I came at OOP via NeXT, so Objective-C, then Java, then it was the early 2000s so literally everything was OOP and made you know about it. When, quite a bit later, I started digging deeply into Smalltalk, I had the feeling that Alan Kay was Charlton Heston , looking across the beach at the statue of Liberty, her torch in one hand and “Teach Yourself OOP with C++ in 21 Days” in the other. You maniacs!
This article and the one to which it responds paint a more nuanced picture that’s very interesting. The main thread - OOP was different enough that existing, experienced programmers found it very hard to take advantage of - is still there, but so are a lot of other themes: financial and corporate management pressures, real and perceived performance issues, staffing and the generation of “legacy code”. But as Wirfs-Brock says, Smalltalk won the war even as it lost all the battles. The entire industry has been shaped by OOP, even the parts that explicitly eschew it, and everyone wants you to know how “agile” they are and how they follow the principles of former Smalltalkers like Ward Cunningham, Kent Beck, Dave Thomas and others.
As quietly influential as Smalltalk has been in the ways you mention, there are others: for example, it pioneered the idea of of a language virtual machine, a la JVM and BEAM. (Supposedly Armstrong built Erlang because he couldn’t get access to special-purpose Smalltalk-optimized hardware! A curious addendum to the Lisp Machine story.) It had tremendous influence on the look and feel of desktop GUI’s, all the way down to menus and radio buttons and black-on-white displays, thanks to both Apple’s Macintosh and MIT’s X-Windows projects copying the Xerox PARC’s UI wholesale. Smalltalk’s academic heir apparent, Self, blazed a trail for both prototype-based inheritance and JIT compilation, as well as introducing the subtle animation tricks used in “modern” GUIs.
But despite the influence on languages and user interfaces, hasn’t been nearly as influential in the world of “systems”. Smalltalk originally presented a coherent alternative to the Unix paradigm which has basically subsumed it in current implementations. People tend to think of it as merely a language, which misses much of the original intent of the PARC research. Nicholas Wirth is a notable exception, as usual. Of course, there are plenty of historical and economic as well as technical reasons for things turning out the way they did. But, for people in the OS-dev space who are looking for roads less taken, Smalltalk is well worth some study.
it pioneered the idea of of a language virtual machine
It did this totally by accident. The Xerox Alto ran bytecode. The instruction fetch unit grabbed a byte and then ran the set of microcode instructions in the look-up table associated with that byte. When you implemented a language for the Alto, you provided a microcode table and wrote a compiler that targeted the bytecode that you’d created. Smalltalk and Algol both did this. Implementations of Smalltalk on other systems initially just wrote emulators for the Alto’s bytecode (and Squeak / Pharo are largely still doing this).
The Alto’s microcode engine was designed to do hardware-software co-design on ISAs. The idea was to be able to prototype ISAs and then later build CPUs that were optimised for the set of micro-ops that compilers wanted to generate. This didn’t happen and the Smalltalk VM as a portable construct came about by accident instead.
I’m thinking back to all the arguments against Smalltalk I heard back in the 80’s and early 90’s, and now we’ve ended up drowning in…JavaScript? Worse really is better.
Yes. All the downsides, magnified, without any of the upsides.
Similar to the way people tried to use Objective-C as a pure OOPL, which is significantly slower than even a half-decent Smalltalk, except less expressive, less interactive and more crashy.
And of course Swift manages to be even slower than Objective-C, and you get even less interactivity and expressiveness. Progress!
Similar to the way people tried to use Objective-C as a pure OOPL, which is significantly slower than even a half-decent Smalltalk, except less expressive, less interactive and more crashy
An Objective-C program written in a purely Smalltalk style will be slower than the equivalent written in something like Anamorphic Smalltalk (though still noticeably faster than something like Squeak), but that isn’t what happens. Even programs that are mostly high-level OO things written in Objective-C are using classes that wrap carefully optimised C/C++ libraries. A typical Mac application spends the vast majority of its time in things like the font and graphics rendering engines, which are C.
I’ve written about this before, but I still believe that the thing that killed Smalltalk was the lack of a good way of interworking with non-Smalltalk code. A lot of core bits of Smalltalk were built around the image model, but this did not work with stateful non-Smalltalk libraries. Smalltalk never had a good abstract machine for reconciling the Smalltalk image view of the world with the C process view of the world and supporting both together. With Etoile, we tried to build an object persistence model that gave the advantages of the Smalltalk image model, but played nicely with C. If Smalltalk had gone in that direction in the early ’90s, it might still be a big player today.
Yeah, absolutely agree on interop issue: image, own-world, vm, gc, thread-of-control. Basically an architectural mismatch checklist. :-) Which is why Objective-Smalltalk is also built on top of the ObjC runtime.
However, pure OO Objective-C can easily be slower even than byte-code interpreted Squeak (so pre-JIT), and yes, I measured. And of course a Smalltalk, and particularly Squeak, will also spend a lot of its time in primitives or plugins that do the heavy lifting.
Good Objective-C code doesn’t do that, of course, and can reach just about any performance level you wish that the machine can provide, while typically maintaining good abstraction levels.
IBM seems to have really believed in Smalltalk in the 90s, then suddenly turned to Java, effectively killing Smalltalk as a serious contender. Why was that?
One can speculate a lot of reasons, I’m interested to hear what others think. For me the Smalltalk deployment story was always lacking in that the “image” of the smalltalk system is the deployment unit, not the source code and compiled artifacts. Another thing was that Sun pushed the “run Java anywhere on the network” angle that was really compelling in the 90’s but turned out to be not what anyone really wanted. I don’t think Smalltalk had an answer for that. Those are just two things I recall.
This reminds me of how IBM made an object oriented version of its scripting language REXX, called oRexx (now ooRexx, open source at https://www.oorexx.org/ ), using the message-passing model of Smalltalk. Just a few years later, they release another object-oriented REXX, running in the JVM using the Java model of object orientation: http://netrexx.org/
I came at OOP via NeXT, so Objective-C, then Java, then it was the early 2000s so literally everything was OOP and made you know about it. When, quite a bit later, I started digging deeply into Smalltalk, I had the feeling that Alan Kay was Charlton Heston , looking across the beach at the statue of Liberty, her torch in one hand and “Teach Yourself OOP with C++ in 21 Days” in the other. You maniacs!
This article and the one to which it responds paint a more nuanced picture that’s very interesting. The main thread - OOP was different enough that existing, experienced programmers found it very hard to take advantage of - is still there, but so are a lot of other themes: financial and corporate management pressures, real and perceived performance issues, staffing and the generation of “legacy code”. But as Wirfs-Brock says, Smalltalk won the war even as it lost all the battles. The entire industry has been shaped by OOP, even the parts that explicitly eschew it, and everyone wants you to know how “agile” they are and how they follow the principles of former Smalltalkers like Ward Cunningham, Kent Beck, Dave Thomas and others.
As quietly influential as Smalltalk has been in the ways you mention, there are others: for example, it pioneered the idea of of a language virtual machine, a la JVM and BEAM. (Supposedly Armstrong built Erlang because he couldn’t get access to special-purpose Smalltalk-optimized hardware! A curious addendum to the Lisp Machine story.) It had tremendous influence on the look and feel of desktop GUI’s, all the way down to menus and radio buttons and black-on-white displays, thanks to both Apple’s Macintosh and MIT’s X-Windows projects copying the Xerox PARC’s UI wholesale. Smalltalk’s academic heir apparent, Self, blazed a trail for both prototype-based inheritance and JIT compilation, as well as introducing the subtle animation tricks used in “modern” GUIs.
But despite the influence on languages and user interfaces, hasn’t been nearly as influential in the world of “systems”. Smalltalk originally presented a coherent alternative to the Unix paradigm which has basically subsumed it in current implementations. People tend to think of it as merely a language, which misses much of the original intent of the PARC research. Nicholas Wirth is a notable exception, as usual. Of course, there are plenty of historical and economic as well as technical reasons for things turning out the way they did. But, for people in the OS-dev space who are looking for roads less taken, Smalltalk is well worth some study.
It did this totally by accident. The Xerox Alto ran bytecode. The instruction fetch unit grabbed a byte and then ran the set of microcode instructions in the look-up table associated with that byte. When you implemented a language for the Alto, you provided a microcode table and wrote a compiler that targeted the bytecode that you’d created. Smalltalk and Algol both did this. Implementations of Smalltalk on other systems initially just wrote emulators for the Alto’s bytecode (and Squeak / Pharo are largely still doing this).
The Alto’s microcode engine was designed to do hardware-software co-design on ISAs. The idea was to be able to prototype ISAs and then later build CPUs that were optimised for the set of micro-ops that compilers wanted to generate. This didn’t happen and the Smalltalk VM as a portable construct came about by accident instead.
I agree with everything here except this part, because Wirth already worked on Euler in the 1960s.
I’m thinking back to all the arguments against Smalltalk I heard back in the 80’s and early 90’s, and now we’ve ended up drowning in…JavaScript? Worse really is better.
Yes. All the downsides, magnified, without any of the upsides.
Similar to the way people tried to use Objective-C as a pure OOPL, which is significantly slower than even a half-decent Smalltalk, except less expressive, less interactive and more crashy.
And of course Swift manages to be even slower than Objective-C, and you get even less interactivity and expressiveness. Progress!
An Objective-C program written in a purely Smalltalk style will be slower than the equivalent written in something like Anamorphic Smalltalk (though still noticeably faster than something like Squeak), but that isn’t what happens. Even programs that are mostly high-level OO things written in Objective-C are using classes that wrap carefully optimised C/C++ libraries. A typical Mac application spends the vast majority of its time in things like the font and graphics rendering engines, which are C.
I’ve written about this before, but I still believe that the thing that killed Smalltalk was the lack of a good way of interworking with non-Smalltalk code. A lot of core bits of Smalltalk were built around the image model, but this did not work with stateful non-Smalltalk libraries. Smalltalk never had a good abstract machine for reconciling the Smalltalk image view of the world with the C process view of the world and supporting both together. With Etoile, we tried to build an object persistence model that gave the advantages of the Smalltalk image model, but played nicely with C. If Smalltalk had gone in that direction in the early ’90s, it might still be a big player today.
Yeah, absolutely agree on interop issue: image, own-world, vm, gc, thread-of-control. Basically an architectural mismatch checklist. :-) Which is why Objective-Smalltalk is also built on top of the ObjC runtime.
However, pure OO Objective-C can easily be slower even than byte-code interpreted Squeak (so pre-JIT), and yes, I measured. And of course a Smalltalk, and particularly Squeak, will also spend a lot of its time in primitives or plugins that do the heavy lifting.
Good Objective-C code doesn’t do that, of course, and can reach just about any performance level you wish that the machine can provide, while typically maintaining good abstraction levels.
IBM seems to have really believed in Smalltalk in the 90s, then suddenly turned to Java, effectively killing Smalltalk as a serious contender. Why was that?
One can speculate a lot of reasons, I’m interested to hear what others think. For me the Smalltalk deployment story was always lacking in that the “image” of the smalltalk system is the deployment unit, not the source code and compiled artifacts. Another thing was that Sun pushed the “run Java anywhere on the network” angle that was really compelling in the 90’s but turned out to be not what anyone really wanted. I don’t think Smalltalk had an answer for that. Those are just two things I recall.
This reminds me of how IBM made an object oriented version of its scripting language REXX, called oRexx (now ooRexx, open source at https://www.oorexx.org/ ), using the message-passing model of Smalltalk. Just a few years later, they release another object-oriented REXX, running in the JVM using the Java model of object orientation: http://netrexx.org/