Why Smalltalk isn't just "another language".
I’ve had to defend this opinion quite a few times over the years so I thought I’d write my thoughts down and provide some background:
There are two kinds of agilists. Those that have experienced Smalltalk and those that don’t know how much better things are supposed to be.
People argue that:
- they shouldn’t learn it because it’s just a niche language, or
- that Java or Ruby will do just as well because the benefits of learning Smalltalk are marginal so it isn’t worth the effort.
Both of those opinions are dead wrong.
To address these points:
- By choosing not to learn Smalltalk you are choosing not to understand extreme programming and scrum as well as you could. It’s an inconvenient truth: not everything worth learning is immediately commercial.
- How do you know that Java or Ruby will suffice? You’re making assumptions about something you don’t know.
It doesn’t even matter if you can get a job in it: It will make you a much better designer. I worked in Java for many years yet when I spent just two weeks in Smalltalk I found lots of ways in which my design thinking had been limited by Java and C++. If you know Smalltalk and are working in Java you can think up better designs and then try to work out how to fit them inside the crushing limitations of Java.
Moving from Java to Smalltalk feels like moving from Pascal to Prolog or Haskell felt in college. It was a mind-expanding experience not merely a syntax-changing one.
”…It’s not that people are completely stupid, but if there’s a big idea and you have deadlines and you have expedience and you have competitors, very likely what you’ll do is take a low-pass filter on that idea and implement one part of it and miss what has to be done next. This happens over and over again…” — Alan Kay, A Conversation with Alan Kay
Why impatient Java-based agilists should study Smalltalk
- You don’t have to waste effort fighting the system to let you mock and stub out classes In Smalltalk easy substitution of objects and classes is built in to the language and environment. A huge amount of wasted brainpower is returned to the task at hand rather than burnt off fighting a system of rules that doesn’t support TDD.
- No time wasted trying to guess how to make the test failure reoccur in a debuggable environment: JUnit and test/unit just show you where your tests failed. SUnit actually allows you click into the debugger at the point where the test failed and see the actual objects and how they’re connected so you can see live in the debugger how the code failed and fix it right there.
- No need for “FactoryFactories” Statics aren’t polymorphic in Java or C++ so you have extra factory code. (You don’t know that it’s “extra” code yet… ) It’s difficult to explain this quickly: Smalltalkers can talk about “proper class objects” and sound academic. In practical terms it means a lot less code and clearer thinking.
- Excellent support for incremental development: If you send a message to an object that doesn’t understand it, the debugger comes up and invites you to write that method…
- The highly interactive style of programming you experience in Smalltalk is simpler, more powerful and direct than anything you can do with Java, C#, Groovy or Ruby. Sure, Groovy and Ruby are interactive but in those environments we keep building and throwing objects away so although they’re dynamic you rarely have interactive access to the objects in the context that’d be useful for TDD or debugging. There’s no “reloading classes turned on” or “inserting a breakpoint and restarting” because you’re in the same dynamic object system all the time.
- The IDE, the app that you’re writing and your data are all part of the same system so you can write your own tools and debug instrumentation far more easily.
- A better starting point for learning Smalltalk is a small, consistent language so it’s a much less confusing place to start teaching OOP. It’ll be quicker if they learn to put big ideas into practice first. They can learn about nasty, kludges like “public final static main” and “MAXINT” after they’ve internalised the most important ideas.
Interesting Design Material from the Future:
Model-View-Controller vs Model-View-Presenter, Real MVC vs “Java Model 2” MVC, the Morphic UI, the concept of “liveness” in a UI, the Seaside web framework, what a continuation server is, OLPC, traits, the 3D immersive environment called Open Croquet and Gemstone the amazing, multi-node distributed OO database environment.
Conclusion
- Smalltalk is a niche language.
- It is the oldest and best player in a niche called Agile Development.
That is all.
- Pharo Smalltalk — a practical Smalltalk made from Squeak
- Seaside — The emerging standard web framework for Smalltalk.
- Alan Kay’s Turing Award Speech — covers lots of Smalltalk-related concepts.
- The Future Reinvented — my article about why Open Croquet matters.
- Alan Kay talking about Open Croquet — You know you’re dealing with something groundbreaking when you just can’t find an existing thing that it’s remotely like.
- Free Smalltalk books — Includes the “blue book” which describes the “laws of physics” of the Smalltalk world.
