Hush, a modern shell scripting language

Why do we need a one true shell that implements the standard? Am I misunderstanding you…? The whole point of a standard is that everyone implements it so the different implementations don’t matter (and everyone does implement it, in the case of POSIX shell, minus a couple things like [ -t ] and some bash defaults).

The situation - as I see it - is that we have a spec, and we have systems that ship a /bin/sh that implements something like it. If people are targetting their system's /bin/sh, then they're writing scripts for their /bin/sh implementation not posix compliant shells. For example, my install uses dash which has features beyond the posix spec which I have to eschew to produce portable scripts.

As a sibling comment points out shellcheck will point out a lot problems, but it requires people choosing to use it. You only have to dive around /usr/bin for a little while to see its usage isn't universal ;)

Of course, if the differences in implementation don't affect your usecase then it simply doesn't matter.

I suspect that, given the general emphasis in the Smalltalk community on images that are "batteries included", that there is a cause and effect relationship between these lacks.

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.