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.

2 thoughts on “Why Smalltalk tools can still be improved a lot

  1. I am currently a “hobbyist” Smalltalker (thought one of old jobs was maintaining a VisualWorks project for a couple of years back in the late 90’s), so I develop mostly with C# during my day job and work on my Smalltalk side projects in the evening and weekends.

    I’ll have to say that there is a lot that I miss when switching from a VisualStudio/ReSharper environment to VisualWorks (I’ve been learning Pharo environment too, but still don’t have much time with it). In VW using Tabbed Views, coloring, Searchlight, and code completions I have an environment with which I am comfortable, but I miss a configurable code editor, better “intellisense”, and an easy keystroke that I can hit to get help on a code element. And even though re-factoring tools originated with Smalltalk (as with so many other things), ReSharper has far surpassed the RB in ease of use and power IMO (take for example deleting a method in RB – if you try to delete #new from one of your classes, be careful!)

    And I would love to have browsing history…

    Alas I think the only way we’ll see improvements in our Smalltalk environments is to grow a bigger community that can help shape and improve the tools. Then again we might not be able to grow the community as well if our tools are seen as sub-par by newcomers.

  2. I am baffled by both sides of this long-running debate. To me, it seems:
    * long-time Smalltalkers have become institutionalized to bad tools, making illogical rationales for not improving them. I can feel this happening to myself already, but every time I have to edit a Ruby script in vim, I realize that, all things being equal, the milliseconds saved every time I press one key to issue a command (e.g. go to the end of the line), instead of switching contexts and hand position and then using the mouse, add up during a programming career.
    * and, why don’t people who want better tools just make them yourself! This is the joy of an open system like Smalltalk🙂

    While some of your bullet points do make the pain less acute (e.g. the browsers are even better than API docs), others fall short:

    * “no need for code completion/intellisense” – only having to type 3 characters of a long message name adds up (see vim comment above)
    * “no need for any tools that help me keep track of my browsing history, because you get used to 38 open windows very soon” Uggh! Even when it doesn’t actively annoy us anymore (I’m not there yet), it’s still inefficient, and doesn’t capture the logical progression of multiple concurrent explorations through the system.

Comments are closed.