Whelp, didn't make it in time and I can't edit anymore... Here's what I wanted to write:
I don't want to talk about Pharo. Please, don't make me talk about Pharo at length. Even a short summary will be painful... But I'll do it anyway if only to have something to link to in the future.
In short: Pharo is the worst Smalltalk out there, with a community that is small, elitist, and entirely unconcerned with user experience. I once engaged with the community on Discord to say that they could maybe care a tiny little bit more about backward compatibility. I learned that "they do care a lot" and - oh wonder! - they are introducing a framework (brand new, of course) to help fix compatibility issues (something based on pragmas)! I then said, "look, I just opened an image of Pharo 7, went to package manager, and tried to install PetitParser, only to get debugger window pop up multiple times." Stock image. Stock package manager. It worked perfectly fine in Pharo 5. Doesn't work at all now. The response? "Well, that package manager is old and was abandoned," and they are currently (again) rolling out an entirely new way of doing things as fundamental as installing packages. The new tool was hard to find, buried five feet under in menus; the broken, old, abandoned project was left where it was, without a single comment about the deprecation. From my perspective - someone returning to Pharo after a few years apart - something that used to work quietly stopped working. I then heard that I should follow the development closely, and anyway, that's not an example of breaking backward compatibility (in user experience) - it's just... something else, and it "just happens" sometimes. I was then chastised for daring to suggest that a mouse is not, in fact, a requirement for having an interactive, introspective, personal system (which is obvious - you can run Emacs in a terminal, and you'll get the exact thing). I left afterward, not wanting any more of the "support" from the community...
In a tiny world of Smalltalk, Pharo rose to prominence because it was free, and it was used by a few flagship projects as a reference platform (while they were being developed - most of the projects had already died - usually shortly after authors got their PhDs). Unfortunately, these were just accidents of history, yet Pharo's community somehow took them for granted and became even more elitist than Smug Lisp Weenies ever were.
The problem with the user experience was mirrored in the developer experience. Over the years, the churn in frameworks was considerably worse in the Pharo ecosystem than even in the JavaScript world. In such a small ecosystem, and over just a few years, most core frameworks were replaced, sometimes more than once, with the "next versions," "new incarnations," and "reboot projects." Due to Pharo not supporting namespaces, keeping multiple kinds or major versions of a framework in the same image is problematic and can lead to bugs. Without doing that, though, you lose all compatibility with tools, utilities, and libraries written for the older versions. In JavaScript, the number of active programmers lets you expect someone to update and fix those tools so that you don't have to. In a tiny ecosystem of Pharo, you can't expect that - the original author most likely moved on years ago, plus the collaboration tools in Smalltalk traditionally sucked a lot. If you depend on something, you should expect to be the one to maintain it - against a collection of ever-changing APIs all around you. In other words, the Pharo community worked hard to dump everyone back into the "dependency hell" period of the early Linux.
Most of that came from the misguided efforts of the community, but some problems ran deeper than that. Take Morphic as an example. It's a nice - if a little simplistic - UI library, and the reactivity of all the UI elements under it is eye-opening. At the same time, it's relatively inflexible (most suited to animating spinning rectangles) and definitely shows its age. This led to attempt after attempt to extend it with features people expect from modern UIs. Those attempts were hard to implement, hard to use, and mostly unsuccessful - all due to the underlying model's limitations. The user experience suffers because of them, too. For example, I - and probably 99% of other users - want my windows to look like all the other windows on my desktop. Instead, all Pharo windows live in a single OS-level window. Another example: I like how my (tiling) window manager does things and would like Pharo's windows to also be managed by it. No such luck. Problems that are long solved elsewhere in Pharo are being solved again, in a Pharo-specific way. Scaling an interface so that the labels still fit in their containers when I increase the font size is something that Pharo still has trouble with. It took ages to get 4k support. Customizing the key bindings was done ad-hoc in Morphs - last time I checked, there was a new framework that would fix that in the works. It was in 2018.
This case might not be purely due to Morphic; there's a pinch of elitism hidden here: because real Smalltalkers use the mouse! Mouse and mouse only! Using a keyboard is what the guys writing Java do, so it's a "Bad Thing" to do. All the poor sheeple, trying to hold to their home rows: Smalltalk (meaning: just Pharo, there's no other spoon) exists to liberate the ignorant you from the tyranny of keyboards!
I'd write more, but unfortunately, after Pharo 7, the installer broke for me on Linux, and I couldn't run it ever since. The 4th incarnation of the FFI framework (that itself needs an obsolete version of libffi) is used to require libgit so old that I can't get it without compiling it from the source. Neither FFI nor Git should be critical to the whole system, but the image simply fails to run when the libgit is not loaded correctly. That, in turn, is because the 5th incarnation of the source code version management tool, finally, begrudgingly, switched from custom code to Git. That's good in itself, but you should either bundle what's needed with the VM or make the tool optional. But no - for all the backward compatibility caring, Pharo moves fast and breaks things with impunity. It doesn't matter that users will lose interest in both Pharo and Smalltalk at the same time when faced with such an experience.
The funniest thing in all this is that you don't even need Morphic to directly interact with widgets in a system. Multiple other Smalltalks demonstrate that it's possible to seamlessly inspect and modify widgets during runtime in a system running in OS-level windows and using native widgets.
If you want to experience Smalltalk properly, get a personal copy of VisualWorks from Cincom. On Linux, you can also use Smalltalk/X (the "jv branch") - it's still being developed, albeit slower. Both implementations can effortlessly run Smalltalk code written in the 90s. Pharo has problems (but the Next Great Framework, when done, will help with that!) running code from 2 years ago. Both, of course, provide headless modes of operation and had been doing so literally decades before Pharo. Even if you want to witness Morphic and classical Smalltalk experience, don't use Pharo - go for Cuis Smalltalk or Squeak instead.
Obsessed with new and shiny, with things bolted-on on top of utterly inadequate infrastructure, rediscovering problem domains that the rest of the world solved already, Pharo is a trap that is not, and likely never will be, user friendly and stable. On the other hand, it is capable - if you are lucky enough for it to work for you.
TL;DR: There's way more to Smalltalk than just Pharo, and I would recommend basically any other implementation to people wanting to learn it. Visual Works, Smalltalk/X, Squeak, and Cuis, are all excellent choices, depending on your needs. I learned Smalltalk with Pharo, starting with version 1.4. There was a brief period when everything worked, and there was a lot of effort put into documentation, most notably the two Pharo books and some follow-ups. After that, everything went downhill, and for a long time, I thought that's just how Smalltalk development is in general. Seeing and working with other implementations showed me a very different picture, and it caused me to lose all faith in the Pharo project.
Cuis is a really interesting incarnation. It's quite stripped down, and Juan, the creator, has done a lot of work to simplify things as much as possible. He has even stripped down Morphic and has an early working version of its "successor," which is vector based.
The dual problem with the open source Smalltalks is that there aren't enough people working on them, and the community that is working on them is fractured.
> He has even stripped down Morphic and has an early working version of its "successor," which is vector based.
That's very interesting, actually, I didn't know, thanks. Morphic is not a bad idea in itself - the problem is that its implementations are ~30 years behind the times, and slapping framework after framework on it won't make the pig fly. But, rethinking and modernizing the ideas behind the base implementation might be a way to make all those frameworks work properly, finally. I will pay attention to Cuis more.
> The dual problem with the open source Smalltalks is that there aren't enough people working on them, and the community that is working on them is fractured.
No, the problem is that the open source Smalltalk community comes from academia mostly, plus some hobbyists, and they are by and large simply poor software engineers. Smalltalk is capable enough to allow them to get what they want more-or-less working, and quickly, but the code is a mess. The authors then go on to write their dissertations or publish some papers, which generates a bit of interest in the project. But then two things happen, almost every time: a) the author gets the promotion or title they wanted and leave the project; and b) the people who got interested in the project are met with a steaming pile of garbage code that modifies half of the Kernel category for no reason at all, has methods with 100+ lines of code, has complex hierarchies that were abandoned halfway but left in the code, has no or almost no comments, the names of identifiers are incomprehensible abbreviations, and so on. Coupled with "move fast, break things" of Pharo, this results in the project stagnating and then quickly stopping to work altogether, other than with the original image (if you're lucky and the author actually posted the image).
Diving into the world of commercial Smalltalks showed me that it's actually possible to write solid, extensible, well documented, tested and stable Smalltalk code. Later, looking at Cuis showed me that it is in fact possible to do the same with open source implementation, but you need a strong leadership, a vision, and skills that most of the Pharo community is simply not interested in having.
Note: this is the first ever time where I'm knowingly, willingly, and somewhat brutally attack or complain about a particular community. I'm really tolerant. I can deal with a lot. But half of the Discord channel shouting at me and calling me names like "masochist" just because I want Ctrl+A and Ctrl+E work as Home and End in the editor? That was too much, even for me.
I love so much about Smalltalk but also felt many frustrations with implementations and community issues.
A couple of me own rants on that include from 2007:
"[Edu-sig] Comments on Kay's Reinvention of Programming proposal (was Re: More Pipeline News)"
https://mail.python.org/pipermail/edu-sig/2007-March/007822....
"There is once again the common criticism leveled at Smalltalk of being
too self-contained. Compare this proposal with one that suggested making
tools that could be used like telescope or a microscope for relating to
code packages in other languages -- to use them as best possible on
their own terms (or perhaps virtualized internally). Consider how the
proposal suggests scripting all the way down -- yet how are the
scripting tools built in Squeak? Certainly not with the scripting
language. And consider there are always barriers to any system -- where
you hit the OS, or CPU microcode, or proprietary hardware
specifications, or even unknowns in quantum physics, and so on. :-) So
every system has limits. But by pretending this one will not, this
project may miss out on the whole issue of interfacing to systems beyond
those limits in a coherent way. For example -- OpenGL works, and
represents an API that has matured over a quarter century, and is linked
with lots of hardware and software implementations; why not build on it
instead of "bitblt"?. Or consider how Jython can use Java Swing
libraries and other such Java libraries easily. Consider this example of
proposed failure: the proposal's decision to punt on printing -- no
focus there in difficulties of interfacing with a diversity of OS
services as a guest -- of relating to prior art. This is where Python
often shines as a system (language plus libraries plus community) -- and
Python is based on a different design philosophy or perhaps different
design ethic. Python has also prioritized "modularity" from the
beginning, which has made a lot of these issues more manageable; Kay's
proposal talks a lot about internal integration, but the word
"modularity" is not even in the document. In this sense, I think Kay's
group are repeating mistakes of the past and also dodging another very
difficult issue -- one that Python somehow has more-or-less gotten right
in its own way. It's their right to do their own thing; just pointing
out a limitation here."
And later from 2010:
"[fonc] On inventing the computing microscope/telescope for the dynamic semantic web"
https://www.mail-archive.com/fonc@vpri.org/msg01445.html
"As I said at the end of my second post linked above: "It's taken a while for me to see this, but, with JavaScript, essentially each web page can be seen like a Smalltalk ObjectMemory (or text-based image like PataPata writes out). While I work towards using the Pointrel System to add triples in a declarative way, in practice, the web of calling cgi scripts at URLs is a lot like message passing (just more like the earlier Smalltalk-72 way without well-defined syntax). So, essentially, a web of HTML pages with JavaScript and CGI on servers is like the Smalltalk system written large. :-) Just in a very ad hoc and inelegant way. :-)""
I don't want to talk about Pharo. Please, don't make me talk about Pharo at length. Even a short summary will be painful... But I'll do it anyway if only to have something to link to in the future.
In short: Pharo is the worst Smalltalk out there, with a community that is small, elitist, and entirely unconcerned with user experience. I once engaged with the community on Discord to say that they could maybe care a tiny little bit more about backward compatibility. I learned that "they do care a lot" and - oh wonder! - they are introducing a framework (brand new, of course) to help fix compatibility issues (something based on pragmas)! I then said, "look, I just opened an image of Pharo 7, went to package manager, and tried to install PetitParser, only to get debugger window pop up multiple times." Stock image. Stock package manager. It worked perfectly fine in Pharo 5. Doesn't work at all now. The response? "Well, that package manager is old and was abandoned," and they are currently (again) rolling out an entirely new way of doing things as fundamental as installing packages. The new tool was hard to find, buried five feet under in menus; the broken, old, abandoned project was left where it was, without a single comment about the deprecation. From my perspective - someone returning to Pharo after a few years apart - something that used to work quietly stopped working. I then heard that I should follow the development closely, and anyway, that's not an example of breaking backward compatibility (in user experience) - it's just... something else, and it "just happens" sometimes. I was then chastised for daring to suggest that a mouse is not, in fact, a requirement for having an interactive, introspective, personal system (which is obvious - you can run Emacs in a terminal, and you'll get the exact thing). I left afterward, not wanting any more of the "support" from the community...
In a tiny world of Smalltalk, Pharo rose to prominence because it was free, and it was used by a few flagship projects as a reference platform (while they were being developed - most of the projects had already died - usually shortly after authors got their PhDs). Unfortunately, these were just accidents of history, yet Pharo's community somehow took them for granted and became even more elitist than Smug Lisp Weenies ever were.
The problem with the user experience was mirrored in the developer experience. Over the years, the churn in frameworks was considerably worse in the Pharo ecosystem than even in the JavaScript world. In such a small ecosystem, and over just a few years, most core frameworks were replaced, sometimes more than once, with the "next versions," "new incarnations," and "reboot projects." Due to Pharo not supporting namespaces, keeping multiple kinds or major versions of a framework in the same image is problematic and can lead to bugs. Without doing that, though, you lose all compatibility with tools, utilities, and libraries written for the older versions. In JavaScript, the number of active programmers lets you expect someone to update and fix those tools so that you don't have to. In a tiny ecosystem of Pharo, you can't expect that - the original author most likely moved on years ago, plus the collaboration tools in Smalltalk traditionally sucked a lot. If you depend on something, you should expect to be the one to maintain it - against a collection of ever-changing APIs all around you. In other words, the Pharo community worked hard to dump everyone back into the "dependency hell" period of the early Linux.
Most of that came from the misguided efforts of the community, but some problems ran deeper than that. Take Morphic as an example. It's a nice - if a little simplistic - UI library, and the reactivity of all the UI elements under it is eye-opening. At the same time, it's relatively inflexible (most suited to animating spinning rectangles) and definitely shows its age. This led to attempt after attempt to extend it with features people expect from modern UIs. Those attempts were hard to implement, hard to use, and mostly unsuccessful - all due to the underlying model's limitations. The user experience suffers because of them, too. For example, I - and probably 99% of other users - want my windows to look like all the other windows on my desktop. Instead, all Pharo windows live in a single OS-level window. Another example: I like how my (tiling) window manager does things and would like Pharo's windows to also be managed by it. No such luck. Problems that are long solved elsewhere in Pharo are being solved again, in a Pharo-specific way. Scaling an interface so that the labels still fit in their containers when I increase the font size is something that Pharo still has trouble with. It took ages to get 4k support. Customizing the key bindings was done ad-hoc in Morphs - last time I checked, there was a new framework that would fix that in the works. It was in 2018.
This case might not be purely due to Morphic; there's a pinch of elitism hidden here: because real Smalltalkers use the mouse! Mouse and mouse only! Using a keyboard is what the guys writing Java do, so it's a "Bad Thing" to do. All the poor sheeple, trying to hold to their home rows: Smalltalk (meaning: just Pharo, there's no other spoon) exists to liberate the ignorant you from the tyranny of keyboards!
I'd write more, but unfortunately, after Pharo 7, the installer broke for me on Linux, and I couldn't run it ever since. The 4th incarnation of the FFI framework (that itself needs an obsolete version of libffi) is used to require libgit so old that I can't get it without compiling it from the source. Neither FFI nor Git should be critical to the whole system, but the image simply fails to run when the libgit is not loaded correctly. That, in turn, is because the 5th incarnation of the source code version management tool, finally, begrudgingly, switched from custom code to Git. That's good in itself, but you should either bundle what's needed with the VM or make the tool optional. But no - for all the backward compatibility caring, Pharo moves fast and breaks things with impunity. It doesn't matter that users will lose interest in both Pharo and Smalltalk at the same time when faced with such an experience.
The funniest thing in all this is that you don't even need Morphic to directly interact with widgets in a system. Multiple other Smalltalks demonstrate that it's possible to seamlessly inspect and modify widgets during runtime in a system running in OS-level windows and using native widgets.
If you want to experience Smalltalk properly, get a personal copy of VisualWorks from Cincom. On Linux, you can also use Smalltalk/X (the "jv branch") - it's still being developed, albeit slower. Both implementations can effortlessly run Smalltalk code written in the 90s. Pharo has problems (but the Next Great Framework, when done, will help with that!) running code from 2 years ago. Both, of course, provide headless modes of operation and had been doing so literally decades before Pharo. Even if you want to witness Morphic and classical Smalltalk experience, don't use Pharo - go for Cuis Smalltalk or Squeak instead.
Obsessed with new and shiny, with things bolted-on on top of utterly inadequate infrastructure, rediscovering problem domains that the rest of the world solved already, Pharo is a trap that is not, and likely never will be, user friendly and stable. On the other hand, it is capable - if you are lucky enough for it to work for you.
TL;DR: There's way more to Smalltalk than just Pharo, and I would recommend basically any other implementation to people wanting to learn it. Visual Works, Smalltalk/X, Squeak, and Cuis, are all excellent choices, depending on your needs. I learned Smalltalk with Pharo, starting with version 1.4. There was a brief period when everything worked, and there was a lot of effort put into documentation, most notably the two Pharo books and some follow-ups. After that, everything went downhill, and for a long time, I thought that's just how Smalltalk development is in general. Seeing and working with other implementations showed me a very different picture, and it caused me to lose all faith in the Pharo project.