Why Smalltalk?

A quick word on why I choose to code in Smalltalk in my spare time, and why I enjoyed the hell out of working with it full-time, several jobs ago.

To put it simply, there is a feeling of delight, wonder and power when coding in a good Smalltalk environment (such as Squeak/Pharo or VisualWorks) that is unmatched by any other environment and IDE.

Like tasting fruit from the Goblin Market in the poem, and then forever pining away for it, working in Smalltalk spoils you for other languages (I’ve worked in C++, Java, Perl, Python, Ruby and Lisp) and development environments (tried VisualStudio, Eclipse, Emacs, vim, TextMate).

The two things that you spend most of your time doing as a programmer — coding and debugging — are made noticeably easier and more fun by that combination of Smalltalk language and IDE. The language syntax is small, powerful, expressive, introspective. The entire stack (and libraries, and IDE) is written in Smalltalk (turtles all the way down), and you have access to the source code, allowing you to study and extend all operations, basic and complex. The code organization — explicit, first-class visual IDE support for packages, classes, protocols (groupings of methods by intended use) and methods — is extremely helpful.

The debugger… is a thing of deep beauty. The ability, while, say, developing a web app, to not only set breakpoints and examine the state of the running program (even, if you set it up right, through the web browser itself — remind me to tell you about “halos”), but to be able to interact with the objects on the execution stack dynamically (i.e. call methods on them, and examine their output), and also to change code and resume execution from mid-halt… is freeing beyond belief.

The above things, by themselves, would merely make me like the language a lot, and miss its convenience. But the thing that makes it truly indispensable for me is Seaside, a web framework.

It is unorthodox, flexible, powerful, and… difficult to describe. I’m going to let people much more eloquent than me attempt to do so:
* Secrets of lightweight dev success, Part 8: Seaside
* A SeaSide Vacation

What’s the downside of working with Smalltalk, though? (Just ask the Lispers what the downside of working with Lisp is), rather than, say, in other sufficiently elegant and pleasant languages such as Ruby or Python?

In short, less popularity and a smaller developer base. Which means less third-party libraries, tools and open source projects. So, you’re a bit out there on the bleeding edge (which is funny, because Smalltalk is 30+ years old, but again, ask the Lispers about that).

The upshot, then is this. If you’re working on a well understood and often-solved problem (for example, CRUD-type record maintenance over the web), use something like Rails, Django or web2py. But, as is just as often the case, if your project is way off the beaten path (like, say, a web mud), Smalltalk and Seaside just might be perfect for you. And in any case, it is worth trying out for a week or a year. You will learn a hell of a lot.

About these ads

13 thoughts on “Why Smalltalk?

  1. I stopped reading at “…good Smalltalk environment (such as…VisualWorks)…”

    VisualWorks was the worst environment I’ve ever had the opportunity to waste my efforts in. Its painful UI and ability to crash at the worst possible moment was what did it for me. Also, the fact that it had so much potential made the experience that much more painful.

    • Just curious when and how did VisualWorks crash on you? Could please you elaborate. I have used VisualWorks and its predecessor since the lates 80s and my experience is that it crashes less often than most other IDEs/development environments. However I agree that its has some flaws, but all (aggressively) evolving environments will always have flaws…

  2. I definitely agree with most of what was said…except that I’d never, ever recommend VisualWorks. It’s a piece of beautiful crap which has the feature of failing at its own pleasure :(. Otherwise, yes, smalltalk is definitely every programmer should explore and play with!

  3. I feel inspired to try Smalltalk. I just picked up a copy of A Taste of Smalltalk now I just need some free software :-)

  4. Excellent info for me, thank you!
    I am an old hand spoilt forever by Smalltalk (Visualworks – the best!) and lots of other experience looking for a CRUD FW. I guess RoR it is then. Sigh!

  5. Smalltalk is the best development environment for both development and maintenance. I’m newly returned to Smalltalk – started with Digitalk/V, then left, then Squeak 2.7, then left, now Squeak/Pharo.

    I think many developers don’t know how to truly program in an OOPL and are also living with the legacy of growing up with text files and edit-compile-link cycles. I often see that many developers in all languages make poor use of their API Library – they resort to brute force programming.

    I must disagree with a statement you made however regarding CRUD applications. I think if Smalltalk is to regain popularity, we should try at every opportunity to use it for all programming tasks. There are simply too many benefits to the Smalltalk environment – automatic logging, and filein/fileout and changesets besides the dynamic programming, live debugging and of course the refactoring browser.

    And that’s another point, how many people actually refactor their code? Smalltalk is great for this.

    I’m in the process of learning all of the capabilities of Smalltalk (Squeak/Pharo) for an “out there” application. During this journey of discovery, I may try implementing a small programming service that does everything in Smalltalk and operates on the following business model:

    - Pay by the Feature, Not by the Hour
    - Free conversion to Smalltalk, based upon a 3 year support contract
    - Aggressive refactoring of code base for optimization and decreased maintenance cost
    - Leverage code reuse and Smalltalk productivity to compete against offshore labor
    - Pricing based upon size of code base and delivery/support rates
    - Reject customers that dictate use of other languages and tools – only Smalltalk
    - Hire Smalltalkers based upon volume/size of code base to handle growth
    - Use virtual management of virtual teams
    - Virtual teams use central code repository for development and maintenance

    I always thought that this approach would allow for growth in Smalltalk jobs, repatriate jobs back to North America and be very competitive.

    Bottom line? As a community, we should be developing in Smalltalk at every chance. It would actually address problems within the IT industry regarding development costs, late projects and a ballooning maintenance issue with legacy code containing 53% defect rates within the code base.

    I’d be interested in hearing what you folks think of my post.

  6. After I originally commented I seem to have clicked on the -Notify me when new comments are
    added- checkbox and now each time a comment is added I recieve four emails with the
    same comment. Is there a way you are able to remove me from that service?
    Appreciate it!

Comments are closed.