I am one of those people who thing that CLIs are not user friendly. The premise - giving a computer instructions via Natural Language (NL) - is very sound. However, the way CLI is done right now (from the ground up) - is broken. The most obvious example - why are CLIs ASCII-based? I want to pass around objects - "ls" should only give me just that, an array of objects (which can be serialized for output in any graphical way, including ASCII). There shouldn't be any ASCII flags or switches - those (if really needed) should be an array of objects as well.
Another example, piping, something that UNIX proponents are quite proud of, is a good concept, but it isn't perfect. I can't even count the number of times I wanted to pipe an output of one program to multiple others, or pipe multiple programs into one. The list goes on and on.
CLI is the best tool that exists at the moment for a few things, but I definitely see how there could be a superior, semi-graphical, non-"scrolling-ASCII-buffer" alternative.
Note: I have tried Linux as my main OS for almost a year, I've done extensive dev under Linux, customized the hell out of my .profiles and *rcs, etc. Still, I see it as flawed. If someone comes up with a sane CLI, I'll be the first in line.
> I can't even count the number of times I wanted to pipe an output of one program to multiple others
ls | tee >(frob x) | grep y
should output the output of ls to both 'grep x' and 'grep y'. The '>(foo)' syntax in bash will create a subshell to run the pipeline in the parens, and evaluate to the name of the FD for the pipeline (eg, /dev/fd/42).
That should probably get a domain-specific tool regardless; Generalizing the command line UI is probably going to end up getting too hairy for the common case.
"I can't even count the number of times I wanted to pipe an output of one program into multiple others ... "
There's nothing stopping you from doing that. Back in college I wrote a Unix shell (as part of a class project in Unix Systems Programming) that, in theory, could do that but I lacked a decent syntax for doing so. Perhaps that's an argument for a GUI, but what you ask for is certainly possible (although the semantics of piping multiple programs into one is hard to resolve, at least in my mind. Do you interleave by characters? By line? User specified? How?).
Also, writing an "ls" that output "objects" is also quite trivial, but the tooling required to convert (or write from scratch) existing command line tools is large. Also, the semantics can get quite rough.
"There shouldn't be any ASCII flags or switches-those (if really needed) should be an array of objects ... "
Again, I can go back to the shell I wrote in college. The arguments to a program were stored in an array. In fact, that's how you had to specify the arguments, as an array. It was an interesting shell, enough to get me an A in the class, but I never used it as an interactive shell. Typing commands (which were first class objects, by the way) was a pain. But boy could I sure could pipe stderr to more and stdout to a file.
Perhaps what you need to do is try to implement your own shell that works the way you think it should work. You could be the one to implement a sane CLI ...
Have you looked at Windows PowerShell? That's exactly what it does. You don't pass around ASCII streams. You pipe .Net CLR objects between programs. I haven't seen much done with it that you couldn't do with a non-graphical shell, but, in theory, you could write filters for e.g. image data that worked exactly like text filters in bash.
I have no idea what you mean by "passing around objects", and I guess that wouldn't make it any more friendly. An "object" is an abstract concept that must be known beforehand, and is just one in a myriad that could exist in the context of interacting with a computer.
You can't approach things from a programmer's perspective when thinking about interfaces. I mean, I see your point, but how would that make it any more user-friendly? More powerful, sure, but it would require an extra layer of abstraction, which is going in the directly opposite way of user-friendliness.
Besides, you already have all that right now, by using the dynamic language of your choice + file system APIs.
I personally prefer the CLI over the GUI since that's primarily what I'm used to. I also dislike control panels (a type of GUI) because they tend to restrict what I can and can't do, but at the same time, I get frustrated when using someone else's CLI. I go into a bit more detail in a blog entry I wrote a few years ago: http://boston.conman.org/2007/05/29.2
As I wrote: "GUIs, on the other hand, restrict the language available to the user, thus enforcing an interactive conformity—much like L'Académie française does for the French langauge (or rather, tries to do). It's not so much about enhancing productivity as it is usability in general (or communication, take your pick)."
Hm, looks sweet! One gripe about super-realism - usually "fun" stems from unexpected game-play variations (and decreasing entropy). In Quake 3, it was the rocket jump. In sandbox games, it's, well, the sandbox. This is also why finding (physics) bugs is so fun. Here, however, I'm not sure if one will be able to do interesting things. Can you, for example, smash half the truck away and be left with a "bike"? Just random destruction seems like it will get old fast.
Minor Pedantic Point of Contention: Quake 1 had the rocket jump "discovery"; by Q3, it was an expected part of the gameplay. However, this does not affect your argument in any way.
In Q3, it was more the way jumping impacted your movement speed which was a discovery. Another example would be the Tribes series, with skiing which was also an abuse of the game physics (and taken as the main movement mechanic in the latest game, Tribes Ascend).
It's nice to see such parts of gameplay emerging from simple bugs. I would argue that it's much more rare nowadays, with games which aim to be always more realistic, and blocking your movement.
> In Q3, it was more the way jumping impacted your movement speed which was a discovery.
Not really sure what you're talking about. Rockets and grenades hugely impacted player speed in Quake 1, but not so much in Quake 3. Check the speed run of the following level to see what I mean:
It was quite serendipitous how although Rocket jumping was "incidental" to Q1 most levels still played extremely well using that feature. Still level-designers who later knew about it and designed for it managed to (ab)use it even more. I designed a level where the entire layout was optimized around rocket-jumping being possible (and encouraged) as much as humanely possible, great fun!
Your piece of paper example caught me a bit off guard. It sounds pretty similar to a quine ( http://en.wikipedia.org/wiki/Quine_(computing) ). I think that the same thing is possible with a demo - write the code to render a piece of paper from an array of letters, and put that part of the source code into the array.
Yeah I'm wrong. What I had in mind I guess, is take an existing very impressive 64kb demo, then do this. That might be much harder, but not necessarily impossible in theory.
A far better argument for me to have made is that it would be impossible to have a 64kb demo which models a surface on which is printed the source code of all 64kb demos written since the start of the scene decades ago. Of course, if equations that describe all of reality are discovered and fit in 64kb, and the graphics card contains a universe simulator, then maybe it's possible.
This got me thinking on the topic of custom UI elements. The problem with those elements is that the programmer ends up rewriting the component, hoping that every little detail matches.
I'm not sure about JS, but in some other languages you can make a new element inherit from the UI element class, and then modify its graphics - which effectively solves this problem. With all its flaws, if I recall correctly Flash let you do this - is there a way to do the same thing with JS?
Good point, I don't think there is. I'd expect custom UI tools to be built around the canvas element someday; we might look forward to UI objects then.
CLI is the best tool that exists at the moment for a few things, but I definitely see how there could be a superior, semi-graphical, non-"scrolling-ASCII-buffer" alternative.
Note: I have tried Linux as my main OS for almost a year, I've done extensive dev under Linux, customized the hell out of my .profiles and *rcs, etc. Still, I see it as flawed. If someone comes up with a sane CLI, I'll be the first in line.