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...
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.)
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."
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?
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.
As for other descendants, ruby is of course deeply inspired by smalltalk.
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.
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.
> 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.
[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.
It also once seemed like "object-oriented" would be important. Now it is recognized as a niche technique.
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.
> 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.
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.