17 Dec
2011
17 Dec
'11
12:03 a.m.
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?
If you do find it "stunningly inconvenient" I'd like to hear from you
:). Honestly, i find Genera an amazing programming environment, and I'm
still a novice with it. Everything is extensible, everything is
debuggable, everything is explorable. Want to see how a program works?
Just jump into the debugger, view the source. Change a few things,
recompile it on the fly, keep following "who-calls" lists until you find
what you're looking for, etc. (And yes, you can quite easily wedge the
machine if you're not careful. Any OS that lets you rewrite the process
scheduler while it's running can't help but allow that to happen :)).
And the thing that gets me the most about it is how *friendly* it is
while at the same time being immensely powerful. It's very inviting, it
just feels comfortable.
I just wish more people could experience it.
(And I don't want to give anyone the idea that it's perfect -- it hasn't
really been updated since the early 90s and there are many things that
are rough around the edges. There are concepts here, though, that seem
to have been completely forgotten and not necessarily for good reasons.)
And a rite of passage you'll experience again, and again, and again...
it's the gift that keeps on giving :).
- Josh
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.
But there seems to be this mindset that what Unix has is perfect and
cannot be improved upon. I happen to think that it has some good ideas
but there is room for improvement. But being the realist I am, I doubt
anything will change much, things are too ingrained in terms of
backwards compatibility (both of software and of wetware.) It would
take a lot of work, but I think the most major effort would be to
convince people that it's worthwhile. I seem to be in the minority on
this, I should just learn to accept it, I suppose :).
Really, if you have the means I really recommend
playing with Genera,
Indeed. Even if you never use it for anything else, even if
you find
it stunningly inconvenient, it is valuable as one of the very few
examples of a (live today) system that is severely non-POSIX. It also
gives some ideas for alternatives to things that people used to
traditional systems never even question, like, "do we need
filesystems?".
And getting your head around Lisp, whether on a Lisp Machine or not, is
something I can't see as bad in any case.
Definitely.
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.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B