Why Aren’t People Using Smalltalk?

Examining the oft-quoted reasons

Smalltalk has a PR problem

Smalltalk is perceived as an old language that is behind the times. Smalltalk is perceived as a market failure. Smalltalk is perceived as having dim prospects for the future and thus not worth investing time and energy in it. It is most difficult to fight bad PR, but I shall try.

Smalltalk is a language that has evolved carefully over the years. However, since there is no de facto language standard (ANSI Smalltalk notwithstanding [1]), improvements to the language have resulted in numerous “dialects.” The resulting market fragmentation has not helped with Smalltalk’s PR. But rest assured, Smalltalk continues to evolve, esp. with the vigorous efforts of the Pharo community. (Pharo is becoming a de facto standard of sorts. It serves as the reference implementation for Seaside and Amber.)

Smalltalk failed to become a mainstream, top-tier language that keeps company with the likes of Java, C#, and Python [2]. To many developers, this is the only definition of success that counts. However, Smalltalk occupies a very successful niche for business clients who value short “time to market” and low software maintenance costs, and developers who prize rapid productivity. The wish of the Smalltalk community is to spread the benefits to the broader software industry. But Smalltalk itself is in no danger of disappearing. “Market failure” is thus a vast overstatement.

The toughest perception to fight is the last one because it is fundamentally true, assuming “good prospects” refer to plentiful programming jobs and broad market acceptance. It’s your standard Catch-22 dilemma. Smalltalk job positions won’t be plentiful unless more people adopt Smalltalk, but Smalltalk will not be adopted in the absence of developer talent and investment.

We Don’t Need Another Hero

Yes, we do. Smalltalk needs some serious marketing to overcome its perceptions. Alan Kay was Smalltalk’s spokesperson many years ago, but it’s time for someone else to step up and trumpet the value of the language and its importance to the software industry. Someone with clout. Who will it be?

Smalltalk missed the boat when it came to the Web

Historically, this is true. In the 1990's, all the Smalltalk vendors failed to recognize the significance of the nascent Web and did not adapt their products accordingly. Java came along and mopped up the market.

However, in the 2000's, Seaside came along and went head to head with Ruby on Rails, Django, Laravel, etc. In some respects, Seaside, with its unique programming model, was ahead of its time, so its success has been somewhat limited.

In the last few years, Amber has emerged to compete in the client-side, browser-based application market (where AngularJS, Ember, and Backbone play). So Smalltalk is no longer playing catch-up; it has largely caught up!

Smalltalk is too different from “conventional” languages

Meaning that it’s harder to learn

“Conventional” languages mean C-style languages (e.g., Java, C#, C++, PHP, Perl, etc.). And Python, Pascal, Ruby.

Smalltalk is, indeed, different, but not so different that a Java programmer couldn’t adapt fairly easily. Both languages have recognizable procedural elements, such as conditionals and loops. Both have OOP in their DNA, although Java’s idea of OOP is more of an extension to Abstract Data Types, whereas Smalltalk is quite a different animal, being solely based on the avant-garde notion of “sending and receiving messages.” The latter stems from Alan Kay’s vision, which has been corrupted into the current status quo of OOP. The status quo is found very wanting when you consider the lost potential that true “OOP” has to offer the software industry.

Smalltalk syntax is so purely simple that it makes the heart sing.

Syntactically, Smalltalk is refreshingly different from C-style languages. The syntax is simple and elegant; many describe it as “beautiful.” (Smalltalk was originally designed to teach children programming. Could adults find it challenging?) Coming from a Java/C#/C++ background is absolutely no impediment to picking up this different syntax. In fact, it’s quite fun to do so!

Why does simple syntax matter? Because a simpler language is much easier to master, and when you’ve mastered your language, you can work at your maximum effectiveness and efficiency.

Smalltalk is also different in that it is typically coupled to a special IDE, a system of “live” objects that confers astonishing reflection capabilities, as well as the ability to alter the code and immediately see the execution result. This is arguably the best thing about Smalltalk and it shouldn’t be dismissed lightly.

Words are inadequate to convey the full meaning of its power. And that’s a problem.

However, the Smalltalk environment also precludes using the conventional toolchain that developers embrace in the realm of conventional languages, which are file-based.

“Source code in files. How quaint.” — Kent Beck

There is no reason why we should be forever beholden to the conventional toolchain. Not when the Smalltalk environment promises so many other unique benefits.

Being different is not necessarily bad nor difficult, unless your mind has completely lost its malleability. Smalltalk should be viewed as a new adventure, a new and exciting learning opportunity.

Smalltalk is too insular

Many developers have a problem with the tightly coupled Smalltalk environment or IDE. They are so wedded to their conventional toolchain that they cannot, and will not, accept the benefits of “live coding” and awesome reflection capabilities. A great deal of Smalltalk’s much-vaunted productivity is due to this live environment.

Conventional developers would rather take a pass on these benefits than forsake the file-based tools they know and love. It is impossible to reconcile such an attitude, so these are developers who will never be won over.

Also, a Smalltalk application is essentially a self-contained operating system that executes within the host operating system of your choice (such as Linux, OS X, or Windows). The application exists inside an “image,” which embodies all the classes and objects you need, including the Smalltalk base. The image runs atop the Smalltalk VM (or Virtual Machine).

Conventional developers would rather take a pass on these benefits than forsake the file-based tools they know and love.

This is not much different from how many modern languages operate. Java, JavaScript, C#, Python, Ruby [3]…applications written in these languages run in a VM. The image is the only distinguishing feature. Many developers object to the image, too, probably because it’s a bit too weird (read: unfamiliar) for them.

An interesting exception is Amber. It’s a Smalltalk that “transpiles” into JavaScript, so it is reliant on the JavaScript VM.

Smalltalk is too slow

Smalltalk is a dynamic language that relies on a virtual machine (which typically JIT compiles bytecode into native code). Thus, it cannot execute as quickly as C++. But why must Smalltalk performance be compared with C++?

Is Python too slow? It, too, relies on a virtual machine (and an interpreter, at that, though JIT compilers are available, eg, PyPy). But this hasn’t prevented Python from becoming one of the most popular languages on the planet. Python is used in an enormous variety of application domains, including:

• telephony infrastructure
• payment systems
• neuroscience
• numerical analysis and engineering
• animation
• gaming backends
• media storage and processing
• operations management
• natural language processing
• Big Data
• web services

Smalltalk is only too slow if you try to use it for ill-suited application domains, such as real-time control systems or high-volume transaction systems. For most typical applications, Smalltalk performance has practically no issue. (I currently use Amber for mobile app development, and it is absolutely wonderful!)

In principle, the Smalltalk runtime can be optimized to execute as quickly as JVM or JavaScript VM. And we know that Java (and JVM) is used nearly everywhere.

Smalltalk cannot scale

That is to say, dynamic languages cannot scale

This presumption is based on little more than ignorance and bias. I am aware of one particular application called JWARS, a battle simulation program written for the joint U.S. military. It exceeded one million lines of Smalltalk code. In terms of performance, it was faster than the U.S. Air Force’s STORM, another battle simulation written in C++ of all things! Unfortunately, the project was killed for political reasons (not unlike Canada’s Avro Arrow program). It was a technical success by any measure.

In my experience, whether or not a project scales has as much to do with good management and architectural design as with the programming language and static typing (the often cited basis for scalability). Static typing may marginally help mitigate the problems surrounding scalability, but it’s no panacea; it has been way oversold. Large projects are difficult to manage at any rate, and if your project isn’t well-managed, then you have much bigger problems than a language that isn’t statically typed. Suffice it to say, Smalltalk can scale, even if it’s not ideal. But then, what language is [4]?

The debate surrounding dynamic vs static typing is highly contentious. In this religious war, beliefs trump the facts (there’s really no research evidence to back up the static typing proponents). Against the static typing dogma, Smalltalk loses.

Damien Katz had a memorable quote:

I just fully realized something that’s been rattling around in my head for a while. Static typing in OO languages isn’t the solution to software complexity, rather it’s an enabler of it. Static typing is like giving a drunk a bunch of breath mints and saying “Don’t drive drunk. But if you must, use these breath mints in case you get pulled over.”

The problem is static typing tends to encourage large, complex framework-like interfaces, instead of the decoupled, modular interfaces everyone desires. The irony is, if your interfaces are small and simple, then static typing offers you very little benefit. Static typing works best when there is lots of complexity, but like breath mints for a drunk, we are just making it easier to get away with what we know to be a mistake anyway.

Smalltalk doesn’t have enough industry support

That is to say, not enough employment opportunities, not enough developers to hire, and not a large enough ecosystem.

This is indisputable. It’s the classic Catch-22 scenario. Without sufficient hiring opportunities, developers won’t pick up Smalltalk. Without a sufficient size talent pool to hire from, companies won’t adopt Smalltalk. Without corporate adoption, there is no incentive to develop an ecosystem.

Historically, all programming languages have faced this problem. In some cases, corporate backing broke the logjam, for example, C#/Microsoft, Java/Sun, Swift/Apple. In other cases, it was serendipity that the languages grew organically into their current standing, for example, Python and Ruby. Still others benefitted from just “being there,” for example, JavaScript, PHP, and C/C++.

The wish of the Smalltalk community is to spread the benefits to the broader software industry.

Smalltalk is reliant on serendipity and the broader recognition of its merits. It also has to fight the historically inaccurate perception that Smalltalk was a failure in the marketplace; a great deal of Smalltalk’s “failure” in the 1990's was political. Smalltalk vendors adopted poor marketing and sales strategies and did not recognize the importance of the nascent Internet. IBM, in particular, was “faked” into switching from Smalltalk to Java, thus losing the opportunity to forge and own the Smalltalk enterprise market.

So here we are today. Only a properly educated public can change Smalltalk’s fortunes. However, this is much easier said than done!

[1] The ANSI standard has been roundly ignored: http://stackoverflow.com/questions/6368337/whats-the-difference-of-ansi-smalltalk-and-smalltalk-80

[2] For historical reasons: usurious licensing costs, expensive hardware demands, company politics. And because of competition from Java.

[3] Ruby borrows some key ideas from Smalltalk, but totally misses the bigger picture of “message passing” and program “image.” Mark Miller explains this well here: http://qr.ae/RFuM8u

[4] Even Python has been shown to scale. There are Python applications up to a quarter million lines of code. (A large application is typically defined as more than 100,000 LOC.)