Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rich Command Shells

waywardmonkeys.org

Post reply on HN
Print view View original

21–30 of 101 posts

Re: Rich Command Shells

#21

Post by pjmlp »

astrobe_ wrote: post #18
pjmlp wrote: post #14

Earlier quoted context omitted.

Because many seem to be willing to go back to the 70's (vi/sh) instead of embracing the progress you mention. 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.

> Because many seem to be willing to go back to the 70's (vi/sh) instead of embracing the progress you mention. 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 emu…

Except REPLs are CLIs on steroids.

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.

Re: Rich Command Shells

#22

Post by pjmlp »

zorbo wrote: post #16

Text is the universal interface. You can do things with it. You can strip it, cut it, transform it, send it to other places. Humans can read it, programs can read it, your printer can output it. It can be sent to web APIs, it can be stored anywhere. It's compressible, can be colored and can be copy-pasted and is infinitely extendable. Thousands of protocols run over it. The command line works with text. The command l…

I rather use objects and function composition in a REPL.

Kudos to Microsoft for bringing to Windows a little bit of Lisp Machine experience with Powershell.

Re: Rich Command Shells

#23

Post by pjmlp »

akavel wrote: post #17
pjmlp wrote: post #14

Earlier quoted context omitted.

Because many seem to be willing to go back to the 70's (vi/sh) instead of embracing the progress you mention. 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.

But, again, why? this can still have many reasons: not willing because of technological obstacles? complexity? because they shown in fact to be somehow worse? (e.g. pure text easier to read, mold, and more universal?) because of some social obstacles? (if yes, of what kind?) what else could that be? (those are just a few of my random quick theories, have I described all possibilities?) edit: the comment by zorbo seem…

Because the majority of those people never had the opportunity to work with Smalltalk, Lisp Machines, Oberon, Amiga,...

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.

Re: Rich Command Shells

#24

Post by richardjdare »

akavel wrote: post #11

Given all of that, and also Oberon -- '80s too, and even the Engelbart's Demo -- '68!, I totally every day wonder and can't understand why in 2010's all of the "modern" OSes still provide the developer just with text-only consoles??... okay, maybe for end-users there was a jump (in interfaces and features), and maybe it was significant indeed (movies editing, 3d modelling/sculpting, possibility of instant communicati…

That's a very interesting question.

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.

Re: Rich Command Shells

#25

Post by a3n »

akavel wrote: post #11

Given all of that, and also Oberon -- '80s too, and even the Engelbart's Demo -- '68!, I totally every day wonder and can't understand why in 2010's all of the "modern" OSes still provide the developer just with text-only consoles??... okay, maybe for end-users there was a jump (in interfaces and features), and maybe it was significant indeed (movies editing, 3d modelling/sculpting, possibility of instant communicati…

For me, because I can't compose strings of gui clicks into an ad hoc list of transformations on text. And I do that a lot in the shell.

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.

Re: Rich Command Shells

#26

Post by a3n »

aduitsis wrote: post #20
zorbo wrote: post #16

Text is the universal interface. You can do things with it. You can strip it, cut it, transform it, send it to other places. Humans can read it, programs can read it, your printer can output it. It can be sent to web APIs, it can be stored anywhere. It's compressible, can be colored and can be copy-pasted and is infinitely extendable. Thousands of protocols run over it. The command line works with text. The command l…

Exactly as you indicate, even in "classic" terminals we have features like unicode support, color, geometry reporting, mouse reporting, window title manipulation, arbitrary cursor movement, etc. All these are in widespread use today. These features could not have been implemented in a real tty, but nowadays I think it makes sense to have them. Maybe some are a little kludge-ish, but are we really arguing about their…

I wouldn't mind it.

Re: Rich Command Shells

#27

Post by lmm »

aduitsis wrote: post #20
zorbo wrote: post #16

Text is the universal interface. You can do things with it. You can strip it, cut it, transform it, send it to other places. Humans can read it, programs can read it, your printer can output it. It can be sent to web APIs, it can be stored anywhere. It's compressible, can be colored and can be copy-pasted and is infinitely extendable. Thousands of protocols run over it. The command line works with text. The command l…

Exactly as you indicate, even in "classic" terminals we have features like unicode support, color, geometry reporting, mouse reporting, window title manipulation, arbitrary cursor movement, etc. All these are in widespread use today. These features could not have been implemented in a real tty, but nowadays I think it makes sense to have them. Maybe some are a little kludge-ish, but are we really arguing about their…

Like extending email, there's a a chicken-and-egg problem. What terminal emulator is going to add a command that no program uses? What program is going to use a command that no terminal implements?

By all means implement this thing - I wouldn't be surprised if there were already terminals that did that. But personally I'd be surprised if it caught on. Compatibility matters.

Re: Rich Command Shells

#28

Post by MrBuddyCasino »

pjmlp wrote: post #22
zorbo wrote: post #16

Text is the universal interface. You can do things with it. You can strip it, cut it, transform it, send it to other places. Humans can read it, programs can read it, your printer can output it. It can be sent to web APIs, it can be stored anywhere. It's compressible, can be colored and can be copy-pasted and is infinitely extendable. Thousands of protocols run over it. The command line works with text. The command l…

I rather use objects and function composition in a REPL. Kudos to Microsoft for bringing to Windows a little bit of Lisp Machine experience with Powershell.

I have used PowerShell, and currently learning Clojure. They never occurred to me as being similar - or did I miss the point?

Re: Rich Command Shells

#29

Post by a3n »

richardjdare wrote: post #24
akavel wrote: post #11

Given all of that, and also Oberon -- '80s too, and even the Engelbart's Demo -- '68!, I totally every day wonder and can't understand why in 2010's all of the "modern" OSes still provide the developer just with text-only consoles??... okay, maybe for end-users there was a jump (in interfaces and features), and maybe it was significant indeed (movies editing, 3d modelling/sculpting, possibility of instant communicati…

That's a very interesting question. 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 el…

> the development of unix is something I'd be interested in reading more about

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

Re: Rich Command Shells

#30

Post by Dewie »

a3n wrote: post #25
akavel wrote: post #11

Given all of that, and also Oberon -- '80s too, and even the Engelbart's Demo -- '68!, I totally every day wonder and can't understand why in 2010's all of the "modern" OSes still provide the developer just with text-only consoles??... okay, maybe for end-users there was a jump (in interfaces and features), and maybe it was significant indeed (movies editing, 3d modelling/sculpting, possibility of instant communicati…

For me, because I can't compose strings of gui clicks into an ad hoc list of transformations on text. And I do that a lot in the shell. 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.

It's perfectly possible for a GUI to have a command history, if the GUI is just a front end to a CLI. Then you can click around when you want to explore, and can go to over to the CLI when you know what you want to do and want to establish a more streamlined workflow. Or even click around and do stuff, and then extract a script from that recent history of clicks and interactions.

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

Post reply on HN