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:
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.
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.
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.
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.
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.
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.
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
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 .
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.
"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."
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.
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.
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.
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 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.
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 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
65 comments
[ 3.1 ms ] story [ 119 ms ] threadhttps://www.cincomsmalltalk.com/main/
I have been blogging about it recently here:
https://smackeyacky.blogspot.com/
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.
- full instructions on install & first steps at [main cuis repo](https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev)
- ["The Cuis Book"](https://cuis-smalltalk.github.io/TheCuisBook/index.html)
- [cuis docs repo](https://github.com/Cuis-Smalltalk/Learning-Cuis)
- [cuis related repos on github](https://github.com/search?o=desc&p=1&q=cuis-smalltalk&s=upda...)
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.
My personal favorite language that has evolved from Smalltalk is Newspeak. https://newspeaklanguage.org
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.
Hopefully not in the same way that Dart turned out to be so "exciting and interesting" :)
Perhaps a question of expectations: "The big question is whether Google originally intended Dart to replace JavaScript".
https://insights.dice.com/2019/03/27/fall-rise-dart-google-j...
[0]: https://dart.dev/null-safety
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.
because…?
for example…?
Dart 1.0 Optional Types runtime checks
Dart 2.0 Mandatory Types (sound null-safe type system) static checks + runtime checks.
All the key designer from Dart 1.0 left Google shortly after Chrome dropped support.
The language only got rescue thanks to AdWords not wanting to rewrite their stack yet again (they had recently migrated away from GWT).
Afterwards Flutter provided the necessary funding to keep improving the language as they replaced JavaScript with Dart.
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.
http://bracha.org/Site/Papers.html
A simple example of Newspeak and literate programming: https://newspeaklanguage.org/samples/Literate/Literate.html
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.
It is worth asking on the forum to see if there is some exisiting code to show this in practice.
the smalltalk universe is pretty special, the live graphical environment is thrilling and their idioms/culture is also very interesting
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!
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.
https://news.ycombinator.com/newsguidelines.html
Err ... oops ... ;-)
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.
Eclipse grew out from Visual Age series.
Or that Sun repurposed Strongtalk for Hotspot.
This, precisely. Pharo is a fork of Squeak Smalltalk, and Squeak Smalltalk is a direct descendant of Smalltalk-80.
(And a common thread in Smalltalk implementations and versions from Smalltalk-72 to Squeak is the illustrious Dan Ingalls.)
Still, Smalltalk has nothing on Lisp or BASIC in terms of dialects/variants/versions. ;-)
[0]: https://en.wikipedia.org/wiki/Strongtalk
Here is a recent talk he gave about it:
https://vimeo.com/ukstug
First, source files everywhere, including in the root, and routinely thousands of lines long [2] with zero comments in them.
[1] https://github.com/newspeaklanguage [2] https://github.com/newspeaklanguage/newspeak/blob/master/Bra...
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.
Apart from a text editor?
"The relationship of Smalltalk and version control systems [not designed to preserve that Smalltalk way of working] is a difficult one."https://www.google.com/books/edition/Mastering_ENVY_Develope...
https://news.ycombinator.com/newsguidelines.html
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...
http://www.bitsavers.org/pdf/xerox/parc/techReports/Smalltal...
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:
After extensive discussion about limitations of previousefforts, 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.
Limitations of Smalltalk72 reinforced the decision to notdefine the fundamental abstraction of computation using a
programming language. Instead computation should be
defined axiomatically in terms of fundamental concepts including
See the following on how to axiomatically define computationusing the Actors Abstraction:
https://papers.ssrn.com/abstract=3418003
https://papers.ssrn.com/abstract=3459566
Also, see the following video:
https://www.youtube.com/watch?v=AJP1VL7shiI