IT’s Dirty Little Secret
Software development has been mired in ancient technologies for decades. The way we create software today isn’t much different from the way we did it in the 1960s and 1970s. Back then, we used textual programming languages like FORTRAN, LISP, COBOL, BASIC, Pascal, and C whose programs were written using text editors like TECO, QED, ed, vi, and Emacs. We stored the program source code in files and folders. We compiled these programs from the command line.
To ensure that a program worked correctly, we had to test it and if it failed, we had to diagnose the problem, edit the source code to include a possible fix, compile the program, and run it again. And if it failed again, we had to do this all over. This edit-compile-test-debug cycle was time-consuming and inefficient.
Fast forward to 2018. Guess what? We’re still creating software the same way! Except now, we’re using Java, Python, JavaScript, C++, Ruby, Swift, and Golang. We’re writing code with text editors like Vim, Emacs, Sublime Text, Atom, and Visual Studio Code. We’re storing program code in files and folders. We’re still compiling from the command line, even if implicitly within an IDE.
We are still slaves to the edit-compile-test-debug cycle! After more than half a century, we haven’t made any real progress. In this “modern” age we live in, we are effectively programming using stone knives and bearskins.
The Future of Programming
A number of years ago, Bret Victor gave a stunningly powerful talk about his vision for the future of software development. He posited that we need an immediate connection to what we’re creating as programmers. We need to see what happens immediately when we change something in our code, no matter how small the change. It’s rather like editing a photographic image or video, or editing a word processing document: immediate connection between user and result. The key is direct manipulation.
Of course, the edit-compile-test-debug cycle just won’t cut it. One may come to the conclusion that we are very far off from realizing Bret Victor’s vision. However, there is one software development tool that comes quite close, and it was invented 46 years ago!
It’s called Smalltalk and it was the brainchild of Alan Kay and his brilliant team at Xerox PARC. The magic of this tool was in making good use of visual displays and organizing source code in a two-dimensional spatial fashion. You were freed from the shackles of source files containing reams and reams of code. Bret Victor said some things about this, too:
Smalltalk has several key features or qualities that give it enormous power. First, the language is supremely simple and easy to learn. It has all of six reserved words! The complete syntax fits on a post card:
This means Smalltalk imposes virtually no cognitive load on the programmer, unlike languages like C++, C#, Swift, Scala, Java, JavaScript, etc.
Second, Smalltalk has a built-in, live coding IDE and runtime that allow you to conveniently and easily alter your program while it’s running! This is how Smalltalk comes close to satisfying Bret Victor’s idea of direct manipulation during programming and establishing an immediate connection between the programmer and the programming output.
The IDE is graphical, just like Visual Studio and Eclipse but much smaller and simpler to use.
Third, Smalltalk is a pure object-oriented programming (OOP) language. It’s objects all the way down, and objects communicate through messages. This provides a unique consistency and ease of understanding you won’t find in any other OOP language, not even Java or Python.
Fourth, Smalltalk is image-based. The Smalltalk image allows you to save the execution state of your program at any time and resume execution later on from exactly where you left off! This is very similar to how the system image in OS virtualization software like VMware and VirtualBox works. This is also similar to how the web browser’s DOM or Excel spreadsheet works.
Image persistence can be used as a kind of database where all the data in your program is persisted to hard drive. There’s no need to futz around with an ORM or third-party database product.
Fifth, Smalltalk is a reflective language. This means that a Smalltalk program is able to inspect its own structure and computation at runtime. This confers enormous power allowing programs to extend themselves with new classes and methods or ask “who sent this message to me?”
Computational reflection is used to implement a powerful way to handle errors. When an object is sent a message it doesn’t implement, it receives a doesNotUnderstand: message, along with a reification of the original message. There are many things that the program can do with the doesNotUnderstand: message, including extending itself with new functionality!
Now, I know that these features and qualities can be found in other modern languages today, but the most important takeaway is this: Smalltalk is the only language to have all of these in one place. It represents a unique synergy not found in any other language.
It is this synergy that is responsible for making Smalltalk the most productive programming language of note in the entire world, according to this Namcook Analytics study (Table 16, measured by “economic productivity” in terms of number of work hours to deliver 1,000 function points):
- C — 26,273
- Fortran — 22,394
- JavaScript — 15,929
- Forth — 14,636
- Haxe — 14,636
- Lisp — 14,636
- C++ — 12,697
- Go — 12,697
- Java — 12,697
- PHP — 12,697
- Python — 12,697
- C# — 12,309
- Dart — 11,620
- F# — 11,312
- Ruby — 11,312
- Erlang — 10,758
- Elixir — 9,845
- Haskell — 9,845
- Julia — 9,465
- Perl — 9,465
- Delphi — 8,289
- Objective-C — 7,848
- Visual Basic — 7,848
- Eiffel — 7,156
- Smalltalk — 6,879
Imagine, if you will, that the average overall productivity of software development could be doubled, or even tripled, for the entire world. What would that mean in terms of dollars and labour costs? What would that mean in terms of “time to market” and the schedules of software deliverables?
Why wouldn’t this be a Good Thing?
The Second Coming
For those of us old enough to remember, Smalltalk was once a very popular language. It made its debut in August of 1981 on the cover of BYTE magazine:
Since then, Smalltalk directly inspired a number of other OOP languages including Objective-C, Python, Ruby, PHP, Perl, Erlang, CLOS, Dart, Java, Groovy, and Scala. Apple even created a Smalltalk for the Macintosh.
Smalltalk’s popularity peaked in the 1990s when it was the most popular OOP language after C++. According to a 1995 IDC report, OOP language market shares were:
- C++ — 71.3%
- Smalltalk — 15.1%
- Objective-C — 5.7%
- Object Pascal — 4.2%
- CLOS — 2.5%
- Eiffel — 1.1%
- all others — 0.2%
Here’s a page from Computerworld, November 6, 1995, showing Smalltalk and C++ duking it out:
Smalltalk was so good for business use that in the 1990s, IBM chose Smalltalk as the centrepiece of their VisualAge enterprise initiative to replace COBOL:
Note that IBM did not choose C++, Object Pascal, nor Eiffel.
In the early 2000s, the U.S. joint military used Smalltalk to write a million-line battle simulation program called JWARS. It actually outperformed a similar simulation called STORM written in C++ by the U.S. Air Force. That by itself is an astonishing testament to the capabilities of the language.
Nearly four decades later, Smalltalk still enjoys far more commercial usage than any of the “new” languages we hear so much about (for example, Clojure, Crystal, Dart, Elixir, Elm, F#, Haskell, Haxe, Julia, Nim, Rust). Cincom, Instantiations, and GemTalk are major Smalltalk vendors. Between them, they have many prominent enterprise users:
- JPMorgan
- Desjardins
- UBS
- Florida Power & Light
- Texas Instruments
- Telecom Argentina
- Orient Overseas Container Lines
- BMW
- Siemens AG
Just to name a few. In my home country, Smalltalk is used by Communications Security Establishment (CSE), Canada’s national cryptologic agency.
Pharo, a Smalltalk modernized for the Twenty-First Century, has prominent users too, for example:
Smalltalk is endlessly versatile:
- Smalltalk is good for data science and numerical computing, thanks to PolyMath and Roassal (also see Numerical Methods with Pharo)
- Smalltalk is good for Internet of Things and robotics (for example, Raspberry Pi and ESUG on robotics)
- Smalltalk is good for ERP (enterprise resource planning)
- Smalltalk is good for machine learning and neural network processing
- Smalltalk is good for natural language processing
- Smalltalk is good for virtual reality (example, 3D Immersive Collaboration)
- Smalltalk can even be used to script the Unreal game engine
- Smalltalk is being used to fight Ebola!
- Smalltalk is used in wide-scale data visualization for medicines in 16 countries
- Smalltalk can be used to write cross-platform mobile apps using Apache Cordova
- Smalltalk is good for server-side web development, thanks to the Seaside web framework and the Teapot micro framework
And I’ve just barely scratched the surface!
After two decades since Smalltalk peaked in popularity, it is high time we gave this language a second look. It just might revolutionize software development for the first time in half a century.
