For the past two weeks I have been experimenting with Smalltalk. I was having a conversation perhaps a month ago with a classmate, who was taking a programming languages survey, and she was mentioning smalltalk, and how weird it was. I tried to explain that it wasn't so foreign, but I may have been tainted by exposure to common lisp, so much of the dynamic nature of smalltalk seemed like a natural thing to expect from a programming system.
I started to look into squeak, and a little reading lead me to Pharo, which if you are an adult looking to write programs and learn smalltalk, offers a much cleaner UI, is compatible with the squeak vm, and has excellent development tools, and no toy like features which provide a funny first impression of Squeak.
It turns out much of what I thought I knew about smalltalk was either incomplete or just plain wrong, borrowing from things I remembered about Objective C from a furtive attempt to start using it years ago. I have been repeatedly blown away by the depth of the object metaphor in smalltalk. The inspector and explorer are leagues above the tools I had become used to (either gdb+emacs or slime+emacs). The additional scratchpads at the bottom of the inspector allowing modification of the object at runtime are well planned and very useful. The debugger at first glance looks like the slime debugger, a variety of restarts are available, a somewhat terse message regarding the offending condition, and a partial stack trace / message history are presented. But the immediate usability of the system comes in the ability to browse the offending code site, modify the code definitions, restart or proceed and fix on the spot the problem.
In two weeks, I worked through the "Pharo By Example" LightsOut program (which was Quinto in Squeak by Example), get a quick feel for SUnit and the test runner, where the tests are only a keystroke away, and can be automatically created, blindly find my way through a currency converter gui program (a la Learning Cocoa), and have created a small DFA simulator. The learning curve is a little steep, but having seen the example application, and learned the short syntax of the language (really fits on a single sheet of paper, possibly a 4x6 card), the remainder of programming seems to have been selecting the appropriate classes, browsing their sanely named selectors, putting the pieces together, and running the tests.
My DFA simulation took about 45 minutes to piece together in between classes one morning, and I am a complete novice in Smalltalk.
Things I don't understand, certainly include monticello/metacello, how to install software, which pieces are loadable but will break your system, and have certainly had my share of frozen images. I recommend to anyone starting to keep a pristine image, and if you ever start it, to immediately save your working copy as an alternate name. Monticello is very useful in packaging versioned bundles, and seems to beat fileOut handily.
The Pharo developers have a very active community, their mailing list is busy, the community is experimenting in several directions at once, and what's most important, the system is discoverable. The browsers and finders are beautiful, the debugger is amazing, the Morphic Hierarchy is easy to browse, and finding the right tool for the job is simply a matter of finding the right pieces to put together.
One thing I haven't discovered in Morphic is how to specify relative position of submorphs, so I simply give explicit locations in the bounds, and hope the user doesn't alter the initial size too much. VisualWorks' GUI Painter seems to have simple checkboxes to control this behavior (if you've used Interface Builder in XCode you will be familiar with Springies...), and perhaps it's present in Morphic as well.
I have to say a few nice things about Stephane Ducasse's well kept links to available books, and his personal efforts in pushing Pharo forward.
