Why No Language Innovations?

Many developers complain that Smalltalk lags behind in language innovations. They point to languages such as Rust and Kotlin and Swift for cutting-edge features. Let’s briefly look at these languages…


The key features are:

  • zero-cost abstractions
  • move semantics
  • guaranteed memory safety
  • threads without data races
  • trait-based generics
  • pattern matching
  • type inference


The key features are:

  • Null safety
  • Exceptions are unchecked
  • Data annotation
  • Builders
  • Functional programming support
  • Extension functions
  • Operator overloading
  • Generics


The key features are:

  • Type inference
  • Option types
  • Protocols (or interfaces)
  • Automatic Reference Counting (or ARC)
  • Generics
  • Exception-handling

Most of these are related to either static typing, or systems programming (e.g., pointers), or OOP extensions, or expressivity (e.g., functional programming). Smalltalk is a dynamic language with garbage collection, and it is definitely not designed for systems programming. Smalltalk’s OOP model is widely considered the gold standard to which most other OOP languages aspire. So what language innovations does Smalltalk need to make software creation much better than it is now?

It does seem to me that the static type-related features are attempting to loosen up the straightjacket that static typing imposes. What was wrong with the static typing that existed in, say, 2002 Java?

In terms of “expressivity,” Smalltalk is exceptional in this respect, as Alan Lovejoy eloquently discusses. Programming in Smalltalk is essentially programming in DSL (domain-specific language). And, by the way, Smalltalk is perfectly equipped for “functional” programming because blocks are higher order functions and closures [1].

Many developers make a big deal out of generics. Not that I ever cared for it (I’ve never used generics in all my 20+ years in IT), but with respect to Smalltalk, David Buck said this at StackOverflow:

Smalltalk is the ultimate in generics. Variables and collections can contain any object. Languages that have “generics” make the variables and collections more specific. Go figure. Polymorphism is based on the class of the receiver. To do multiple polymorphism use double dispatching.

Automatic Reference Counting, as an alternative to normal garbage collection, is not foolproof; memory leaks can still occur. The developer bears responsibility to prevent this, but isn’t this why garbage collection was conceived? Despite the minor performance issue, I’d rather not return to the days when I had to manage memory.

At any rate, research shows that intrinsic language features are of secondary importance when it comes to choosing a programming language. Things like open source libraries and existing codebases are vastly more important. In my opinion, very few intrinsic features conceived in the last thirty years will have any significant impact on the quality and reliability of software, or on the velocity of software development (in which Smalltalk absolutely shines). Improvements will be incremental, at best.

Having said all that, I believe Smalltalk could stand some improvement with respect to programming on multi-core processors. As Pharo continues to evolve, it will doubtless add features as necessary. New features will be carefully weighed, because the haphazard addition of features will only complicate the language unnecessarily. Look no further than Scala, D, Vala, and arguably Rust for examples.

Have a great Christmas, everybody! And I hope you enjoy this present.

[1] Functional programming will never become mainstream, at least, not for a long, long time.