Design Principles Behind Smalltalk (1981)
cs.virginia.edu
cs.virginia.edu
I think it is the most accessible explanation of the marvel of Smalltalk, for those who were not lucky to work with it during the late 80-90s.
Also I think Ruby is the mainstream language that is closest to Smalltalk today, with the idea that everything is an object and late-binding as much as possible.
One thing I can't help point out is that Smalltalk / Alan Kay's vision of interconnected objects forming a recursive computing system is not the only "true" vision of OO out there. From Simula thru C++ and then Java and C# also are object-oriented (or class-oriented for those who care about the distinction), but they are statically typed. It is also OO because OO is a word, not a mathematical definition, and when people talk about OO, there is enough similarity between all these variations that we consider all of them to be in the same camp. Plus with the growing move towards strict static typing even in interpreted languages, which I think is driven by actual industry needs and programmer preferences than external marketing, it is becoming a disservice to think of statically typed OO languages as being somehow inferior to the true ideal of object-oriented programming.
I wish Ruby had taken Python's spot. When Rails exploded ~2006, I thought it'd become a mainstream language. But sadly it has never been very popular for non-web things, if we exclude Japan.
One reason is probably that the standard Ruby implementation (MRI) was really slow till recently. Smalltalk, on the other hand, had extremely good VMs that served as embryo for the JVM.
I've used Ruby for many big projects (but never used Rails!) and it has scaled really well for large and exotic things such as abstract interpreters.
Personally I don’t use Ruby and prefer Python instead, but the book was very enjoyable nonetheless so I would recommend that book to anyone, even to people like me who don’t really like Ruby in general and don’t really want to read or write Ruby in general.
Stuart, T., 2013. Understanding Computation: From Simple Machines To Impossible Programs. O’Reilly.
Book website: https://computationbook.com/
0 - https://www.amazon.com/Enterprise-Integration-Ruby-Maik-Schm...
And functional programming is no good as a general programming paradigm because:
1. Little of computing--almost nothing--is declarative. That means functional programming's non-general by definition.
2. Programming cannot be married to mathematics despite what formal proof proponents and people who think naming their language "Pascal" is a good idea think. It will always be an arranged and sham marriage.
3. Thinking being able to easily execute your declarative programs in parallel means you'll never have to think concurrently and can just outsource everything to Hadoop only means you can't understand the difference between parallelism and concurrency.
I must say that I have trouble reconciling this with the fact that every single GUI program running on my computer right now is written mostly in C++ with a bit in C for my WM and a bit of Rust for Firefox.
But more from a user developer point of view. Power user.. power users aren’t here anymore
No, it depends on what you're doing. Always does, always will.
> Even in ... GUI programming, ... OO is a failure because interactive programs are extremely concurrent
Seems to work well for me on windows. What's the problem precisely?
> And functional programming is no good as a general programming paradigm because ... Little of computing--almost nothing--is declarative
That's just wrong.
> Programming cannot be married to mathematics...
You give no evidence despite it being a long association.
> Thinking being able to easily execute your declarative programs in parallel means you'll never have to think concurrently
Yes, because concurrency only becomes an obvious issue when state is involved. So FP sidesteps that by not having interacting state. I have some criticisms of FP but this is plain silly.
You're just dissing stuff here. It's annoying.
* Artificial general intelligence * Operating systems * Video games * Emulators for hardware * Interpreters * Debuggers * Word editors * Image editors * Graphical user interfaces * Robotics * Web browsers * Servers
Basically everything that makes computing interesting is non-declarative and concurrent. Financial math on K street, parser combinators, and SQL queries are the declarative segment of programming.
Declarative/imperative are models, not necessarily implementations (although they often are treated as model x = implementation x). You need to separate the two conceptually, but in implementation you can do both. Anything you can do declaratively you can do imperatively and the reverse.
As such it makes it meaningless to say that almost nothing is declarative because how you choose to create it is a choice. How well it runs is another matter because real hardware is relentlessly state-y, but that's an implementation issue. And that's fine, and sometimes imperative stuff is just cleaner.
But you can write a web browser or a GUI or whatever declaratively, but underneath it will be imperative because that's hardware.
Declarative vs imperative is a choice, not necessarily a 'natural' thing, (depending on the problem, I'd say a web page renderer is distinctly stateless - take some static HTNL, render it, where's the state?). A web server can be stateless too, a request comes in, a web page goes out. I need someone else to speak for others, pretty sure stateless GUIs have been written.
Any big data cruncher that works on petabytes, purely with output coming from input deterministically is effectively stateless.
> “oh, that’s obviously stateful and imperative” merely because they haven’t thought about the problem in a different way.
No I am not a conventionalist.
Since turing machines are turing complete, and existing general purpose CPUs are turing complete, this is trivially incorrect.
> That's why computer scientists invented I/O automata ... those items on my list
wat?
Where it's needed such as in modelling the very important implementation detail of parallelism on multi-core machines to ensure correctness (such as with model checkers like Spin) then stuff like buchi automata are used, but that's dragging maths into the real world to solve real world problems. Turing machines don't live in the real world.
Please just stop.
But this is all naval-gazing anyway. What's even the point of a purely-declarative OS when it's either gonna:
1. Act as a glorified C preprocessor for an imperative language like Haskell and its do-notation?
2. Look like brainfuck?
Typically declarative systems are interesting because it is easier to prove strong properties about them.
Imperative programs are so popular among "joe schmoe" average programmers because they have a clear teleology. People are willing to forgive that imperative programs are harder to formally reason about because they make the teleology clearer. But have you seen declarative code? Because it's like math formulas, each function needs the same kind of documentation in order to understand the teleology behind the function.
Even the Xerox manuals contain several examples.
1. https://www.youtube.com/watch?v=QM1iUe6IofM
2. https://www.youtube.com/watch?v=ljx0Zh7eidE
3. https://www.youtube.com/watch?v=vrRCY6vwvbU
4. https://hopl4.sigplan.org/track/hopl-4-papers#List-of-Accept...
Looks like there's another Smalltalk paper, too:
Abstraction is overdone. Sometimes the simplest implementation is a function. Not a class.
Inheritance is a failed idea of code reuse because it leaves the code brittle.
You can develop GUI apps without OOP - Tcl / tk and some game programming guis are done that way. All that you need are callbacks essentially.
Polymorphism is essentially overloaded functions and you don't need OOP to support that.
Classes as concept, are nothing more than extensible modules, and in that regard C and Assembly are pretty much the only mainstream languages that eschew such abstractions.
You can also develop GUIs in Assembly, and I don't miss doing that.
Interesting that you mention Tcl/Tk, given the OOP extensions that were all the rage when version 8.0 came out.
Julia implements polymorphism without OOP. Modules are better than classes anyways. The whole Java ecosystem tried so hard to bring modules back as components and failed miserably.
If we are going to talk about all types of interfaces then OpenGL is a clear winner. That last time I checked it uses a procedural interface and vertex buffers directly. Why a procedural interface ? Because OOP is incapable of dealing with any complex data structure other than lists in a performant way.
C++ and Java don't break anything that a bad designed module won't be doing as well.
OpenGL a clear winner?!? The 3D API that should never haven gotten outside SGI with its global variables and state?
OpengGL is faster. Procedural code is always faster. Global variables are infinitely better than pretending problems vanish with singletons and AbstractFactoryMakerProducer. I remember going from C++ to Java, what a joke. C++ is infinitely better than Java because it doesn't suffer from OOP monothinking which is beyond pathetic. It was the first time I realised programmers would repeat marketing slogans without verification.
OpenGL is a garbage API that I repent having spent so many years dealing with its Frankenstein API design.
Fast? Only if you happen to use the magic incantation of data structures and the driver happens to play ball.
There is a reason why all modern 3D APIs are object based, including Vulkan with its handle model.
OOP based C programming is used all over the place in the Linux kernel, in spite of Linus opinions regarding C++.
You can almost backtrack all the horrible decisions in C / C++ and compare it to wirth languages which tried modular programming, bounds checking ....
> Vulkan with its handle model
That sucks. The performance is going to be slow. It's possible they did not go full OOP because of performance.
> OOP based C programming is used all over the place in the Linux kernel
Nope. They implement interfaces / modules using structs. Again, no inheritance and "classes". The most popular example being drivers and filesystem.
Also in case you have missed, all proprietary 3D APIs are either OOP or object based.
I wonder where is the OpenGL C implementation that will outperform LibGNMN.
By the way, one of the reasons why OpenCL failed to gain market shared was its focus in C, instead of the nice C++ libraries provided by CUDA.
When Khronos woke up and decided to offer such APIs, it was to late, now we have OpenCL 1.2 renamed as OpenCL 3.0, and SYCL is being re-designed to be backend agnostic.
Again, OOP is not 100% about inheritance.
It seems some people keep not learning what OOP is all about and relate OOP <===> Java.
Linux kernel uses components, not objects.
The ideology of OO is using classes and inheritance to design software. It is an abysmal failure of software engineering, only mediocre managers use OO anymore and pretend visitor pattern is still a thing. All successful OOP projects use components in a disguised form and use a separation between Data (Value Objects, POJOs) and Code (Services). All failed OO projects use classes and take 3 years to deliver even the dumbest of software.
SELF, BETA and JavaScript don't use classes yet are OOP.
VB originally did not do inheritance and yet it did provide another OOP approach.
Plenty of other languages can be looked upon on SIGPLAN.
Speaking of failed OOP projects, Web DOM, Android, iOS, CUDA, DirectX, LibNMN, LLVM, Metal are indeed such a colossal failure, what were they thinking.
In case you are lacking CS literature I can give you some hints.
You can just read this wiki ...
https://en.wikipedia.org/wiki/Modular_programming
Modularity is the very fabric of most engineering disciplines. As opposed to that, OO is a holistic "ideology" about using classes and inheritance to design software. I call it an ideology because despite its abysmal failures people still refer to it in positive terms.
Apart from Android not one software from the list uses inheritance and classes. OO has shown a narrow success in GUI.
In C you don't have modules and interfaces, so what you do is define a struct with pointers. Now you can compile any .c file which follows this interface and dynamically load it into the software.
Python / Perl / Javascript / Ruby ... support this. Remember how much code is resused in the packages downloaded when you do pip install ? Thank modules for that. Not OO. Because of duck typing these dynamic languages don't need interfaces but you can find code snippets that implement it with keywords like pass.
In modular coding you get libraries, extensions and plugins. I find it sad not many people use these terms and prefer to honk OO every time.
If you're talking about ML-style modules, that really can't be farther from the truth, both in theory and how they're used in practice.
Modules can be used (among many other things) to implement abstract data types, which are conceptually a bit easier to compare to objects[0]. Then you'd have to go into structural vs nominal typing, functors vs generics, etc.
[0]https://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOO...
"Use Squeak!"
"No, Squeak is old! Use Pharo!"
"Pharo doesn't adhere to the Smalltalk standard. Just use gnu-smalltalk in a terminal!"
Never have I seen such a self-defeating community. If the Smalltalk community wants it to be anything more than a historical curiosity, I beg it to form some kind of standards committee and agree on a common implementation so that I can learn Smalltalk without worrying that I'm studying a dialect that is not mutually intelligible to the other implementations.
Joking aside, it's an entirely understandable sentiment, but Smalltalk is not only an old language, but also one that lives in a symbiotic relationship with its tools (which defy the normal notions of language standardisation).
As things stand, if you want a standard, what you're likely to get is a time-capsule. Pharo in particular does not want to be a time-capsule, and while it's certainly been a source of frustration to me that Pharo has existed in such a state of flux for so much of its life, I understand that the change is necessary, and I remain cautiously hopefuly about the direction they're taking.
I'm not a daily user of Pharo, so while I have a rough idea that it is becomming more settled as time passes, I'm not an authority here.
See the many Unix clones before Linux. The difference is that Linux came along when you had GNU code to avoid having to implement ls, ps, etc yourself, you had many people with 386 PCs and you had the Internet to work together without having to be all in the same room (not to mention not having to set up a company to sell CD-ROMs, though other people did that for Linux).
By the time languages like Python and Ruby came along it was a different world and they could be more Linux-like in terms of community and less QNX/Coherent/Idris/BSD/Irix/AIX/Solaris/...
Putting a splintered community back together is not an easy task.
Note that Squeak, Pharo and Cuis deviate from the ANSI Smalltalk standard in the same ways (Traits, {....} syntax for runtime collections).
At the same time Forth has had an unofficial standard as soon as 1979 (Forth-79 followed by Forth-83) before the official ANSI standard (1994).
Actually, a splintered community is not an entirely bad sign. It means that there is no monopoly and that the sub-communities are wealthy enough that they don't need to make compromises with their siblings in order to survive.
https://www.youtube.com/watch?v=BDwlEJGP3Mk
His blog is also great to follow as a general programming blog, and as it turns out, he wrote a post just two weeks ago where he rehashes some of the content.
https://gbracha.blogspot.com/2020/05/bits-of-history-words-o...
(scnr)
From my perspective as someone learning about it post 2015 is that the really killer “feature” is the ability to modify anything anywhere while the image is running. But this is also the feature that makes it so impractical. You start to realize as you are tinkering how simple and elegant it is and how much modern tooling really gets in the way. But this is all based on it being built up upon itself and all the magic of this sits in an environment that’s so foreign to other tools it always feels awkward to interface with them.
Its rejection of static typing is not axiomatic, merely an expedient way of achieving those interactivity goals. Could the two things be reconciled? I don't know, but I think at least that it shouldn't be unthinkable.
As an aside, static type systems which can be mutated during runtime are astonishingly commonplace. They're very crude, and tend to be called "relational databases", and doing those mutations is a major pain because in spite of all that's elegant about relational algebra, actual SQL is a fucking abomination. (And this is coming from a full-on Postgres fanboy.)
On your comment about the similarity of Ruby, I know what you mean, and yet I regard Ruby as being basically nothing at all like Smalltalk. That's because I'm principally thinking in terms of the development culture, tools, and working practices, and not thinking in terms of the implementation of the VM or the object model, or the names of certain methods.
So similarity between languages is a tricky thing to nail down, not least because in the case of a gestalt system like Smalltalk, "programming language" is actually a tricky thing to nail down.
Yes, they can, that was the whole point behind StrongTalk.
Whose JIT technology eventually became the basis for Hotspot.
Globally we go in every aspect against this principle going into narrow specialisations. Such a movement is made on a purpose by the flow of money of central printers/powers, and the result is according to the principle - luck of creative spirit of single individuals. The tools which we are learning and the way we are trained is against creativity.
In last 10y perspective is visible how the industry is mislead in wrong directions by the biggest players. So don't ask why we don't use Smalltak-like technology in 40y.
And the interactivity is awesome once you wrap your head around it. If you haven't experienced it, you most likely won't see the point since you assume much of what it enables is impossible.
I'm still not sold on the image-based dev cycle, Common Lisp allows the same level of interactivity and even more power without giving up files.
They killed it by trying to keep selling it for profit at a time when free alternatives started appearing.
It's a beautiful way to go up and down the ladder of inference.
Basically—Objective-Smalltalk is based on Objective-C which is a superset of C. It's like having the two worlds coming together at the same time.
Does it miss some of the beauty of a totally integrated system like Squeak? Sure. But that's kind of the beauty too. Can we make an Objective-Smalltalk takeover?
This guy is doing some interesting work: https://mulle-objc.github.io
One more factor: my guess is that GNUstep picked the LGPL—which although more permissive than the GPL—turns away the money / status seeking Mac folks.
GNUstep has also moved to GitHub and seems to favor the the MIT license nowadays where possible (e.g., libobjc2)[1][2].
While I understand the overall sentiment, it's a bit odd as a comment on Objective-Smalltalk which runs on GNUstep. For example, the Objective-Smalltalk website (http://objective.st) is served by an Objective-Smalltalk web-server (heavy lifting courtesy of libmicrohttpd) running on GNUstep on a Linux-based Digital Ocean VPS.
I am also currently involved in a project improving lldb Objective-C debugging with the GNU runtime and just contributed to the GNUstep Catalina compatibility effort.
https://www.gofundme.com/f/gnustep-catalina-compatibility
And of course I also instigated writing a major Web CMS in Objective-C on SunOS/Solaris, AIX, etc. First with GNUstep, later libFoundation, though I think they switched back to GNUstep. Always contributing back.
Or Unix as a closet Smalltalk...
"Liberating the Smalltalk lurking in C and Unix" by Stephen Kell
That, combined with the Superbad tools of patching things together make it almost useless these days.
It’s unfortunate, because there’s so much you can do with good interoperability.
1. https://www.hpi.uni-potsdam.de/hirschfeld/publications/media...
:-)
Unfortunately, the internal details of other components are important for performance. It is not enough to know that something is e.g. an ordered collection; I also need to know whether accessing items randomly has an O(1) or O(n) cost. Increasing the complexity from linear to quadratic is not a minor detail that a faster processor would solve.
But when you start caring about performance, suddenly you don't deal with ordered collections, but with arrays, linked lists, red-black trees, and whatever. Then you also get unspecified ordered collections returned from other modules, and you wonder whether it is okay to use them as they are, or whether you should pay a one-time price to convert them to a more efficient collection. And somewhere, a new programmer is crying: "I just wanted to create a list containing dozen numbers, why do I have to deal with all this complexity?"
Looks like they are on the third iteration now:
https://github.com/LivelyKernel/lively4-core
https://lively-kernel.org/lively4/lively4-core/start.html
Apparently now using git for persistence.
Two subtle but necessary and principal clarifications.
1. A reference is not "from that time on". The notion of time must be irrelevant here. The reference is immutable until the process (scope) ends, not in time, just ends.
2. Objects are unnecessary. References and the abstraction principle are necessary and sufficient. Duck-typing is abstraction without an object.
This is what Haskell type-classes captured - to be a _____ is to be able to ______.
Greeks and Platonism plagued OO minds.
> While the presentation frequently touches on Smalltalk "motherhood", the principles themselves are more general and should prove useful in evaluating other systems and in guiding future work.
Indeed the principles of Smalltalk went on to guide the design of many future languages
I always preferred the Generic Functions of CLOS, that allows capturing the semantics of an operation outside the stranglehold of the Single Object pattern.
http://web.archive.org/web/20070101160421/http://users.ipa.n...
I never really dived into a comparison, since I am lacking real Smalltalk knowledge. However, I'd be interested what someone who knows both languages things about SC compared to Smalltalk.
Supercollider has two distinct components – a backend software synthesizer (audio server) and a frontend combining an IDE and an interpreted language which draws strongly on Smalltalk, but is written in a C-like syntax. The front and back ends (typically, but not always, running on the same machine) communicate using the lightweight OSC protocol. It is perfectly possible to use Smalltalk or indeed any other language as an alternative front end to Supercollider audio synthesis engine.
The Supercollider language (sclang) mirrors Smalltalk very closely in some respects, but also has major differences. As in Smalltalk, Supercollider has a metaclass structure and closures which are used to implement control structures. Supercollider makes extensive use of continuations to flexibly sequence musical materials, but is file-based rather than image-based. Smalltalk has far more sophisticated support for refactoring, debugging and programming. For example, it is possible to inspect, manipulate and restart using live objects in the stack after any exception. Smalltalk has a much simpler syntax, a rich IDE, and a wide variety of specialised tools for browsing, refactoring and inspection. In Smalltalk, the complete source code for the whole system is available at all times. Smalltalk has powerful and well documented tools for reflection and modifying the system or changing the model of computation (such as selectively modifying the doNotUnderstand method - though in fairness this is also technically possible in Supercollider). More generally, Smalltalk parsimoniously exploits a small number of principles with ruthless consistency and clarity, making it relatively easy to learn, understand, and if desired modify, any part of the system. Supercollider has a different aim, to provide the maximum power and flexibility for carrying out music purposes to the highest quality. This sometimes leads to trade-offs between clarity and power, and some frameworks whose details are hard to understand. In their contrasting ways, both are outstandingly engineered, seminal languages.
Objective-C has informed Swift.
Long live Smalltalk.
I struggle to find the mapping between Objective-C and Swift, other than "same company" and must preserve backwards compatibility.
Smalltalk became Squeak. Long live Squeak. :)
After Swift was released, I understood why ObjC 2.0 was written the way that it was. It was modified to allow the standard libraries and SDKs to transition to Swift.
I remember coming from C++ (CodeWarrior/PowerPlant), and encountering ObjC, and going "Whiskey Tango Foxtrot?".
After a while, though, I got used to it, and actually started to enjoy ObjC, in a way that C++ never got me.
I enjoy Swift, even more.
After years of writing code in languages I didn't really like (C++/PHP), Swift is something that I actually enjoy. I suspect that Smalltalk, and its affect, are responsible for the "enjoyment" factor of Swift.
I consider most of the lineage to be "in spirit," more than "in detail."
It's quite easy to shoot holes, if we get particular.
The flexibility that's enabled directly by ObjC's simplicity is just not a goal for Swift.