Subject: Comments on "In the beginning there was the command line"

From: Chen Shapira <[email-masked]>
Date: Tue, 13 Feb 2001 16:57:36 +0200

Hi,

Many people on the list recommended this book to me, perhaps because I'm a
GUI person by profession and inclination, unusual traits for a linux lover
and a programmer.

The book is a well written, colorfull and fun to read commentary on
computers, it has a bit of everything: Review of history, culture, bugs,
features, personal experiences. Mostly culture I think.

Which is why my review is meaningless, I disagree with him on many technical
points, but he didn't write a technical book and he didn't care about
technical accuracy, he was writing about a culture, doing a great job at
that.

But since many people recommended to me along the lines of "Read this and
you'll see why GUI isn't this good", well, the book fails in making a case
for that.

The book starts with a nice metaphore of OS and cars. It seems like he uses
the metaphore mainly to show his dislike toward Microsoft OS's.
He gives this impression by discribing MS cars as ugly and Macintosh cars as
pretty. 
Well, you could just as well switch the description around. It depends on
taste really.

But the main thing that's wrong with this metaphore is that OS's aren't cars
(duh.). A more fitting metaphore might be an engine. It gives main
functionality and power, but its worthless without a 1000 other utilities
like wheels and word processors.
Then Linux maybe a perfect tank, but you need to build to wheels yourself.
And MS might be ugly and built on a reworked old engine, but it has an
autopilot.
Mac also has a old engine and an autopilot, but its quite a bit heavier so
you should watch out when crossing bridges.
BE may be a batmobile engine but it doesn't has any other car part yet.

The point is that you can prove anything with a metaphore, just by being
descriptive and not bothering to explain how it relates back to the object
the metaphore is about.

He seems to like the car metaphore, no matter how invalid it is and he
returns to it later, he comments that if someone would replace the current
car interface (steering wheel, pedals, gear) by GUI it may be easier to use,
but also more dangerous.

Sorry to break it to you guys, but a car interface is a GUI, and a pretty
decent one. Although it could be improved and the new Fiat Multipla makes a
great improvment in the location of the dashboard.
But really - you have little icons going on and off depending on the state
of the car (instead of written messages). I believe it qualifies as GUI.
Also pressing pedals to change engine state can be considered as gui.

And few lines later he comments: "The idea that difficult things could be
made easier by an interface is absurd".

Absurd? I think its obvious.
Think of how easy it is to sort a list of strings in Unix or Excel and how
difficult it is in Notepad.
Or even a more trivial example, I have this horrid SQL frontend where you
can't see where the cursor is, probably some bug they didn't notice. The
not-so-trivial-task of writing SQL just became more difficult. On the other
hand, a SQL frontend with syntax checking, linting and syntax coloring can
make the job easier.
Programming isn't trivial, but its easier under vi/emacs/visual
studio/random IDE than with cat.

Interface is  about making difficult tasks easier. Thats the diffrence
between a good one and a bad one. 

Somewhere near the end of the book he gives an example of how much better it
is to create the world from command line rather than GUI, mostly because of
the large numbers of options.

I disagree, humans find it easier to remeber things given few hints, that
part of the reason we like command-completion.
I think the ideal interface should combine visual hints as well as a
flexibility of commandline.
Since creating a world sounds much like programming a GUI interface
(regarding the wide variety of elements and the number of options each
contains) I would suggest some sort of RAD interface, like glade of VB,
allowing you to edit things both visually and programatically.

Thanks,
Chen.

---

From: Adi Stav <[email-masked]>
Date: Tue, 13 Feb 2001 22:43:10 +0200

> Hi,
...lots of interesting interface talk snipped...

First of all, you might be interested in a recent discussion on
http://advogato.org about combining the command line and the GUI. Read
it now (and lend me the book :)

I thought about that a lot myself. It seems to me (and I'm repeating
here what is mostly already universally accepted) that we have two
different approaches here that are not necessarily linked to a command
line and a GUI. One is the UNIX shell / vi key sequences / LaTeX /
your favorite programming language; lets call it illinear
interface. It lets you define and execute actions with almost
unlimited sophistication, and implicitly adjust the interface as you
work. The price is that it is not immediately clear how to perform a
common action, because of the multitude of possibilities. The second
interface is more like many GUIs, and also like command line menu
based systems, and very simple CLIs (linear interface). It only has
limited actions and so it is very clear how to do what, but to perform
more complex ones you either have to do repeat simple actions
interactively, or climb the invisible learning curve and customize
your environment -- write VB scripts or whatever.

So yeah, I would like to be able to receive hints on how I can
continue my vi or shell commands while I write them, and I don't care
much if they involve a GUI as long as they seems natural with the
environment. Likewise, I would like my drag and drop actions to
dynamically create new actions and objects for me so that I can
continue to work more efficiently. I'm not sure how either can be done
(I have more ideas regarding the first than the second, though) but I
suspect that if both go far enough they will reach the similar
results.

Now that reminds me of thoughts I've had when I read about chimps
learning how to talk in sign language, and the flamewars about the
definition of a language. The best I could come up with was that you
could only call a communication system a language when sentences
consisted of more than one word. For example, you could tell a chimp
or a person "sit on the chair" and they would understand "sit" and
"chair" as two words, but also understand the connection between them
and act accordingly (if they give a damn, that is). But you cannot
teach that to a dog. A dog can only understand "sit" or "chair" or
maybe even "sitonthechair" as single words and single sentences
implying single actions.

So that's a lot like linear and illinear interfaces. Linear interfaces
are like dog communications -- simple, effective, but inherently
limited, while illinear interfaces can be considered languages,
because commands in them consist of several symbols whose combination
stand for a new meanings.

	- Adi Stav