Nate Dickson Thinks...

My first day of high school I walked into Latin class. I had chosen Latin for my mandatory foreign language because I'm a stereotypical Gen-X guy: I didn't want to be in a popular class. I (rightly) guessed that there wouldn't be all that many people in Latin, they'd mostly choose “mainstream” foreign language credits like Spanish or French.

The teacher got up and said, “You're never going to need to speak Latin.”

Which...I mean, we all knew that.

“Not because Latin is dead, but because it's only used by a very few people in its original form. But what you are learning here is the why behind so many other languages. Learning Latin will make you a better speaker of English. And if you decide to learn French, or Spanish, or Portuguese, or Italian, you'll have an easier time with those languages as well.”

I spent three years studying Latin. My third year there were only two of us in the course, so we met at the same time as the Latin II students. I'm eternally grateful that our teacher had us teach them from time to time.

Fast forward to the early 2000s when I was a sole developer at a bookstore. The management team discovered that they suddenly had a software developer, and one of my first projects out of the gate saved the organization tens of thousands of dollars in manual computation time. So they more or less let me do my own thing, leaving me as the goose that laid golden eggs. I used that freedom to teach myself...well, lots of things. Since nobody else knew what I should be doing, I wrote apps in every language I wanted to learn. I wrote Ruby on Rails apps. I wrote an app or two in Adobe AIR (it seemed like a good idea at the time, okay?) I wrote a bunch of PHP and thus paved the way for a number of future jobs.

And I stumbled across SmallTalk.

At the time I was on a windows machine, so the version I discovered was Dolphin . I had an instant affinity for the language. I love SmallTalk's insistence that everything is an object, including classes. That the entire system is sitting there waiting for messages to get passed around.

Since then I've worked in a number of real software development jobs, and I've used the languages that my (more tech-savvy) bosses required me to use. But I've recently been playing with SmallTalk again for fun. And now that I have experience with more modern languages it's striking how clearly SmallTalk's DNA is wound into so many modern systems. Some fun examples:

• MVC (Model-View-Controller) architecture is a major feature of many web development frameworks like Laravel and Rails . SmallTalk-80 (yes, that means 1980 ) builds user interfaces on the MVC principle.
• VM's. Java's bytecode-running-on-a-VM is an imperfect example, but it comes close. A more striking comparison is deploying an application into a Docker instance. Like Docker, SmallTalk lets you build a full ecosystem that supports your application code, and deploy the entire thing as an image that can run on any OS that can run a SmallTalk interpreter. Which is basically all of them.
• Test-Driven Development TDD was an early principle of SmallTalk and has been picked up almost everywhere. SUnit, the SmallTalk Unit test framework, is the ancestor of all the other *Unit testing frameworks, like JUnit, PHPUnit, etc. An interesting feature of SmallTalk's TDD-nature is that it's a common practice to do the following:
  
  • Write a bunch of unit tests
  • Fire up the test runner
  • When the first test fails, write the method to satisfy the test in the debugger itself since every object is alive all the time.
    
    • Repeat until all tests pass and your first pass of the app is written.
  • Write more tests for as-yet-un-implemented refinements and features
  • Repeat
• Object Orientation. SmallTalk is the great grand-daddy of classes. It's is older than C++. Apple (via NeXT) fell in love with SmallTalk, and Objective-C is heavily reminiscent of SmallTalk. Instead of “calling methods” like C/C++, Objective-C “sends messages” in a syntax that you could almost drop into a modern SmallTalk system. Speaking of Apple,
• AppleScript is basically SmallTalk writ large. Instead of having objects in a VM that can send each other messages, AppleScript asks “what if every app on the whole computer could send each other messages?”
• Ruby incorporated a lot of SmallTalk's big ideas. From basic things like like “everything—including the class Object—is an object.” to simpler things like blocks, symbols for identity instead of strings, and, well, a lot of Ruby's syntax in general. Code like 10.times do | x | ... would feel very at home in SmallTalk. Matz himself is fairly open about SmallTalk's place in Ruby's history, alongside Ada and Eiffel and others.
• “Duck-Typed” Languages. SmallTalk's philosophy about typing is that it's kinda none of your business. You send a message to an object. If it (or any of its ancestors) has a response to that message it'll answer. If you really want to know what class an object belongs to, just ask it nicely and it'll tell you. If it feels like it. But on the other hand...
• Prototypical Languages also have a debt of history to SmallTalk. One thing that gets classical developers stressed out when they learn “deep” JavaScript is that you can modify objects in real time by changing their prototype. This is a SmallTalk feature. If you don't like the current class of an object you're using, feel free to modify it, dynamically, at run time.
• Pharo and Squeak are modern and currently-maintained versions of SmallTalk, and have given rise to intriguing systems like Scratch .

Why Should I Learn SmallTalk?

At the very least, You will gain the benefit my Latin teacher offered. Learning SmallTalk will make you a better “speaker” of all those other languages, because you get a glimpse of where some of your favorite (or least-favorite) features came from.

Just like Latin still has a few people who actually speak it (mostly in Rome), there are still jobs in professional SmallTalk. There's even a “preferred” ^{by whom?} web application stack, called GLASS (GemTalk, Linux, Apache, Seaside, SmallTalk) that you can use to write real websites with all the modern bells and whistles.

But you're more likely to get hired to write or maintain websites in PHP and Laravel, or Java/Spring or Ruby on Rails or Python or....

Even in this case, SmallTalk can still be useful to you for your actual job, because prototyping an application in SmallTalk is fast. The general process is:

1. Grab the latest image for your favorite flavor of SmallTalk
2. Open it
3. Write some tests
4. Write your code from those tests

You don't need to mess around with setting up your toolchain and build process, there isn't a build process. Code is live instantly, all the time. Package management is included, but most of the packages you need will be included by default in your new image, up to and including version control (with or without git) and deployment tools.

This is because people have spent more than 40 years refining and polishing the SmallTalk-80 paradigm into something very clean and easy to use. Apple poured a lot of time (and some money) into Squeak before finally turning it open source. The Pharo project seeks to move SmallTalk forward, even if they don't exactly call it SmallTalk any more. Most of what you want to do is easy to do in SmallTalk. Many people have done parts of your new idea. Then they created elegant packages to help you out. Then they documented those packages and created a test suite for them to boot, because that's what “good SmallTalk” code looks like. The pace is very different than the endless glut of fancy new JavaScript frameworks; it's not uncommon to use a package that is decades old, with only a few thoughtful changes over the intervening years. So you can sketch out your new idea in SmallTalk, starting with the tests, and figure out if your idea was sound. Then you've got a huge boost on creating it in your employer's development stack of choice.