Byte Magazine Special Issue: Smalltalk (1984)
archive.org
archive.org
Thinking back on all this, I am astonished once again at how much has happened in computing in my lifetime (I am older than FORTRAN, e.g., so essentially all code every compiled has been compiled in my lifetime, unless you want to count Autocoder macros as compiled code).
Previous discussion: https://news.ycombinator.com/item?id=14333157
Smalltalk and Erlang are my next choices. Same reasons as LISP.
I was exposed to image based through Pharo, and I've found the idea to be awesome, as it allows very tight feedback loops on development. I see people complaining because it was nontrivial to extricate a finished program from the environment and ship it to customers in a "tamper-proof" opaque form. What puzzles me is why didn't Smalltalk play a bigger role on the ascension of free and open source software, given what was a bug for proprietary shops (hard to ship a opaque binary) is actually a feature for copyleft development (fully inspectable source code together with full development environment included by default). The GNU-Smalltalk development appears to be mostly stale. The torch of free smalltalk is carried most by Squeak and Pharo today.
1. Information (and source code) was not so freely available as it became even by the mid-90s, when the internet itself started approaching ubiquity and the Web provided much greater access to information.
2. A large part of the OSS movement has long focused on replacing Unix-like OSes with a FOSS Unix-like OS, which eventually meant GNU/Linux becoming the dominant system people rallied behind. This focus carries with it a language focus, C.
3. Smalltalk in the 80s and through most of the 90s was not easily used freely, and implementing it carries its own costs even if you have people interested in it. Without the common experience of having used it, there is less of a desire to create a free version of it (see 2, the common UNIX and Unix-like experience shared by OSS developers molded and directed the movement, even if not consciously).
If the Internet had been more widely available, Smalltalk more widely used and free (or at least much cheaper), then maybe we would have seen a different outcome.
But it's not just that.
The image was actually a big turn off even back then, even before source control was even a thing.
Even today, Smalltalk runtimes (e.g. Pharo) are extremely slow compared to other languages, now imagine how slow Smalltalk was forty years ago... I can tell you, it was very, very slow (I used it on NeXT back then). I'm talking "watch the window draw with your naked eye" slow.
Sadly I have this experience on a daily basis with Windows 10's file explorer. I ran XP in a VM today and was amazed that explorer windows not only open instantly, but fully drawn. In W10 it takes half a second to even respond, and then another half second while it draws the UI elements one by one.
It doesn't feel slow to me. I regularly use the VM on a Raspberry Pi and the GUI is snappy. On that same system I even use it to solve algorithmic puzzles, and I've been more often surprised that it isn't as slow as I had expected.
So yeah, I'm sure it isn't the fastest language out there. However, "extremely slow" compared to other languages? It beats Python and Ruby most of the time. [1]
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
"… it is possible to write time critical, real-time applications while still maintaining access to the user-interface facilities of Smalltalk. In the ESM testbed, C language support has been provided both by a package of C-to-Smalltalk communication primitives, and by high-level C code debugging facilities accessible from the Smalltalk environment."
1987 "USING OBJECTS TO DESIGN AND BUILD RADAR ESM SYSTEM'S" p200
Nothing, because I never said anything of the sort.
What I did say was that Smalltalk has always been very slow compared to other languages. It was true decades ago, it's still true today.
March 7, 1988 — "Smalltalk/V 286 is available now and costs $199.95, the company said. Registered users of Digitalk's Smalltalk/V can upgrade for $75 until June 1."
https://books.google.com/books?id=CD8EAAAAMBAJ&lpg=PA25&ots=...
> … I can tell you, it was very, very slow…
And of-course you used the Smalltalk profiler to fix that?
Here's the "Smalltalk/V 286" Digitalk License Statement —
http://stephane.ducasse.free.fr/FreeBooks/SmalltalkVTutorial...
And by 1991, with Smalltalk/V Windows and Smalltalk/V PM — "Smalltalk/V code is portable between the Windows and the OS/2 versions. And the resulting application carries no runtime charges. All for just $499.95."
(Advert on the last page of "The Smalltalk Report")
https://rmod-files.lille.inria.fr/Archives/TheSmalltalkRepor...
September 1991 "The Smalltalk Report" p25
https://rmod-files.lille.inria.fr/Archives/TheSmalltalkRepor...
1) source code management
Even ancient Smalltalk-80 provided —
"Within each project, a set of changes you make to class descriptions is maintained. … Using a browser view of this set of changes, you can find out what you have been doing. Also, you can use the set of changes to create an external file containing descriptions of the modifications you have made to the system so that you can share your work with other users.
…
The storage of changes in the Smalltalk-80 system takes two forms: an internal form as a set of changes (actually a set of objects describing changes), and an external form as a file on which your actions are logged while you are working (in the form of executable expressions or expressions that can be filed into a system). … All the information stored in the internal change set is also written onto the changes file."
1984 Smalltalk-80 The Interactive Programming Environment page 461
https://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePr...
2) deployment
Not all software was shrink-wrap — plenty of high-value enterprise software.
A lot of developers significantly younger than me seem to think that source code control was developed in the the last couple of decades, but in fact we did source code control, modular development, and build pipelines way back in the 70s - mostly with home built tools, but the capabilities began to be built out as soon as source code left card decks for permanent residence and in place modification on rotating storage. And SmallTalk was at best hostile to all those techniques.
Strange that you don't mention ENVY/Developer?
Method-level source-code version-control and configuration-management implemented for VisualWorks, IBM Smalltalk and Digitalk.
"Mastering ENVY/Developer"
https://www.google.com/books/edition/Mastering_ENVY_Develope...
Years later, I finally got over the fear of OOP by using languages that let you kind of ease your way into it. Visual Basic was "object based" in that you could use pre-made classes, but had to buy a special version to make your own. Still, understanding the benefits of using classes was a good preparation for making them. Probably the point when I realized that I had been using OOP without knowing it, was when I started doing some moderately complicated programs in LabVIEW.
BASIC cast such a shadow over the 8-bit era that no other scripting languages were really significant on micros in the 1980s.
In the early 1990s there was Perl, TCL and Lua that came in with the 32-bit age. Visual Basic was particularly interesting because it was tied to an object model that was bigger than Visual Basic itself. That is, you could write COM components in a language like C or C++ and script them in VB. For that matter circa 1990 there were quite a few scientific programming systems that revolved around scripting languages like MATLAB and IDL.
LabVIEW, however, is in a special category of systems that represent a (usually) real-time calculation with a graph of operators. This kind of system is particularly prevalent today for sound synthesis.
Its main effect on the world, aside from being the implementation language for the Xerox UI that was demonstrated to Steve Jobs, seems to have been via its influence on the language Self, which then influenced Javascript. And here we are.
It also once seemed like "object-oriented" would be important. Now it is recognized as a niche technique.
> A second phase would almost certainly involve some programming in order to set up a real system at CERN on many machines. An important part of this, discussed below, is the integration of a hypertext system with existing data, so as to provide a universal system, and to achieve critical usefulness at an early stage.
> (... and yes, this would provide an excellent project with which to try our new object oriented programming techniques!) TBL March 1989, May 1990
Objective-C had a wonderfully pragmatic approach to OOP, though it remained tied to the systems it was on because of the standard object libraries that enabled it. NeXT promotional materials really liked to showcase its suitedness to rapid application development, whether Jobs himself doing so [1] or in a staged competition with Sun [2]
[0] https://www.w3.org/History/1989/proposal.html
Hypertext systems preceded it by decades.
Objective-C has great as it might have been, didn't brought much to the table to those used to the Windows or Mac IDEs for GUI development.
The Next vs Sun marketing video wouldn't have been the same when placed against HyperCard, Visual Basic, Delphi or C++ Builder.
NeXT was almost bankrupt when they were pivoting into OpenStep, and not only was Java born out of Objective-C influences at Sun during the OpenStep days, Java EE was born from the ashes of an Objective-C framework for distributed computing at Sun.
The way dynamic code works (classloader, reflection), methods being virtual by default, interfaces, the JAR archives (think NeXT app bundles),... all that is Smalltalk/Objective-C influence.
[1] https://www2.eecs.berkeley.edu/Pubs/TechRpts/1986/5376.html
Hard to believe, given that optimizing native code compilers for Lisp were already available.
> Strongtalk is a major re-thinking of the Smalltalk-80 programming language and system. While retaining the basic Smalltalk syntax and semantics, it contains a number of significant advances, including:
> The Strongtalk system was developed in secret in the mid-90's by a small startup company. Before the Strongtalk system could be released, the company was acquired by Sun Microsystems, Inc. to work on the Java® virtual machine.
The only one I ever hear of nowadays is the "visitor pattern".
Anti-patterns have more sticking power. Arguably all patterns are anti-patterns, since each identifies something one's language is too weak to capture in a library. As C++ got more powerful, the patterns vanished into ordinary library components.
-- Peter Norvig
- Factory functions, as seen everywhere, even if people don't bother thinking of them as such;
- Memento pattern, a common way of implementing undo-able actions in applications that need it;
- Proxy pattern, frequently used when you have a code-generated client that talks to a server from a template. Like generating REST/RPC client code that matches a server spec;
- Visitor pattern, but you already mentioned that... but ironically enough, if you have pattern matching support in your language, it's much easier to use that.
And that's just off the top of my head. If you use any of these you're no architecture astronaut, nor are you gilding your lillies.
For the younger generations, the whole set of Visual Age IDEs were written in Smalltalk, SOM (the OS/2 COM like OOP ABI) had support for C, C++ and Smalltalk, making Smalltalk the kind of OS/2's .NET.
Then Visual Age became Eclipse, and the Smalltalk business pivoted into Java.
Interestingly OTI (which was purchased by IBM in 1996 and did all the Smalltalk/Visual Age and later Eclipse) had a VM that could run both Smalltalk and Java bytecode:
in order to accomodate Java execution, OTI developed what was called the UVM (or Universal Virtual Machine) whcih could execute both Smalltalk and Java byte-codes, and used Smalltalk to implement the Java primitive functions which were implemented in C in the Sun JVM.
https://web.archive.org/web/20090611013334/http://talklikead...
As for other descendants, ruby is of course deeply inspired by smalltalk.
Toit has blocks (lightweight closures), single inheritance, everything-is-an-object (no primitive types).
Like Smalltalk the Toit VM is dynamically typed, but unlike classic Smalltalk there are optional types and they are checked at compile time and run time if you choose to use them.
The syntax is not much like Smalltalk though, and development is with conventional source files and compilation, not image based like Smalltalk and Self.
(In Self the editor was inside the VM and you saved your work by snapshotting the entire VM state which is superficially attractive but makes it really hard to collaborate and use version control.)
We used to think Ruby would turn out to be important. Then it didn't, and Python reclaimed its niche. I have probably heard of Toit before, but am unsure.
Snapshotting your VM state as the way to deliver programs was probably Smalltalk's chief failing.
> the way to deliver programs
To judge whether that could be successful, we need to be more specific — deliver what kinds-of programs to what kinds-of end-users?
That doesn't seem likely, that wasn't the recommended approach to managing source code in Smalltalk — but I have no personal experience with Self.
Seems like it might depend on which version of Self is being discussed.
"To briefly recap, the Self transporter allows the programmer to take a program that adds some functionality to a snapshot and move that program to another snapshot. It accomplishes this task by writing the slots that comprise the program to a source file that can be read in and evaluated in the new snapshot to recreate the program."
Perhaps you mean because of prototype inheritance? But the form in JS doesn't look anything like the form in Self. Or particularly thought through at all, really. I fear that Eich may have implemented prototype OO by accident almost?
I have a whole book on prototype OO from the 90s, and the languages in there are much better thought through (Self wasn't the only one or the first one. Actually even Smalltalk 72 is kind of prototype-OOish).
In other respects, syntax and scoping model etc, I don't think original JS looks anything like a Smalltalk-descended language.
I think Eich's own words may be helpful here: https://brendaneich.com/2008/04/popularity/
Maybe it was accidental, but he refers to it as being Self-ish. And refers to it as "a quickie love-child of C and Self".
And of course Self's JIT/VM evolved into HotSpot and probably influenced most future VMs including JavaScript.
Lisp probably counts as the first major language to have OOP, and along with Smalltalk, was the language that introduced OOP to the wider programming world. Bjarne Stroustrup knowing about Simula (which was always a little esoteric) and trying to turn C into a Simula-like language, is more the exception. Most OOP languages today can trace their OOP heritage to CLOS.
[1] https://en.wikipedia.org/wiki/Common_Lisp_Object_System
[2] https://en.wikipedia.org/wiki/Flavors_(programming_language)
I'm extremely dubious about this claim and cannot think of any mainstream OO language this applies to (clearly not C++, Java or C#, nor of course Smalltalk, hence neither Objective-C nor Self nor Javascript).
For further context: I learned about programming languages, did programming language research starting in the early 90s. CLOS, and multiple-dispatch especially were always a significant outlier.
Simula, Object Pascal, C++, c#, ... (class based OOP with virtual functions)
Smalltalk (message passing, classes)
Lisp/CLOS (generic functions) -> Dylan, Perl, Julia, R, ...
Actors, Self, JavaScript, ... (Prototypes)
....
https://interlisp.org/saved.html#history
Besides Common Lisp, the only languages that have anything on their object model that resembles CLOS are Dylan, Clojure and now Julia.
Regarding R and Raku I cannot say anything, but the CPAN package for OOP extensions I used back in 2000's wasn't it.
But Moose is largely influenced by CLOS.
https://www.perl.org/about/whitepapers/perl-object-oriented....
some comment here on Hackernews :
"Moose is back-ported Perl6 objects, which borrows heavily from CLOS and the concepts introduced in the Smalltalk traits paper. This is a bit of a simplification of the history, but the ancestry is present, documented and obvious."
A quick search gave me Moose, Moo, Class::Accessor, Class::Tiny.
So kind of hard to make it the Perl OOP way.
Sorry, I have to correct you on that. Or rather, clarify the proper construction of it, which is: narrow.
In https://www.albertcory.io/inventing-the-future, I talk about Smalltalk a lot. It was not used for the Xerox Star, and there was only a limited demo of the UI done in Smalltalk. No one seriously considered building Star on it.
However, you're right in that the PARC demo to Jobs did make heavy use of Smalltalk. That's because the demo was done by PARC and not by the Star developers, and they showed him the ideas that inspired Star, ideas that had existed for years before he came.
According to the Arbiter of All Things, the demo was in 1978, and Star came out in 1981.
https://www.albertcory.io/inventing-the-future to immerse yourself in that world.
* https://news.ycombinator.com/item?id=20014281 (2019, 42 comments)
* https://news.ycombinator.com/item?id=8391400 (2014, 16 comments)
* https://news.ycombinator.com/item?id=7052479 (2014, 32 comments)
8/77 - APL
8/78 - Pascal
8/79 - LISP
8/80 - Forth
8/81 - Smalltalk
8/82 - Logo
8/83 - C
8/84 - Modula 2
8/85 - Declarative programming
8/86 - Object Oriented programming
9/87 - Misc programming
And too bad they covered Modula-2 rather than the Oberon system which was (and is?) quite amazing and compact.
I wonder what they would have covered if they'd continued? Maybe.... C++. Objective-C. Ada. Apple languages: HyperCard/HyperTalk, Dylan, NewtonScript... Object Pascal (later Delphi.) Oberon. Scheme. Tcl. Perl. Python. HTML. JavaScript. Ruby. ...
The recently-featured-in-HN BYTE Lisp issue actually included an 8-bit Lisp implementation for the 6800 (though you had to order the full listing separately.) Or you could write your own based on the article.
But Wirth's systems are terrific in general and highly educational. For example, I like Wirth's TRM/RISC5 (not to be confused with RISC-V from Berkeley et al.) processor designs[1] and the Lola hardware description language. So maybe a followup on Oberon/(Wirth)RISC/Lola/etc. would have been justified.
[1] https://people.inf.ethz.ch/wirth/Lola/index.html
Having a system which is compact enough to understand from the gate level to the application level is remarkable. (I'm also a fan of nand2tetris, etc..)
Sad that BYTE shut down for good in 2013.
https://archive.org/details/byte-magazine-1985-05
The August 1986 Byte issue on "Object-Oriented Languages" had another article on Smalltalk that was expanded into a nice book:
In the mid 1990s I tried to get 1979 issues of Creative Computing and couldn't find any academic libraries that could offer them for interlibrary loan.