Re: Learning from history - The UNIX-Hater's Handbook (Peter Quirk)

Today, Lawrence MacIntyre <[email protected]> wrote:
>> a) applications crash, leaving core dump files lying around (or
>>    not). No debugger pops up. If you had unsaved state, it is lost
>>    unless you can pry it from the core file, which is nicely named
>>    "core", without any indication of which program left it (BSD names
>>    them "program.core", which is a little better)
> 
> Would you prefer that they crash, leaving nothing?  The file command
> can tell you where it came from.  If I had any core files on my
> system, I'd give you an example:-)

No, I would prefer to not do any post-mortem program debugging at all,
and instead fix the error as it appears. Not-so-modern-anymore operating
systems managed to pop up a debugger when an error (most any error, with
the exception of errors in the debugger (-:) happened. "Segmentation
Fault" makes me want to smash the screen, really.

I once saw a talk which presented one of the machines in the videos I
linked below; the guy who talked about it said that he tried to hook the
machine on to an old VAX box over ChaosNet. His Lisp machine didn't
recognize the ChaosNet packet that came in, so it popped up the debugger
and he could update the version of the entire network stack, without
rebooting or even dropping this single packet! I'll say that again: He
hacked around in the network code, and the environment didn't break. He
fixed a few case statements, hacked this and that, and after a few hours
of hacking, he had a working ChaosNet (version 4, I think he said it
was) implementation on this machine.

Now imagine implementing a network driver in linux. You'd first write a
userspace program that talks over a "raw" socket, then you'd try to make
it work inside the kernel, and after a few 10 reboots and a few times of
cursing about the lack of debug support in the kernel, you'd have a
mostly-working solution that is still thought of as likely to produce
crashes of the machine, until extensively tested for a few months if not
years. Hmm.

>> b) Command syntax is garbled (think also shell quoting rules). Nasty
>> command names abound. For which command is "grep" an abbreviation?
>> "sed"? "tar"? "cut"? "paste"?? Are these programs still used for
>> these purposes?
>
> grep is the General Regular Expression Parser.  I'll bet that you
> didn't go to the School that Peter Quirk wrote about, you'd know
> that:-)) 

I didn't, but I learned enough about unix to look up "grep etymology"
in google first (-;

http://www.faqs.org/docs/jargon/G/grep.html speaks of: g/re/p, "Globally
search for Regular Expression and Print", which Dennis Ritchie seems to
confirm (-:

> tar is Tape ARchiver.  sed is Stream EDitor.  cut and paste are easy.
> I'll leave that as an exercise for the reader...

Right, in good UNIX tradition, tar stands for Tape ARchiver, but doesn't
compress files, leaving the job to gzip. This makes it the Garbling Tape
ARchiver or somesuch. Whenever a bit on this tape is corrupted, you can
throw away the whole tgz archive on the tape; gzip won't read it because
the checksum is wrong - how's that for archival?

And, be honest: have you ever used "paste" for anything? I have, but
it's embarrassing. (-:

>> c) When you encounter a kernel bug (and subsequent crash), you have
>> lost.
>
> You should get an oops which will tell you what happened and allow you
> to use the kernel debugger to figure out what happened.  After all,
> you DO have the source code for the OS.

Availability of source code doesn't mean that you'll be able to fix all
the bugs. It's a requirement, but not sufficient. A useful means of
debugging the kernel would be a good thing to have in linux/any unix
implementations.

>> d) You get to write programs in languages such as C, which force you
>>    to
>> go through a cycle of
>> write-compile(&fix-errors)-run-crash-debug-(&fix-errors). This
>> development cycle, I'm sure, is responsible for "good enough" tools
>> such as make[1] and other berkeley abominations.
>
> We all know that using MS VC++ allows you to write bug-free code the
> first time with no crashes ever.  That's why there are no bugs in
> Windows XP!  

Sorry, this paragraph gives me the impression that you're suffering from
User's Second System Effect. (-:

C++ is just C with classes. The development cycle is the same. Except
that you get to draw all these fancy UML diagrams.

And never would I suggest that you go develop software in Microsoft
Windows. Really, what were you thinking?

> And we're all jealous that Linux isn't that way...  Creating complex
> bug-free code (that actually does something) without debugging is,
> sadly, beyond the state of the art.  I know that there is all sorts of
> research into clean-room design, but the methods they use are far less
> efficient than the afore-mentioned cycle.

I'd be happy with programs that, when they exhibit errors, don't crash
instantly and that are dynamically extensible.

>> And some others. Life does not have to be like this; and it wasn't,
>> for some users of machines, even back in the 1980s. See the amazing
>> videos made by Rainer Joswig (on
>> http://lemonodor.com/archives/000441.html#000441
>> - be sure to follow all the links). Also, see
>> http://kogs-www.informatik.uni-hamburg.de/~moeller/symbolics-info/symbolics.html
>> for more resources.
>
> You obviously have a great love of parentheses:-) Lisp is neat, but
> all of the implementations that I've seen are extremely slow, 

Then you haven't been looking too hard (-:

http://sbcl.sf.net/
http://cmucl.cons.org/cmucl

are both free Lisp Environments which compile to very efficient native
machine code on a variety of platforms. If you're not opposed to
commercial software, also try LispWorks from Xanalysis. This one has a
really nice development environment, too.

> and I'd really rather not have to write network protocol code in lisp.

Does code speed matter when you're talking over a network?  Hm. I'd
think that network latency was the speed killer. If not, why are there so many
network applications in perl and TCL...

Anyway, take a look at http://www.cliki.net/Etiquette. It allows easy
definition of network protocols in lisp. Nice stuff.

And, really, watch those movies. This is 1980's hardware these demos are
conducted on. My make-of-1992 286 gave me another impression of
"extremely slow" (-:

>> Unix or Linux is by far not the last word in User Interface
>> Design. People have gotten it right (or at least, more right)
>> before. And, amazingly, this "getting right" wasn't done in
>> UNIX. There are amazingly useful data structures out there. Why then
>> do we need to use tools that were written in the 1970s, to fix 1970s
>> issues, operating on One data structure, the stream of bytes without
>> structure, most of which focus on working around the issues arising
>> from the use of exactly this data structure?
>
> While the OS doesn't enforce data structures on the applications, they
> applications DO have data structures.

The OS controls the inter-process communication (IPC). When the only
accessible means of IPC is the pipe, the socket and the file descriptor
(which carry a stream of bytes), then that is what the applications are
limited to. They can invent as many cool data structures as they want,
but to pass them on to other programs, they still have to use streams of
single characters - efficient in programmer time or program run time? I
don't think so.

>> Hmpf. Back to your question above, much has changed. Much has been
>> done. But not much (save for its speed) in UNIX nor Linux has changed
>> to the better.
>
> I think that it's better.  For instance, we don't have to use vi to
> write code anymore.

Hah. Thank the Heavens that we don't have to.
 
Anyway, Emacs already was in existence when the Unix Hater's Handbook
was written, and people still complained; so I don't count the
continuing existence of Emacs as too much of an improvement (-;

>> [1] the author of `make' was reputed to not have fixed an early bug
>>     in the file syntax (you have to prefix every "command" line with
>>     a TAB character; it will barf when it encounters things like 8
>>     spaces) because he already had a few 10 users. This bug is still
>>     present in "modern" make implementations.
> 
> I thought that was a feature...

Hah. If you can't find a rational reason for it, it's not a feature (-:

Good luck and keep your sanity,
-- 
Andreas Fuchs, <[email protected]>, [email protected], antifuchs