Smalltalk is well-known for its impressive collection of development tools. There is nothing like coding in a live environment, surrounded by the living, breathing objects of your application. Other languages try to attain the same level of interaction. Some of them are even getting pretty good. But nothing I’ve seen comes close to what Smalltalk has being doing for 30+ years.

If the provided tools don’t quite meet your needs, you can always add your own to the environment. New tools are written in Smalltalk and can make use of all of the same facilities as the vendor-provided tools. There’s no special plugin language to learn.

That said, there is a downside to this. With a few exceptions, like GNU Smalltalk and the forthcoming Redline Smalltalk, the only convenient way to write Smalltalk is to use the provided development tools.

I believe that this dependence on tools inhibits experimentation with the language and with new concepts and constructs. Any new idea must come with tool support, or there is no way for others to make use of it.

As an example, Squeak and Pharo Smalltalk have so-called “brace constructors”; that is, a literal array syntax using { and } instead of the normal #( and ). The difference is that the elements of the brace-constructed array do not have to be literals themselves. Instead, the code for the elements is evaluated at runtime. This is more like Ruby arrays and can result in much more readable code than the equivalent use of Array class>>with:with:with:.... Years ago, someone released a package for Visualworks that provides the same feature. However, because there wasn’t sufficient tool support for it, the package essentially died on the vine.

As another example, there was some work done on traits years ago. As near as I can tell, traits are somewhat like Ruby’s mixins, but are not allowed to have instance variables. There was even some tool support for them at the time. However, at least in Visualworks, the vendor-provided development tools evolved over time. The traits tool support didn’t keep pace, and so the work that was done is now essentially unusable by those who might be interested.

Good development tools are awesome when doing normal development. Tool support is what drives me to use RubyMine instead of Emacs for a lot of my Ruby development. But I think the need for the tools causes there to be a higher barrier of entry for new language ideas and experiments.