- bash is just one of many possibilities, so bash != UNIX shell. It is not available by default in all UNIX systems

- bash is not a REPL with support for live coding.

- as consequence of the last point, bash cannot provide graphical output and respective manipulation of system data structures

Writing data to /proc to alter the OS behavior, is pretty basic compared with changing OS behaviour with a "doit" message on a expression block.

EDIT: For better understanding, imagine using something like Mathematica as an OS shell.

You're being argumentative instead of informative or useful.

"bash is just one of many possibilities, so bash != UNIX shell. It is not available by default in all UNIX systems"

Bash is one example of a modern UNIX shell. It is not the only example - there are some that are more advanced in some ways, and some that are less advanced in some ways. I wasn't saying "BASH IS ALL UNIX", I was picking a specific setup as a point of comparison.

"bash is not a REPL with support for live coding."

What are attributes of a REPL which you see bash as lacking? Clearly, it Reads, Evaluates, and Prints. If you just object to the particular language, fine, there are certainly things to object to there - though I think it's pretty great as UI. It's certainly atrocious when you try building anything large out of it.

"as consequence of the last point, bash cannot provide graphical output and respective manipulation of system data structures"

That's mostly false, which you touch on immediately following.

'Writing data to /proc to alter the OS behavior, is pretty basic'

It can get arbitrarily sophisticated, but...

'compared with changing OS behaviour with a "doit" message on a expression block.'

I don't know what this means, please elaborate.

"For better understanding, imagine using something like Mathematica as an OS shell."

There's too many things that can mean for it to aid my understanding much. Do you mostly refer to the ability to embed graphics in the interactive session while retaining a scrolling log? or are there other relevant attributes I'm not following?

In Interlisp, Smalltalk and Mesa environments the shell interacts with the operating system.

All those demos you see from Bret Victor are based on the experience to do live coding originally developed in these environments.

The operating system and applications are blended.

UNIX shell is based on the principle you write little programs in whatever language you feel like and you just have pipes, command line arguments and exit codes as communication mechanisms.

In Xerox PARC environments, you have a REPL experience where you can make use of any function or object in the whole OS and applications. You can change them dynamically (Interlisp, Smalltalk) or via module reload (Mesa).

Since the language of the REPL is the one of the system, you can do tasks, like select something with the mouse and then apply a REPL script to the currently selected graphical objects.

Just a few dummy examples, do a map over all selected windows to change their size for automatic tiling.

Or go over the paragraphs on the text editor and right align them.

The shell blends application macros, operating system scripts and live coding all in the same way.

For graphical editing in the shell you can pretty print data structures so that when you type a variable that represents a graphical structure, it gets drawn graphically in the command line.

You get to change running applications state from the shell, without requiring some kind of network protocol or shared memory API that they need to implement. Any public function or object can be directly accessed and manipulated.

Think of the whole experience as something like DrRacket or Mathematica being the complete OS.

Much more informative - thanks!

That said, little of this is really dependent on another model. It seems your complaints boil down to 1) applications may do a poor job defining interfaces (which is either also true in the PARC setup, or they ignore the need to define interfaces in which case things are unlikely to be stable), 2) everything is too stringly typed (which I mostly agree with, though there are advantages to it), and 3) these (plus cultural attitudes) lead to insufficient/inappropriate infrastructure (which I also agree with - "the application" is typically harmful in the UNIX model).

Having said that, there doesn't seem a theoretical difference in capabilities except for the choice of a more sophisticated terminal (which is something I'd like fixed on modern systems).

As an amusing aside, "Just a few dummy examples, do a map over all selected windows to change their size for automatic tiling." I did literally this just the other day with bash + ratpoison.