As a Pharo contributor, well, there is indeed some clicking involved but not as much as you may think.
Keybindings are okayish at this point but can use some more love indeed. But this is not related to the core of Pharo but to the tooling that can be improved on some aspects (and this is moving forward actually).
If a user is not able to use a mouse, well, maybe the user can have a CI that integrates all of the code written in Tonel format and pushed to a git repo. Can work, Tonel format is pretty readable and usable from a command line.
There are ways to use Pharo as a "normal" language. But then, what's the point.
I am using Linux a ton (actually on clusters of boxes) and have a boatload of tools and languages (including low level C and in the past, assembly).
Now, I am also using Pharo to do things on Linux and it is easier and faster to get results out of it, especially when I need to fix a failure.
Pharo is not replacing the OS (even if it may feel like it).
One can deal with a running Pharo remotely (either via VNC directly into Pharo or with Pharo7, using Calypso remote connections).
I am with you on the symbolic aspect but still, having an image that one can inspect is great. I was not understanding its value when I started. Now, I do. And I also find it awesome to have a stacktrace saved to disk on a server so that I can reload it into my desktop box and see exactly where things went south, including variables, values etc. Try that with a core dump.
Now, to each its own and I have a personal little project I should actually deliver, namely being able to expose a fuse filesystem from a Pharo image, so that I can use vim and tmux and those things right from a server. There is no technical issue doing this, just damn code it.
The current Pharo is not an OS inside an OS. UnifiedFFI actually makes it easy to bind with C libraries (heck, I wrapped LibStrophe which is full of callbacks, callbacks that are actually written in Pharo, including full debugging on callbacks, see https://docs.google.com/presentation/d/1HTG3GB3xdwlje8wADZPj...) and the more Pharo evolves (been there since Pharo 2.0) the more it delivers on what I need.
With the new boostrapping, one can actually have images with just the bare minimum (no UI, no devtools) so that it can run.
What is also interesting for me in Pharo is that it actually stood the test of time. I am sick of new languages that pop up all the time, where one is relearning the basics with half baked libraries. Pharo core classes are solid, work well and after working in there for a while, it becomes second nature to do quite advanced stuff that one would not even dream to do in, say, Java.
Pharo is indeed a tool and in my toolbox, it is one the best ones so far. Coupled with Unix tools, it is a beast.
I not care if it is getting popular or not. What I care is that it works, that I can influence its course and change what is not pleasing me (try that with other toolchains).
And also that its community actually owns it, not a commercial organization like Oracle, Google, Microsoft...
In that regard, Pharo is pretty much aligned on Linux.
The Pharo community understands the limitations or warts of Pharo, because there are some. But the features are currently delivering a net positive.
And, a little thing that is quite important: I have fun creating and maintaining systems I have done in Pharo.
This really contrasts with other solutions where fighting with accidental complexity takes 50% of the time, if not more.
Anyway, to each its own. I can relate to being angry when engineering. Pharo is lowering the level on my WTF-o-meter, which is actually good.
"Scale aims to take Pharo into the shell. That is, to write shell scripts in Pharo, use its power, and have a better syntax instead of the ugly bash one"
There are a set of command line handlers that can be invoked and do eval or load code etc.
Test suites and test cases.
Tests are usually written first and drive the development.
When encountering a non existing message, the debugger pops up and asks you if you want to create the message.
Usually, this makes one think: "ha, this is not right" and then goes back on the execution stack and either fixes the test and continues or refactors something etc.
But in a dynamic language, tests are required to avoid regressions.
Programming as teaching goes both ways, programmer is teaching Smalltalk, Smalltalk helps in revealing thinking flaws to programmer. Loop continues.
Nowadays, an image should not be considered as a long lived artifact, one would have a CI job to create the image. See https://github.com/hpi-swa/smalltalkCI
There is also Metacello with BaselineOf constructs etc.
Advantage is that when you get an exception, you just go back in the stack, fix, and then proceed forward instead of looking at a stacktrace and wondering what happened (yes, pdb is nice but not the same feel at all).
Nice to have the videos indeed!