Why I Talk About Smalltalk Even Though I’m Working in Java
It might seem strange to bring up the way things are done in Smalltalk while working in another language. It can lead to all kinds of misunderstandings, such as that I think the product should be rewritten in Smalltalk, or that I just don’t like Java, etc., none of which is the case.
The thing is, any language which gains a following is better for something than what preceded it, otherwise nobody would bother learning it. As people learn it, this initial optimization tends to increase in the area it’s initially useful for. JavaScript, for instance, despite my dislike of it, is well suited to an unpredictable, limited runtime (the average web browser), partly because if doing something one way doesn’t work, there’s a million other ways to do it, you can write JS pretty much any way you want. C is good for systems programming, ERLANG is as good as LISP for very complex systems and somewhat easier to figure out a solution in. Java is good for general programming from small to fairly large projects, and as it’s developed, it’s gotten better. So why talk about a niche language like Smalltalk?
Smalltalk of course is good for certain things, otherwise it would have disappeared (anyone remember Eiffel? — beautiful OO language, but not really optimized for anything). It’s a good educational language, it’s a niche language for niches, since niche products can be written affordably in it, and it’s also got a niche in areas where things simply must work. But none of these are relevant in terms of why I mention, at times, the way things are done in Smalltalk and look for something similar in Java.
In the beginning, as an experimental language, Smalltalk attracted experimenters. It still does, as a result it’s great for prototyping. Sun prototyped the first JIT compiler in Smalltalk before implementing it for Java, IBM has prototyped a VM capable of scaling linearly to thousands of cores. It’s easier to figure out certain things in Smalltalk and once you have it figured out, apply it in your target environment. Of course, most of the experimenters it attracted over the years were developers, and one thing developers experiment with are ways of making development easier — tools, techniques and methodologies that assist with development. As a result, design patterns, test driven development, model driven development, and refactoring are just a few of the innovations that came out of the Smalltalk ecosystem.
This is where it becomes relevant to people whose main work is not in Smalltalk. In the book Refactoring Kent Beck talks about the refactoring browser in Smalltalk and how it changes the whole experience of refactoring. Eventually tools like Eclipse and IntelliJ have had refactoring tools added but they’re still limited compared to what’s available in most dialects of Smalltalk. Partly they’re just more difficult to implement, because as Smalltalk attracted experimental developers, the ease of building experimental tools increased — it became more and more optimized for developer experience.
And this is, in turn, why I look at the way things are done in Smalltalk when writing in other languages, as well as why, when I’m writing code for my own use, I tend to write it in Smalltalk. I enjoy it more; it’s better optimized for developer enjoyment.
Java is probably the best optimized language for the project I’m working on, and fortunately, it’s been written in Java. The combination of an easy to use language, with OO everywhere it doesn’t harshly affect performance, and libraries and frameworks that speed development in numerous areas, is compelling when it comes to writing business software. It’s optimized for what we’re doing, and therefore it’s the best choice.
But simultaneously it’s not optimized for developer experience. Long build times with Maven or Gradle, long startup times for a Java server, too much necessary rote code, poor debugging tools (relative to Smalltalk) etc., make it less than the ideal developer experience. Optimizing our tools helps but doesn’t solve every irritation. Some can’t be easily solved or worked around, some require too much effort and/or complexity, etc. In choosing an environment optimized for what it’s optimized for, we must compromise with the fact that it’s not optimized for developer experience.
But that doesn’t mean that in individual situations there aren’t improvements that can be made, and that’s really the reason I look at an environment that is optimized for developer experience — to see what, if anything, can be emulated in our specific situation to improve things and be more productive / less irritated.
It doesn’t mean I think we should rewrite it in Smalltalk, it’s not optimized for our crucial goals. But it is optimized for many of the things we need to do to get there, and if we can translate a few of those optimizations, we’ll get there faster and with less aggravation.
