Smalltalk -- Language of the gods

Smalltalk is a very beautiful thing. It is a "pure" object oriented language (everything, even numbers, even blocks of code, even the execution environment is an object.) Smalltalk's syntax is very simple and very pure. Smalltalk runs in its own graphical world (Sam, http://www.javarants.com/, finds this a barrier to using Smalltalk.) Smalltalk is a live system in that the objects in the program that you're editing are live all the time. There's no 'run', you simply edit live classes of live objects and they stay live. You save your 'image' and all the running objects and all their state gets saved.

This means if you have a web server running in your image, you can save your image, stop the Smalltalk environment, start Smalltalk and load your image and your web server is running again. No need to restart anything. No need to do anything to get back to exactly where you were when you saved your image. This does not mean you have to stop your image (some folks have had images running for years.) However, if you are doing development and you need to shut your machine down to go home, you can save your image, stop your computer, go someplace else (or copy the image to another machine), start the image and things are exactly how you left them, including having your server running.

This mechanism has its pluses and minuses:

-- Always getting back to exactly where you were is awesome.
-- Because the system is live, you can inspect (and modify) any object in the system and because everything in the system (except for some byte-code primitives that communicate with the underlying OS) is an object, you can change the way the system works on the fly as well as seeing how others have implemented stuff.
-- To aid your exploration and changing of the system, Squeak (the open source Smalltalk environment I use) allows you to enable 'halos' around any graphical object and inspect instance variables and code associated with that object.
-- The halo thing works for web based applications in the browser as well (Seaside really rocks.)
-- Lots of tools for exploring all the classes in an image: 'find all the classes that implement a method', 'find all the classes that call a method', etc.
-- Because the execution environment is well defined and has clear boundaries, the code for exploring or halos or changing methods while the system is running is short, clear, and very, very stable.

-- The environment looks very long in the tooth... Squeak feels like Macintosh circa 1989. It feels like driving a 1965 Mustang... everything is in its place, but it's got an AM radio, a 3 speed manual transmission, and no air conditioning.
-- Running headless is a bear. Updating (e.g., loading the latest version of the web server or fixing a security vulnerability) a headless image on a remote server is very difficult (one has to either have a VNC session running in the image or save the image, copy it to a local machine, update it, copy it back, start it up again.)
-- The data and the code is resident in the image so stopping the image without saving causes data (state) loss.

I really like the image concept for development, but for deployment, it's a challenge and for code sharing, it's a lot more work than using CVS/SVN for text files.

The code browser (it's a class browser, editing, syntax checker, method name checker, almost like Eclipse, but has access to every object [and they're all live] in the system) has a great deal to do with why Smalltalk is a thing of beauty.

The code browser allows users to easily find any method from any class. There are all kinds of tools for finding methods. The code browser allows users to add or change methods or instance variables. The code browser does nice formatting (color syntax highlighting is optional.) The code browser helps you look up method names on the fly, does method name completion, and warns you if you're about to call a method that's not defined anywhere in the image.

The code browser has an editor window that, by default, is about 40% of the height of the code browser... or about 14 lines. This is a not-so-subtle reminder that, in Smalltalk, one writes short methods. If your method is too long, you are encouraged to refactor your code. You are encouraged to refactor your classes and push commonly used methods up the class hierarchy.

A side note... Smalltalk has a rich, deep, and beautiful class hierarchy. I looked at it. I was blown away that Smalltalk's classes are richer, more beautiful, more understandable, and all-in-all better thought out than any class hierarchy in Java, .Net, or any other O-O system I've seen.

I found myself writing "better" code in Smalltalk than I ever have in Java. I found myself refactoring early and often. Then I started asking myself why I was writing better code. I realized that Smalltalk is that a language of the gods, I was in Mt. Olympus, and I was doing as the others before me did: coding more thoughtfully.

Smalltalk is an amazingly well designed system/environment/language. It's clean, clear, precise, understandable, and in general done right. I found that I was doing things the way other Smalltalk programmers do things. I was following the example and lead of the amazing folks who wrote the beautiful classes I was browsing and learning from.

This is true of the community as well as the code and environment. The folks hanging out on the Smalltalk and Seaside mailing lists were more polite, more thoughtful, and more direct (flaming is not direct, it's counter-productive and thus less direct) than many other open mailing lists I've seen. Avi Bryant, the guy who wrote Seaside, is amazingly polite and helpful and welcoming. Stephan Ducasse, a professor in Switzerland who's written a bunch of Smalltalk books, helps beginners with the simplest issues in a really warm way.

But all of this takes a lot of work. Coding correctly requires more work and more thought and more effort and less short-term productivity than, well, being a couch potato coder. It takes a lot of work to be nice to everyone on a mailing list, even when they are not being nice to you.

The more I think about Smalltalk, the more I think about working out with free weights. It's a lot of work and a lot of discipline and a spotter and a lot of slower going at the beginning. It all pays off. It's all worthwhile in the long term. But keeping up the pace, keeping up the work, keeping up all the things that must be kept up to have fewer, more understandable, more maintainable lines of code is, well, a big commitment.

I don't think that Smalltalk will ever make it to the mainstream because it does require so much commitment. The bow-flex, treadmill, work-out in front of your TV kind of programming environments are the ones that will prevail. Smalltalk is not one of these. Smalltalk requires real work to get significant rewards. Rails and VB require filling in some blanks and refreshing your browser.

So, maybe I sound like I'm condescending to the programmers who don't want to spend the time and effort and work to make things of beauty. To the contrary. SInce I've become a father and a husband, I have very little chance to get into the "zone" required for me to build great things. I feel comfortable coding by filling in blanks. The fewer things I have to worry about, the more quickly I can get to my project goal. I want to have time and space in my brain for my wife and kids (this was not true 6 years ago when I liked nothing better than to code for 2 weeks straight with small breaks to eat, sleep, and occasionally shower.) In the past I've been able to make the kind of commitment that Smalltalk requires. I'm not sure I'd want to continue to make it over a large project.

I am not sure I'd make the commitment to being a god that Smalltalk requires. Most of the developers I meet on a day-to-day basis... the kind of developers who work hard and are conscientious in the work for 10 or so hours a day are not looking for an environment that requires a mind meld. They're looking for a tool to achieve their goals. From what I've experienced with Smalltalk, I don't think Smalltalk is that kind of tool.

Smalltalk is in fact a language of the gods. Unfortunately, one must make the commitment to work as hard as the other gods to generate output. That, I think, means that Smalltalk will continue to attrack programming gods and continue to grow as a thing of beauty, but will also continue to be a niche language.