Hacker News Reader

Comment by akavel | Hacker News Reader

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 communication with significant fraction of all the people in the world, to bring up some). But it still feels like even for them, some things were there, and now are not (sorry for vagueness, but I don't have much time now to think about examples, unfortunately. When I'm gonna finally start this blog thing, one day...).

Any theories, anyone? I'm really curious. Still believe this can be improved, and work on some ideas in my free time, but I often wonder why I have to, and I can't already use those beautiful ancient features?

View on HN

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.

> 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

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

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.

Hm, that's a really interesting theory, and the stories and related arguments too, thanks a lot! I didn't think of it before.

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...

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.

Not sure why, but I'm reminded of the old WordPerfect dual mode, with rendered text on top and raw mode on the bottom. It was a little annoying because sometimes that was the only way to get something done, but it was also fairly powerful.

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

Some CAD programs do this. You could execute a command with fully defined parameters to make something happen, or maybe you'd execute the command and enter the parameters by selecting things in the GUI when prompted. It is a very powerful way to work, but the learning curve is often steep.

well, not at that minute level, but every application worth its name has an undo log - and that's a pretty close functional equivalent, IMO.

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.

The problem there is that every application needs to implement a macro recorder, and every application needs to implement history and undo. With small programs that all handle text the shell takes care of history and automation, while the other programs can focus on solving a new problem.

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

True, such a feature should really be system-wide - something like OSX's Automator, maybe.

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

But right now, they aren't. :)

Hah, but here we come back to my question: which was specifically not about what we do have "right now", but why those things that we do have right now are worse than the things "we" had before??

In CLIM, a graphical presentation is only a representation of an underlying type. Types will have default representation (e.g., basic text like you would get from printf), but you can also override this using with-output-as-presentation (see p. IV-1.30 of [1]).

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

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 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?

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.

> 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 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.

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.

IPython already makes for a pretty good bash/zsh/etc replacement for many things. You can get a GUI using the IPython notebooks as well. While I haven't made the switch completely yet, I always keep an IPython session around in an extra tab, since it is very often just much simpler to do something there than in bash.

>I always keep an IPython session around in an extra tab

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

I actually meant a terminal tab (I'm using Tilda as terminal emulator). I'm only really using the web-based notebook interface when I need to display graphics for something.

I am very glad I asked :)

Reply on news.ycombinator.com