Why Smalltalk tools can still be improved a lot

Readers of my bog know that I sometimes start to dream of a nicer, better Smalltalk environment. Smalltalk has great tools and the language and environment give you a lot of possibilities to explore the objects hanging around in your system and fixing / improving them. Developing a Smalltalk program has two components to it:

  • exploring and maintaining the zoo of objects living in the system
  • reading and writing code

Typical Smalltalk environments have very good tools for doing the first, but the world around us has improved a lot on the second field over the last few years. And Smalltalk environments are only slowly catching up on code editing tools as compared to what other environments offer today.

Over at the VA Smalltalk support forums, a member of the development team asked for ideas of what could be done short- to mid-term to improve the environment.

Around that evolved quite some discussion in several threads, from Improved Code editing, to code merging tools and new ways of navigation source code. A few very nice ideas that I’d also call low-hanging fruit for improvements of VAST were brought up in the discussion and I hope Instantiations is going to pick them up.

In an answer to somebody’s post that repeated an often used argument, I wrote the following post. The argument was essentially that Smalltalk methods tend to be short, so if you see long, hard to merge methods often, you should think about refactoring these methods instead of crying for better tools. While I agree that long method should be avoided and I also agree that refactoring them would help in not only making the code better readable, but also in improving the maintainability of the system, I think the consequence drawn is wrong. Here’s my argument:
I agree. If we all wrote short methods and were good in OO design and programming techniques, the quality of our tools wouldn’t matter all that much.
I just had the same discussion with a Smalltalk friend yesterday. We old bones Smalltalkers often don’t realize how much tool support we are missing:

  • no need for code completion/intellisense if I know the Collection Protocol by heart
  • no need for a code formatter because it would only start religious wars in the project team and we as as a Smalltalk community would be extinct within weeks
  • no need for good merge support because Smalltalk is so easy to read
  • no need for line numbers or code folding because our methods are no longer than 6 lines (gives me a good laugh every weekday when I work with legacy code)
  • no need for any tools that help me keep track of my browsing history, because you get used to 38 open windows very soon
  • no need for a “new class” dialog because everybody knows I can just type over an existing class definition expression to create a new class
  • no need for an online “API” documentation because I can always fire up a Class Browser on SortedCollection to see how I can use it
  • The list continues

But still, when I’m in Xcode and enjoy code completion, online help, good merge tools and a nice-looking environment, I feel some excitement about that. I would say that Objective-C methods are also short, if you program in good OO style. Being able to fold/unfold code can help a lot. Finding the opening bracket for a closing one helps me find missing ones. Code completion which also helps me find the online documentation for what parameters to hand in etc. helps me.Maybe that’s because I am a relative Objective-C newby and need that, whereas I don’t need it in Smalltalk all that often.

But maybe I am also not the kind of user that brings in fresh blood into the community.