Damon wrote: > I bought the book Smalltalk Companion, by Ted Bracht, to see if I can > pick up Smalltalk. I’ve programmed in Java for several years, and I > think I have a decent grasp of OOP issues. > […] > Missing though are insights that I seek to translate the concepts that > I learned in developing in the file-based language of Java with its > edit/compile/test iterative development process to the image-based > interactive development process of Smalltalk.

 Welcome aboard!

 I made the Great Leap Forward from Java to (Dolphin) Smalltalk a few years ago
 and I think I can still remember how it felt. My motives were not too unlike
 yours -- curiosity about what was claimed to be a better way of working, more
 than anything. What I got out of it wasn't quite what I'd expected. I was
 hoping to find better tools, what I found was a different way of thinking about
 OO.

 You've already had a couple of fairly direct answers to your specific
 questions. I'm going to try to take a step back and talk a little about the new
 way of thinking. I'll try to relate it to your questions as I witter on, but
 the connections may seem (be) rather indirect.

 BTW, this is all -- obviously -- only my own opinion. Other Smalltalkers might
 disagree with much, or even all, of what I want to say.

 The "image" is the *central* concept of Smalltalk. In comparison, nothing else
 is very important. (I'm aware that there are Smalltalk dialects that don't have
 images, but I -- personally -- can't see the point.). If you are like me, then
 you are currently thinking of a big difference between Smalltalk and Java being
 that Java stores code in files, whereas Smalltalk keeps it in the image. That's
 sort of true, and I'll get back to it, but, for a minute, just forget about
 code, it's not important (really!). What matters is *objects*.

 The image is the place where the objects live. Technically, the image is a
 garbage-collected heap that can be saved to file, and later restored, thus
 saving and resuming the state of a computation. *Technically* that's true, but
 it isn't at all a helpful way to think about it. A more organic metaphor works
 much better. I think of the image as a deep, murky, pond where objects move
 around in the depths like fish. It's an important part of the metaphor that the
 objects are *independent* of me. Even if I designed and wrote the classes, once
 an object has been created it has an independent existence. I can talk to it, I
 can ask it to perform operations, but it is separate from me. In a sense it is
 "my" object, but it is only "mine" in the same way that a pet, or a rose bush,
 or a table, could be "mine".

 The image is where the objects live. Not the code, the objects. We'll get back
 to the code in due course, but not yet. The Smalltalk environment is just a
 place where you can talk to objects; no more, no less. Oh, sure its got class
 browsers, debuggers, editors, etc, but that's all tinsel. What matters is that
 it is a place where you can interact with the objects.

 I'll get back to the "tinsel" later too, but for now, I want to talk about the
 one part of the environment that isn't just a productivity aid: the workspaces.
 Workspaces are the medium through which you talk to objects. You *can* describe
 workspaces as "containing snippets of code" which you execute, but IMO that's
 exactly the wrong way to think of it. A better picture (slightly
 tongue-in-cheek) is as a kind of singles bar, where you can meet objects, talk
 to them, check them out, get to know them. Each workspace has a number of
 objects that are (temporarily) living there; they are the values of the
 variables in the workspace. In most cases they'll die when you close the
 workspace, but until you do they'll survive and you can talk to them. I keep
 some workspaces hanging around for days if they contain objects that are
 important for what I'm doing. The way you "talk" is by sending messages written
 in the Smalltalk programming language, but that's almost incidental. The
 important thing is that you are communicating with them using an interactive
 text-based medium, like using an IRC channel.

 I very much like that picture. A workspace is like an IRC channel for talking
 to objects. One difference is that the other users of a real IRC channel don't
 usually die when you sign-off (at least I don't think so, I admit that I've
 never actually used IRC).

 (BTW, you can save the *text* of the workspace in a .ST file -- it's actually
 saved as RTF -- but that just saving a transcript of the conversation. If you
 re-opened the text in a different workspace window then you'd see the text but
 the objects wouldn't be behind it. Using cut-and-paste from one workspace to
 another has the same effect and can be a good way of killing unwanted objects
 without loosing the record of what was said.)

 Another way of interacting with objects is to use the Inspector(s). They give
 you a much more nuts-and-bolts, low-level, view of the object -- a more
 intimate view, if you like. I, personally, don't think that the Smalltalk world
 has yet woken up to what inspectors *could* be, but the current implementations
 (like "flipper" in Dolphin) do at least allow you to see inside the objects.

 An image will contain many objects, some long lived (living, perhaps, for
 decades), most very short lived indeed. Some will be simple or trivial, like
 Strings and Points. Others will have complicated internal structures, and/or
 complicated behaviour. But they are all objects, and they all live in the
 image, and you talk to them in workspaces.

 Classes are one particularly interesting kind of object. Remember I'm *still*
 not talking about code (that comes later), I'm talking about the objects called
 classes. Just like any other objects, you can invite them to join you in a
 workspace:

     class := String.

 and then you can use the magical Smalltalk object-oriented IRC to talk to them:

     class name. "--> #String"
     class allSubclasses size. "--> 3"

 and so on. So classes are objects, and they live in the image.

 Since Smalltalk is a programming environment with GUI features, there's nothing
 more natural once we've reached the point where we have an image full of
 objects, than to start writing tools that allow us to interact with the objects
 in more structured/convenient ways. Workspaces and Inspectors are fine for the
 basics, but we'll soon want better tools that allow us to see the relationships
 between objects (or some subset of objects -- the classes for instance), or
 what messages they understand. Maybe we'll want to be able to modify their
 behaviour, or create new kinds of objects. That's exactly what the IDE
 provides. The class browsers, etc, are merely a collection of tools for talking
 to objects. They are useful, even highly desirable, but ultimately dispensable
 because we could talk to the objects without them, anyway.

 But now it's time to get to the subject of code. The progression I've taken,
 starting at objects, then the important tools, then classes, then more tools,
 and finally code, really does represent a progression from the most important
 to the least. In this way of thinking the code is the least important part of
 programming in Smalltalk. (Of course, I'm schizoid about this, I don't
 *really* think that the code is the least important part -- just muck with my
 code's formatting and watch me explode -- but on the other hand, I really *do*
 think that the objects are more important.)

 Code is how we tell objects how to behave. It's text in the Smalltalk
 programming language. We're programmers so we care about code; when we wrote
 the tools for looking at objects, we naturally designed the tools so that we
 could also see the associated source code. For instance our special tool for
 looking at classes (the class hierarchy browser) allows us to see the source of
 the methods, to change the source and recompile, etc. That's natural for us as
 programmers. If we weren't programmers then we'd want different tools, and we'd
 be interested in talking to different objects. Such systems, built for
 non-programmers, are called "applications", but they are still just
 Smalltalk -- tools for talking to objects that live in an image. (A big
 difference is that the "image" of an application is typically not persistent,
 unlike the image of the IDE).

 Back to code. Granted that the most important thing is the objects and how they
 behave, we still do care about the code. We want to organise it, back it up,
 put it under source code control, etc. A class is an object that lives in the
 image, but the source code *for* that class is something else. For all sorts of
 reasons, we want to keep that outside the image. The way that Dolphin organises
 source-code is via Packages. A package is a collection of the source code for
 classes and methods (and a few other things too, which don't matter here) that
 is kept outside the image in one or more files. You can load the package into
 the image, which will create an actual Package object, and class objects
 corresponding to the source-code. Or you can "uninstall" the package, which
 really means killing the Package object and the Class objects.

 So a package is just a way of collecting related source-code together. Some
 Smalltalks go further and associate namespaces with packages. Dolphin doesn't
 (and I'm not at all sure that I think that's a bad thing). You can load the
 same package into different images, in which case you'll have duplicate
 versions of the class objects living in both images. If you do that then you'll
 want to be careful not to make changes to the classes in one image and not the
 other, because then the package file cannot reflect the state of both images.
 The package mechanism is relatively simple; it could be improved, but I find it
 adequate for my needs. Package files are text files, you can edit them with vi,
 or notepad, or whatever. Occasionally I do that if I want to make particularly
 sweeping changes to the source. Of course, if you do that then you have to
 install the changed version into the image before it'll do anything useful.

 Notice how very different this way of thinking is from the way that even the
 best Java IDEs encourage you to think. When I started out in Smalltalk I was
 thinking of the IDE as if it was a Java IDE. I though of it as a tool that
 allowed me to write code, and had features to allow me to browse and test the
 code. After a year or so I realised that I'd turned the picture upside down
 completely, and in the process had revised my conception of what
 Object-Oriented programming is all about. As a Java (or C++) programmer I had
 pretty much thought my .java (and .cpp) files *were* the classes, and I thought
 that creating classes was what programming was *about*. I now think of the
 objects as being the important thing, and the classes as very secondary, hardly
 more than an implementation detail.

 I *feel* that that has made me a better programmer. Of course it's not possible
 to know for sure, but if it has, then it all comes down to Smalltalk's
 workspaces...

 (A couple of asides for seasoned Smallalkers, if any are still reading:

 Was Dolphin the first Smalltalk to have workspaces that kept the values of
 variables rather than throwing them away after each evaluation ? VW used to
 discard them and I think VASt still does. Squeak keeps the values, but I don't
 know how long that's been true. Anyway, whichever implementation it was that
 introduced the idea can -- I think -- claim to be the first *truly*
 object-oriented Smalltalk. Presumably also the first truly object-oriented IDE
 of any kind.

 Writing this has made me focus on the unease that I still feel with
 programming-in-the-debugger. I was already a bit suspicious that it might
 encourage a (crypto-)topdown approach to decomposition. I'm now starting to
 wonder whether it also is part of a "code-centric" way of thinking, rather than
 the "object-centric" mindset that I think Smalltalk *should* foster.)

 BTW. One book on Smalltalk that I heartily recommend, especially if Ted
 Bracht's "teach-by-example" approach isn't right for you, is Chammond Liu's
 book, "Smalltalk Objects, and Design". It's the best book on Smalltalk that
 I've ever read (although it's not Dolphin-specific), and in fact I'd say it's
 the best book on OO that I've ever read too.

 Oh well. Once again, this has been a longer post than I'd intended. I don't
 know if anything I've said has made any sense to you, or has seemed even
 slightly relevant. I've had fun writing it anyway...

 -- chris

A number of times before we’ve talked about organizations behaving in ways that seem pathological, and what agilists might do in those circumstances.

This interesting article suggests that a number of headline CEOs (and likely a bunch of high-level executives and corporate climbers) are diagnosable psychopaths:

www.fastcompany.com/magazine/96/open_boss.html

In particular, quoting from the article, they score highly on eight characteristics:

• glibness and superficial charm
• grandiose sense of self-worth
• pathological lying
• conning and manipulativeness
• lack of remorse or guilt
• shallow affect (i.e., a coldness covered up by dramatic emotional displays that are actually playacting)
• callousness and lack of empathy; and
• the failure to accept responsibility for one’s own actions.

For me, this article was an eye-opener. There have been a couple of agile adoption efforts that I have participated in where, in retrospect, I concluded the only thing I could have done was walk away as soon as possible. From my armchair diagnosis, both involved psychopaths in positions of power.

Now it makes sense. These people weren’t just sincere but misguided. They really had no interest in transparency, in long-term sustainability, in producing good work, in steady progress. Indeed, given that they thrive in chaos and confusion, that they enjoy or are indifferent to suffering, their values are fundamentally opposed to the values we here hold.

Nancy Van Schooenderwoert added: Yes, a very fascinating article! I have a book on a related topic. It’s "the Corporation" by Joel Bakan (2004 Free Press). A cover blurb says:

  "The corporation's legally defined mandate is to pursue relentlessly
  and without exception its own economic self-interest, regardless of the
  harmful consequences it might cause to others."

I got the book recently and haven’t read it yet - but this article seemed to point at the same problems on a personal level.

www.rubyist.net/~matz/slides/oscon2005/index.html

 irb --noreadline

Alternatively make sure you check out the graphical frontend to ri.

 fxri

Dear all,

 Euruko 05 will be in Munich, October 15 and 16

 Location
 Room 2.07 of Sulzer GmbH in Munich, Frankfurter Ring 162.

 Audience
 Everybody interested in Ruby is most welcome!

 Fee
 Like last year we will collect a minimal fee of 20 euros.

 Please sign up here, as we will spend last year's income to make some
 T-shirts and to get some drinks for the conference.

 http://www.approximity.com/cgi-bin/europeRuby/tiki.cgi?c=v&p=Euruko05

 Please also sign up if you want to give a talk.

 We thank Sulzer GmbH for letting us use their office space and all
 other support.

 Hope to see many of you,
    -Armin, Sven, Michael and Stefan

 A leader is someone who has followers.

 A manager is the person who is responsible for everything that no-one
 else is responsible for.

 The rest is details.

 Actually, when I was working with Chuck he usually wrote it three times:
 1. "It can't possibly be that complicated."  Very simplistic model that
 captures the essence of the problem but ignores a lot of the requirements.

 2. "But you have to handle these other situations..." Complications get
 added to handle more and more of the requirements, encrusted on the original
 base.

 3. "Ah, now I see what we need."  Starting over from scratch, he can now
 build a clean implementation that accomodates all the requirements from the
 ground up.

 Unfortunately, many projects end up with an extended Stage 2, and never
 progress to Stage 3.  Chuch always had the courage to grasp when it became
 necessary to abandon Stage 2 and start over, even though it often caused
 consternation for the customer!

 Mike wrote:
 > What is a smaller lisp implementation that runs on both
 > gnu/linux and windows?

 Let's see, the user will have to install Linux to run the program, but
 the footprint of that program has to be small. :)

 Have you run a system call trace lately on, oh, the ``ls'' program?
 Tons of shared libraries attached. System calls flying left and right.
 A bazillion nonexisten files searched after.

 Linux is not exactly small and lightweight (any  more).

 Here is a comparison between a directory listing and evaluating a
 single expression with CLISP:

 machine:$ strace clisp -norc -q -x '(+ 2 2)' 2>&1 | wc
    260    1963   19729
    machine:$ strace ls /dev/null 2>&1 | wc
        111     870    8225

 It only takes about 2.5 times as many system calls to start up CLISP to
 evaluate an expression than to fetch a directory listing for a single
 file.

 The size of this Lisp system is less than 3 megabytes: a 1.2 meg
 executable and a memory image that is about 1.4 megs.

 Then we add up the shared libraries:
 machine:$ ldd ~/lib/clisp/base/lisp.run | gawk '{ print $3 }' | xargs
 du --total --dereference
 176     /usr/lib/libreadline.so.4
 852     /usr/lib/libncurses.so.5
 16      /lib/libdl.so.2
 1540    /lib/tls/libc.so.6
 20      /usr/lib/libgpm.so.1
 112     /lib/ld-linux.so.2
 2716    total

 The shared libs are as big as the program.  The kernel on this system
 (the uncompresed vmlinux file, not the compressed vmlinuz!) is about
 3.5 megabytes, whoa! Of course, all these executable images have
 run-time storage requirements as well.

 This particular Lisp system is smaller than the kernel, smaller than
 the total size of the shared libraries attached to it, and cranks out
 only about 2.5 as many system calls to evaluate an expression and quit
 as ``ls /dev/null''.

widgets.precisionis.com.au/

More than a century of studies show that long-term useful worker output is maximized near a five-day, 40-hour workweek. Productivity drops immediately upon starting overtime and continues to drop until, at approximately eight 60-hour weeks, the total work done is the same as what would have been done in eight 40-hour weeks.

In the short term, working over 21 hours continuously is equivalent to being legally drunk. Longer periods of continuous work drastically reduce cognitive function and increase the chance of catastrophic error. In both the short- and long-term, reducing sleep hours as little as one hour nightly can result in a severe decrease in cognitive ability, sometimes without workers perceiving the decrease.

www.igda.org/articles/erobinson_crunch.php

 A revolutionary machine that can copy itself and manufacture everyday
 objects quickly and cheaply could transform industry in the developing world,
 according to its creator.

www.cnn.com/2005/TECH/06/02/tech.reprap/index.html

 The question is _where_ is it gaining ground...
 as a hobby (which I presume is what most c.l.l readers,
 myself included, use it for), or as a substantial outfit
 in a company or in academics, and in the latter I see none
 of it in the last couple years (the almighty Java seemingly
 smothering all and everything).  Any recent success stories
 (i.e. new or significantly increased use of Lisp) here from
 non-hobbyist camps that someone is willing to share?

Sure, CliniSys. Clinical drug trial management. Don’t ask. It is a big problem. Sites by FDA requirement must operate independently of the drug sponsor in conducting trials, which the FDA further want conducted in precise fashion and with elaborate documentation. Investigators are busy people and often screw up. Monitors from the sponsor visit every six weeks to corral things temporarily.

Our mission was to bring everything under control with a thick client installed at the site guiding sites thru the process, enforcing business rules, and basically seeing to it that the whole process runs right while documenting everything and with a precise audit trail of that process and documentation. The thick client also meant we needed a sophisticated application-level partial replication scheme to move clinical and audit data around a wide-area network of collaborating trial professionals.

The hard part is that every trial is different. Even within a trial, the documentation can vary from site to site. On the wish list is customizing documentation to individual patients to support adaptable trials. To make things worse, the documentation can change in the middle of a trial, but data collected under one version of a document must remain associated with that version as other versions come along.

And getting the documentation right means applying arbitrarily sophisticated edits. eg, The pregnancy test result on Visit 2 is required if the gender collected at Visit 1 was female, otherwise it must be "Not applicable".

The final challenge is scaling any successful result to hundreds of trials a year. Existing software does a small fraction of our intended functionality and is so hard to configure to each trial that (a) they can get $500k to do a big trial and (b) vendors max out at a couple dozen trials a year. They hope sponsors will run the software (they call it "technology transfer") and figure out how to configure the software themselves faster than could the vendor. They do worse, and a lot of these vendors go out of business.

So we needed to do WYSIWYG DTP, ICR (scanning and reading documents), our own DBMS, workgroup software to support remote monitoring, and a full browser app for reviewing and collaborating on the documentation set. ie, we needed a GUI, too.

I knew right away that we would have to be able to configure the application for a new trial without programming. Well, there would be a scripting language, but it would be the kind of thing power users master all the time. I also figured out pretty quickly that it would be easier to make a programmable application with a programmable language.

The project was two years old and $2m spent when I signed on to take over software development. My predecessor had just quit. In an exit interview I determined that he was making the right move for himself, but that I would like the gig.

The angel founder trusted me to use the right software, which only makes sense since he was betting $3m on me succeeding. I brought on one other person and in four man years we produced a system that was vastly superior to systems built with tens of millions of dollars. 80kloc Lisp.

People in the business agree our system will revolutionize the conduct of clinical trials. Some nice big partners have joined the effort to make our case to our first customer. That helps since it is a little stange for a three-person operation to have done what no one else even thought possible (which is why they were all trying to use the Web to solve the problem). Making progress, though. Close brushes more often <g> getting both customer and investment.

How did we do it? First, I had done this programmable application thing a couple times before. Second, Common Lisp. Third, Cells. Fourth, AllegroCL’s AllegroStore database. Fifth, AllegroCL’s IDE and Franz tech support.

 Yesterday I was pairing with Patrick, our new intern. He's great,
 smart as a whip, and willing to learn. (When I told him we write tests
 first, he laughed, incredulously, but then I said No, really, I'm
 actually serious, and he listened, and later, he said, Oh, now I see.)
 At the end of a long successful refactoring (turning a clutch of
 static methods into instance methods), we were sort of buzzing and
 didn't want to stop, were casting about for other refactorings to do
 in the same class. I suggested a technique I only just then gave a
 name to, that I've done occasionally on my own for a long time, but
 hadn't yet taught: Zen Refactoring.

 "Just let your eyes unfocus and scroll through the code and look for
 refactorings. Look for duplication; look for too-long or
 too-deeply-indented code blocks. When you notice something odd, don't
 read it, just select it, hit Extract Method (ctl-alt-M), and hit
 random keys for the name. Then focus your eyes again and see what
 you've done."

 I demonstrated. The first time we hit a bunch of print statements with
 repeated formatting -- it worked, but the refactoring was tedious,
 with marginal payoff. But the second time was golden. I saw a blurry
 if-else block; the first arm meandered for 15 or 20 deeply-indented
 lines, the second for fewer; their logic appeared opaque and disjoint.
 But after extracting the first block as a method, lo and behold:

 if (something() || other()) {
  customerId = sdlfjds(x, y, z);
  } else {
    user = someOtherExistingMethod();
    customerId = user.getUserId();
 }

 IDEA had figured out that the result of that meander was a single
 value, and returned it from the new method. It was instantly clear
 that we should rename the extracted method
 customerIdForSomethingOrOther", and extract the whole conditional as
 "getCustomerId". Shift-F6, ctl-alt-M, high five.

 Then it was Patrick's turn. Not quite as much of a slam-dunk but still
 a worthy refactoring. I can't wait to get an incredulous laugh from
 the next one I spring this on...

 When I talk with CEO and CFO types, I generally emphasize that XP /
 Agile projects focus on the delivery of running, tested, actual
 software, along the lines of my article /A Metric Leading to
 Agility/, http://www.xprogramming.com/xpmag/jatRtsMetric.htm