7 ms·

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

by akavel 12y ago

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?

pjmlp 12y ago
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.
- akavel 12y ago
  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?
  - pjmlp 12y ago
    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.
- astrobe_ 12y ago
  > 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.
  - pjmlp 12y ago
    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.
    - rkrzr 12y ago
      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.
      - hollerith 12y ago
        >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.)
richardjdare 12y ago
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.
- a3n 12y ago
  > the development of unix is something I'd be interested in reading more about https://en.wikipedia.org/wiki/Unix https://en.wikipedia.org/wiki/Unix http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html http://www3.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1905.pdf http://www3.alcatel-lucent.com/bstj/vol57-1978/articles/bstj... http://cm.bell-labs.com/cm/cs/who/dmr/chist.html http://cm.bell-labs.com/cm/cs/who/dmr/chist.html http://www.unix.org/what_is_unix/history_timeline.html http://www.unix.org/what_is_unix/history_timeline.html http://www.faqs.org/docs/artu/historychapter.html http://www.faqs.org/docs/artu/historychapter.html
a3n 12y ago
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.
- toddkaufmann 12y ago
  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 http://3e8.org/pub/scheme/doc/lisp-pointers/v4i1/p17-rao.pdf
- Dewie 12y ago
  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.
  - a3n 12y ago

by akavel 12y ago

pjmlp 12y ago

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.

akavel 12y ago
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?
- pjmlp 12y ago
  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.
astrobe_ 12y ago
> 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.
- pjmlp 12y ago
  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.
  - rkrzr 12y ago
    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.
    - hollerith 12y ago
      >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.)

richardjdare 12y ago

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.

a3n 12y ago
> the development of unix is something I'd be interested in reading more about https://en.wikipedia.org/wiki/Unix https://en.wikipedia.org/wiki/Unix http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html http://cm.bell-labs.com/cm/cs/who/dmr/cacm.html http://www3.alcatel-lucent.com/bstj/vol57-1978/articles/bstj57-6-1905.pdf http://www3.alcatel-lucent.com/bstj/vol57-1978/articles/bstj... http://cm.bell-labs.com/cm/cs/who/dmr/chist.html http://cm.bell-labs.com/cm/cs/who/dmr/chist.html http://www.unix.org/what_is_unix/history_timeline.html http://www.unix.org/what_is_unix/history_timeline.html http://www.faqs.org/docs/artu/historychapter.html http://www.faqs.org/docs/artu/historychapter.html

a3n 12y ago

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.

toddkaufmann 12y ago
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 http://3e8.org/pub/scheme/doc/lisp-pointers/v4i1/p17-rao.pdf
Dewie 12y ago
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.
- a3n 12y ago