I'd guess that the technical decisions that differentiated early unix from the lisp machines etc. were based on hardware and cost limitations.(the development of unix is something I'd be interested in reading more about) Then as unix took off, these technologies became entrenched, with a kind of apologetics developing amongst users who liked those systems, or never used anything else.

There's an interview with Bill Joy where he said that Vi's famous modal interface was merely a result of his poor quality terminal and network connection, and now it's used by millions of programmers. I'm not saying that these users are wrong about the benefits of modal editing or the unix text interface etc, but that these are discovered benefits that are then used to retroactively construct a containing narrative of justification that often walls people off from alternatives.

I'd also hazard a guess that many of these technologies were simply inaccessible and/or unknown to the mass of post-pc-revolution developers who create the bulk of our present systems. The number of devs who had access to Lisp machines was small compared to the number who came in with Unix with its success in the workstation market, and tiny compared to the number of devs who came in through home computers/PCs.

I myself grew up with 80s home computers, moving to the PC and Linux in the late 90's. Lisp machines, Oberon etc. were unknown to me until a few years ago, and information about them is still hard to come by. Nearly all the lisp machine sites are web 1.0 with broken links etc. Very few of them try to market the benefits of these systems to people in the wider community.

After I got interested in lisp and lisp machines (thanks pg!) I spent a weekend getting that notorious leaked Symbolics Genera distribution working on Linux, inside virtual box on my mac. After a few hours in the Listener, with its rich output and superior incremental help system I wanted to show it to everybody I knew. It was one of the most incredible things I had ever seen on a computer. For the next few weeks at work I was occupied with the constant thought, "This is not as good as Genera". It's had a huge impact on how I think about software, even my indie game development.

https://en.wikipedia.org/wiki/Unix

http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html

http://www3.alcatel-lucent.com/bstj/vol57-1978/articles/bstj...

http://cm.bell-labs.com/cm/cs/who/dmr/chist.html

http://www.unix.org/what_is_unix/history_timeline.html

http://www.faqs.org/docs/artu/historychapter.html

In fact, I started hearing of all of those OSes fairly recently too, but I still see myself as a "youngster" in programming world, and thus I thought those technologies were more well known at that time. Also, that they were more well known to Important Figures and Big Companies then, so they could try to build on those ideas.

But now I start to recall, that most of those OSes are usually reported to be used and deployed quite rarely (Lisp Machines e.g. often dismissed because of high price and hardware requirements), so that could have limited their exposure. And also, I'm ashamed to admit I forgot about this (oh the times!), it must be taken into account that there was no Internet at the time, so this also made sharing of ideas harder than now...

http://www.levenez.com/unix/ has a good amount of info and links on the history of Unix and the people who worked on it. I came across the site a while ago and browsed it some. Interesting stuff, some of it at least. Recursively traversing the links should give even more.

There is also no command history for my gui clicks; once you've clicked on something, there's no way to reuse that click in some slightly different way.

So, when outputting a number, you could display it in the output stream as a circle of radius N. Then, any input which wanted a number as argument (using "(accept 'integer ..)") would let you type a number or click on that circle.

This could be extended to shell command parser for richer input choices (rmdir can only accept directories, cat won't). Existing utilities could support a "richly typed stream of objects" (graphical ls) or a wrapper or output processor could add it. The latter has the advantage that not all commands would need to be aware, and it could be multi-functional (could work on "ls|grep", "find", "tar tf" output--but you might need to specify type hints).

I think it would be handy to have all my recent files, directories, outputs handy in a list on the side (with keyboard shortcuts too; I'm not a clicker..).

So in no way should your command history have to be compromised just because you have alternative input methods available.

[1] A Guided Tour of the Common Lisp Interface Manager, http://3e8.org/pub/scheme/doc/lisp-pointers/v4i1/p17-rao.pdf

And: applications that have Macro recorder features (Office and many text editors) allow you to actually record your actions - clicks or otherwise - into code that can be rerun.

Why have macros and history reimplemented badly by every application when one application could do it well?

That doesnt take away from the point, however, that GUI actions can be stored in history, composed, etc.

Some R (programming language) GUI frontend does it in this way.

It would be kind of cool to have gui interfaces (including the general desktop gui) have something like this dual mode.

Since I discovered UNIX, with Xenix in 1994 followed by many other variants, I always looked for ways to replicate such workflows in UNIX.

At the end of the day, Mac OS X and Windows communities are more welcoming to such ways of working.

Just because it's old, doesn't mean it's only about nostalgia.

Besides, I for one can't have this kind of nostalgia because in the '70, my fingers were a bit too short.

There is something extremely convenient to be able to use the same environment everywhere, with minimum prerequisites, because terminal emulation software is very common (probably as common as Web browsers).

I also find it more natural to deal with the system with a CLI when you spend your time editing source code or doing sysadmin stuff; it doesn't break the flow. Of course it's totally different if you're a graphic artist or a Web developer.

Sometimes CLI makes more sense, sometimes GUI makes more sense. But accusing people of being stuck in the past, that makes no sense.

UNIX shells can only seem powerful for those that never had the luxury of playing with Smalltalk, Lisp, Mesa/Cedar or Oberon environments.

Where you have a CLI and GUI experiences interact together to create a composable workflow experience.

Where I can do function composition on my REPL over data that I just selected with my mouse on a word processor, just to give a possible example.

Where public functions from dynamic modules are exposed on the REPL and can take part in any set of commands.

There is this primitive notion that a CLI needs to be the UNIX way, when a REPL as CLI is so much more powerful.

By "tab" you mean tab in your web browser; do you not? (I ask because there are non-web-based IPython thingies.)

edit: the comment by zorbo seems an interesting answer to my question, but I'm still not 100% convinced; also, I must still ask how can we be sure we're not victims of a text-mode "Stockholm Syndrome" in this regard?

So they look around and see only UNIX CLI.

It is just like mankind during the middle ages that never experienced how the Roman and Greek society were developed before the empire downfall.