Smalltalk: Swimming with the fish

The analogy given in the article is pretty accurate. The Smalltalk environment is unique in that it allows very easy access to the libraries, the IDE and the language’s internals (including the compiler!). The Smalltalk debuggers are among the best ones I have ever used.

(I’m mostly speaking out of my experience with VisualWorks, a commercial Smalltalk implementation, but other implementations are similar.)

I would greatly recommend everyone to give Smalltalk a try. The IDEs are pretty ugly and cumbersome, but don’t let that put you off. Get a feeling of the minimalism of the programming language and the pure form of object orientation. Dig through the code of the standard library — it’s quite easy — and check out the implementations of TrueClass, FalseClass, BlockClosure etc.

Unfortunately, many parts of the Smalltalk IDEs are horribly outdated and make Smalltalk a very poor choice of environment to use for production code.

Smalltalk lives in its own little world, and the tools that you’d normally use during day-to-day development are integrated in the IDE, and there is virtually no possibility of using external tools. The text editors are pretty bad, and you can’t use vim or emacs or Sublime Text. The Smalltalk VCSes are particularly horrible. For version control, you need to use systems such as Monticello or Store, both of which make me cringe just thinking about them again.

I also feel that Smalltalk coders get locked in into their environment. Many Smalltalkers that I have met are quite unfamiliar with what is happening in the outside world. Most of them have never heard of git, for example (and quite a few did not know what Subversion was). When an interesting technology enters the Smalltalk world, people seem to rush to reimplement it in Smalltalk (yes, there is STON — Smalltalk Object Notation).

These were the main reasons why I quit my Smalltalk job. A sad decision, but one that was unavoidable in the long run.

Smalltalk is a nice language and has IDEs with some very nice features that I would love to see in other environments, but it is also severely lagging behind in many other areas. I would like the Smalltalk community to be more aware of what is happening outside and build bridges. Without that mindset, I feel Smalltalk will simply fade out completely.

Source: I used to be a professional Smalltalker for almost three years.

With respect to version control systems, I notice you didn't mention ENVY. I can't comment on Monticello nor Store, never having used them, but I still miss ENVY. Best version control system I ever used.

Source: professional Smalltalker for about four years (fifteen years ago)

> Still, using Python to pay the bills isn't so bad...

Well, and pdb isn't bad.

There's barely any such thing as a debugger, and no such thing as an object graph, and even modifying a function in place is far more complicated than real tools would make it -- but nonetheless, in the sort of browser-based Javascript development I do on an almost daily basis, I sense a faint echo of the je ne sais quoi to which you refer; specifically, iteratively fiddling with a live system until it behaves more like how you want, then baking those changes into the serialized form of it (also called "source code") so that they're incorporated next time the system is instantiated.

Granted, I have only the most trivial experience with Smalltalk; I'm pretty sure at least some of the concepts I have in mind here are entirely meaningless in that context, but I wonder if it would be fair nonetheless to consider the modern browser Javascript environment, for example Firefox with Firebug and a proper REPL instead of the single-line console, as potentially possessing at least some of the flexibility a Smalltalker considers de rigeur.

On the other hand, if you wanted to build, for example, an object-graph generator in pure Javascript, I don't think you could do so, at least not one worth having; unless I'm very much mistaken, Javascript's reflection facilities don't suffice to allow one thing to notice when another thing changes, unless the latter thing explicitly notifies the former of the change. So you'd have what would be essentially static analysis on running code; you could recursively walk properties from the global object on down, following references where necessary, but it'd be dog-slow in modern JS implementations; worse, there'd be no way to keep it synchronized with the actual state of the objects to which it refers, short of rewalking everything to spot the changes, which would be ugly in theory and unusable in practice. So it's probably also accurate to say that the modern browser Javascript environment offers no immediate prospect of attaining anything remotely resembling the facilities a Smalltalker considers de rigeur.

Which is a shame, because what I've seen of Smalltalk has been impressive in the extreme, especially by contrast to the tools whose use I can actually justify in my professional life.

It exists. That's better than the alternative, and if this seems like damning with faint praise, it's because there really isn't anything else good to say on the subject -- the debugging facilities available in any Lisp environment, even Emacs, make those offered by Python (or Perl, or Ruby, or Javascript) look pitiful, and from all I've seen of Smalltalk, it is to Lisp as Lisp is to your interpreted language of choice.