17 Dec
2011
17 Dec
'11
3:43 a.m.
On Sat, Dec 17, 2011 at 12:03:33AM -0800, Josh Dersch wrote:
And a rite of passage you'll experience again, and again, and
again... it's the gift that keeps on giving :).
Well, some people _are_ capably of learning from past mistakes. Not all
people, unfortunately, but some ;-)
Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
On 12/16/2011 10:09 PM, Mouse wrote:
I never implied (or meant to imply) that this had to be
special-cased by anything at all -- on the contrary, to do it right
would require changes to Unix shell behavior, as you have suggested.
Perhaps I haven't used it enough, but I've never ever had a problem
with the Genera listener mis-interpreting a lisp form as a command
or vice-versa... do you recall specific examples?
Because it simply works. Oh, there have been improvements since the early
days, like tab-completion (which is very handy) or programmable completion
(which tries to be smart and ends up being very annoying, so I quickly
get rid of it where it is installed by default).
I'm not sure I agree with your two points
here. Specifically, I
don't agree that making a commandline user friendly necessarily makes
it "expert-hostile" as you put it,
No, it doesn't necessarily make it
so. But they do correlate
remarkably well, at least in my experience.
or makes it impossible for said commandline to be
consistent.
Hm, yes, I overstated the case. "The other is that
novice-friendly
usually means logically inconsistent special cases."
Let's start with the "rm *" example.
"rm *" is a particular
invokation of rm that isn't commonly used -- [...]
The problem is not what the
interface looks like, or should look like.
The problem is implementing it. As it stands, the only entity that can
tell whether I typed "rm *" instead of "rm Makefile a.c a.o b.c b.o
etc" (or whatever) is the shell, so this requires a very ugly special
case in the shell.
That's why I was trying to design a general mechanism that supports the
desired effect without resorting to a special case - in this case,
knowing that the command spelled "rm" should have magic treatment for a
* on its command line (worse, it only sometimes should, if it supports
your -y suggestion). Something like my idea would permit moving the
code into rm, which is where it belongs; that way, the test is kept
with the program, so it's performed only when it should be. Another example, from Symbolics Genera (which
I've been spending a
fair amount of time with). The Command line in the Lisp Listener has
a few wonderful features [...]
Perhaps _you_ like them. I remember when they came
in and I really
wished I could turn them off entirely. If I'm typing to a lisp
listener, I want everything I type to be taken as Lisp code, never
(mis)interpreted as some kind of funky non-Lispy CLI.
But there's little reason to do a point-by-point reply to your example;
it's all a question of who finds what intrusive, helpful, whatever.
I'm trying to say that I think that a command-line can be
interactive and helpful, rather than simply passive. (And I believe
it can be done in a way that makes both experts and novices happy.)
Perhaps not in the way Genera does it, but my point is -there is
room for improvement-. Today we have gazillions of cycles sitting
idle, displays with millions of pixels and our primary interface to
the CLI is not much more advanced than an ASR 33. (At least we have
lowercase characters.) The CLI itself hasn't really evolved at all
since Unix c. the 70s. I've literally had people tell me that "oh,
accidentally deleting
your files is a 'rite of passage'". I cannot express the level to
which I disagree with this idea :).
I think there is a little truth lurking in it,
though. While it
doesn't have to take the form of a bad experience with rm, I think that
learning that Unix is an extremely YAFIYGI system is very important,
even to the point where it might be fair to call it a rite of passage.