I was surprised to see that Smalltalk-72 was actually a much different language. In some ways it reminded me of Lisp macros and a bit of stack languages like Forth.
This document [0] and especially Appendix II in this pdf [1] explain it well. Essentially an object just gets the unparsed message sent to it for it to do what it wants. So the code for an object basically parses the raw symbols to figure out what message to respond to.
The first Actor languages were inspired by Smalltalk-72 and make a lot more sense if you are familiar with -72 and less for those who only know Smalltalk-80.
Excellent video by Dan Ingalls on the Xerox early history of Smalltalk.
In November 1972, Alan Kay gave an inspiring seminar at MIT
on Smalltalk-72. There were ongoing discussions during the weeks after the lecture about the following:
Dennis and van Horn capabilities
Petri nets
Smalltalk-72
Simula, which was strangely very different from Smalltalk-72
the Internet
etc.)
After extensive discussion about limitations of previous
efforts, we realized that
there is a single abstraction that provided the foundation
for all of computation which it was decided to name the
"Actors Abstraction". The Actors Paradigm covers all of
digital computation and consequently is more powerful than
Church/Turing Paradigm.
Although the use of bitmap displays with Smalltak-72
was very impressive, Smalltalk-72 left a great deal to
be desired as a programming language.
Later Smalltalk designs were completely
different because they adopted the Simula class
hierarchy instead of the byte stream interpreter of
Smalltalk72
Limitations of Smalltalk72 reinforced the decision to not
define the fundamental abstraction of computation using a
programming language. Instead computation should be
defined axiomatically in terms of fundamental concepts including
Actors
Computational Events
Partial order on computational events
Regions of mutual exclusion
Event induction as the foundation for proving properties of Actors Systems
See the following on how to axiomatically define computation
I think messages should be able to carry Actors. But there needs to be a "meaning" to a message. Therefore the message must pass on words and sentences which are the interpreted by whoever receives the message.
Fantastic video. Most of the previous talks I've seen Dan give started with Smalltalk-78 or maybe briefly touched on Smalltalk-76 before spending the bulk of their time on the later versions. So I very much appreciated the time he spent on the early Smalltalk implementations (Smalltalk-76 and earlier) as it filled out the picture of how Smalltalk evolved.
The most active Smalltalk inspired community seems to be Pharo.
https://pharo.org
I have avoided calling Pharo "Smalltalk" as it has evolved from the original fork of Squeak and the project is evolving and modifying from its Smalltalk origins.
The current version runs on top of WASM and can be used in a web browser. Gilad Bracha is going some exciting and interesting things with this language.
IMHO, the claim that pharo is not smalltalk is, to put it bluntly, nonsense.
Yes, I understand that Pharo may well eventually change the some semantics of the underlying language, or at least reserves the right to do so. Fine, call it "not smalltalk" when that happens (if ever).
Until then, call pharo what it is. An interesting, in some ways innovative, FORK OF SQUEAK SMALLTALK.
Its a squeak fork, in the same way that cuis smalltalk is a squeak fork. Both pharo and cuis have evolved in different directions, as per their original directives.
And you know what? Thats fine. Great, in fact. Each can (and does) learn from the other.
And they're both STILL smalltalk. And thats also fine!
I think of Pharo as a bit like Racket: it intentionally is distanced a bit from the parent language to avoid being limited to the design of that language. For example: the word “Smalltalk” isn’t anywhere on the homepage of the project.
I'm not so sure that's the only reason to intentionally distance from the "SmallTalk" brand. There might be a advertising benefit, too, since ST is sometimes maligned for having "lost".
Even without active malignment, Smalltalk is largely perceived as a historical curiosity of primarily academic interest. Even among many people who like it.
Since Pharo wants to position itself as a modern, industrial programming language, it makes sense that the project would want to distance itself from that reputation.
But if you look at the hero myth is the wrong strategy. It's like the immature hero that wants to hide who his father is because is ashamed for some immature reason hence demonstrating that is not ready yet for the challenge of the world. The alternative is, embrace his history, have a clear own identity, and yet come back and rescue his father (not the project but the spirit) "from the belly of the beast" and improve itself and the world by doing so. Not doing it like that will not fit the psychological archetypes of the good stories that marketing needs and fail and waste a lot of effort having at the end of the day to always admit it is a Smalltalk. Not all products can aspire to be legends. This is one that can do it.
"A position (or statement of position) is a cold-hearted, no-nonsense statement of how you are perceived in the minds of prospects. It is your position."
Some people are very picky and only accept Smalltalk-80 as "Smalltalk". Of course, that would make Smalltalk-72, -74, -76 and even -78 not Smalltalk, which would be very odd.
I, on the other hand, consider Self and Slate to be good examples of Smalltalk.
Beyond any technical discussions there is the marketing issue. Smalltalk's reputation took a major hit in the 1990s with the rise of Java (from the "language of the future that doesn't run on the computers you have, yet" it became "a failed language of the past") and association with the name can hurt a project in some cases.
Thank YOU for taking the TIME and EFFORT to attempt to OUTLAW the BARBARIC PRACTICE of using capital letters in written communications, to convey a slightly ELEVATED tone.
The MOOC is great. It was my introduction to Pharo and Smalltalk programming. The focus is on web development, I hope they eventually create a version geared towards data science. I'm still far from mastering Pharo, or any Smalltalk-like languages, but just scratching the surface made me remind that William Gibson quote: "The future is already here – it's just not evenly distributed".
If you're interested in visualization/statistics with Pharo, you should check out Alexandre Bergel's work at http://agilevisualization.com/ .
Alexandre kindly gave a presentation on this topic at the October 2020 UK Smalltalk User Group meeting: https://vimeo.com/473356757 .
I played a bit with Newspeak, in their legacy Squeak-based IDE, but after they migrated to the new webapp IDE, I was kinda lost, in this new environment. I didn't find much documentation about the new IDE. Any recommendations?
The IDE works in a similar way to the Squeak-based IDE, but there is no image and being hosted in a browser has other limitations. This isn't a language you are going to use to make a quick and dirty CRUD app (although I have) but it is an interesting example of how Smalltalk concepts can be used in a web-based world.
Thanks, when I was working on a particularly convoluted React codebase, I realized that it's better to pass dependencies into modules rather than importing them and, when I looked around to see what prior art there was to this idea, I came across https://gbracha.blogspot.com/2009/06/ban-on-imports.html
Not exactly the same direction as Strongtalk, but Herman Wilkinson's "live typing" project does interesting things by collecting type information as Smalltalk runs.
I haven't kept up with Dart, as I kinda fail to see the point right now, so can you elaborate a bit on how you think the current design is going against Gilad Bracha's convictions?
Language evolution is an interesting thing, especially when you've got corporate influence, second system effect etc.
Or simply the need to add stuff, as languages are considered just another product, and otherwise you're considered "stale" in today's market. Weird.
Interesting. I’m a fan of Gilads work, and have a strong admiration for Lars Bak who were both involved in 1.0. I followed it cursorily from time to time and thought it looked intriguing. I had a number of colleagues from the Smalltalk industry that went to work on it.
They’ve all left now (I don’t know what Lars’ involvement is anymore?).
But I was curious about Dart for a cross platform app and learned Dart 2.0 and was wholeheartedly let down. I just felt like I was staring at a Java dialect. The “sanctioned” tutorial I watched introduced classes as a “way of organizing code” which I guess could abstractly be said to be true, but IMO misses the mark entirely.
Anyway, I found Dart 2.0 to be very uninteresting. Very safe and traditional and boring. Maybe I need to relook closer to try and see what you’re seeing that I did not.
don't read too much into what I said, I barely read the async/concurrent primitives they made, it felt different and interesting. I came with the impression that it would be a cuter java (like you somehow) but these bits caught my brain by surprise.
Until recently[0] Dart had pervasive nullability, that is, all types `T` are implicity `Option(T)`. Which in my view was completely unacceptable even in 2011 when it was initially released.
No idea, and I wasn't judging, it's just that on average you'll see 12 languages on articles / news / threads before you see mention of Dart. I heard flutter was solid and quite used but "socially" the mentions are rare.
I don't want to vigorously defend the organization of the git repo, but browsing the source code of Smalltalks is always an issue. The source code is closely tied to the "browser" and for the longest time this was the only way to view the classes contained in an image. At some point mechanisms were designed to serialize the code to source control repos. The relationship of Smalltalk and version control systems is a difficult one.
In the case of Newspeak, I only would edit the raw source code if I had no other way to do it. It is so much easier and ergonomic to use the Newspeak IDE to view and modify the code, with the live debugger, object introspection and all the advantages that the IDE gives you. The recent addition of exemplars, where working fragments of the code are part of the documentation, is especially nice.
The threshold for starting new research projects from scrath is getting much higher all the time. When Smalltalk was developed you could implement most of the software stack in a quite small team in a few years. I’m not sure that is possible anymore if you want to connect to outer world eg. web. You will create dependencies out of your control quite fast. These dependencies will shape design decisions. Lowest common denominator rules and fighting that will take considerable resources and effort. I think this is one reason we are stuck with Unix like file based systems for most foreseeable future
To complement the Pharo recommendation, I would also recommend cuis smalltalk.
It also forked from squeak, but went on an aggressive diet, shedding much complexity in the base image, and modularising (using git) much of the rest.
Smalltalk newcomers may find cuis is easier to "digest" and get to grips with. Having used pharo and squeak myself, I find myself preferring cuis for more serious development. YMMV.
I have been working with Squeak for many years. It's stable, evolving, and always interesting. I'm also a big fan of Cuis, but Squeak is still my personal favorite.
Neither Squeak or Pharo have well maintained website and searching for documentation via google is very hit and miss. Pharo is worth downloading and playing with though. The old, main commercial implemention of Smalltalk is available through Cincom. VisualWorks was just about to take over the object world before Java was released:
This document [0] and especially Appendix II in this pdf [1] explain it well. Essentially an object just gets the unparsed message sent to it for it to do what it wants. So the code for an object basically parses the raw symbols to figure out what message to respond to.
[0] http://worrydream.com/EarlyHistoryOfSmalltalk
[1] https://raw.githubusercontent.com/worrydream/EarlyHistoryOfS...