Micro$oft Biz'droid Lusers (was: OT email response format)

From: Richard Erlacher <edick_at_idcomm.com>
Date: Mon Apr 22 00:25:41 2002

See my comments below ...

Dick

----- Original Message -----
From: "Sean 'Captain Napalm' Conner" <spc_at_conman.org>
To: <classiccmp_at_classiccmp.org>
Sent: Sunday, April 21, 2002 8:47 PM
Subject: Re: Micro$oft Biz'droid Lusers (was: OT email response format)


> It was thus said that the Great Richard Erlacher once stated:
> >
> > I wouldn't say it's better, but (1) it's better documented, and (2) I
don't
> > have to look at the code.
>
> Better documented [1] as for using the program, yes, I'll grant you that
> (to a degree). And for two, you were the one who brought up the source code
> of Linux as being ``full of ugly hacks and undocumented modifications, among
> comments relevant only to the original code that was abandoned six or seven
> revisions back, though it's not obvious.'' So if you don't have to look at
> the code, why should this be of concern to you?
>
I do have to look at the code because the documentation is irrelevant to it.
The code is on rev 13.64 and the doc is on 1.01 which is beta, and incomplete
at that. What I said was that since the commercial code didn't come with
listings, I don't have to concern myself with them.
>
> -spc (Who has looked to the source of Linux to figure out the stack frame
> given to a signal handler to help debug a problem in user code ... )
>
> [1] For various values of documented. Using only the documentation that
> comes with Microsoft Word (hardcopy or the help files) can someone
> be reasonably expected to learn how to use Word?
>
I'd say so. My 80+ year-old mother did.
>
> Seems like books on *using* software is crowding out books about
> *writing* software at the bookstores. And to me, that says that
> the documentation that comes with software is so lacking that a
> market of third party documentation is viable. So I might contend
> that your assertion of ``better documented'' is invalid.
>
If programmers knew what computers were intended to do, perhaps they could
figure out what to do with them. I'd say a goodly share of what passes as
software today, including that from Microsoft, does nothing at all related to
what the user thinks it should do, based on the writeups. Further, I'd guess
that at least half of the programmers who have worked on a given piece of
software, whether for UNIX or Windows, can't agree on what it is supposed to
do. Additionally, I'd guess that, of the half that agree on what the program
is intended to do, half can't tell you whether it does that, and of that half,
another half can't tell you what their own code was intended to do or whether
it does that.

For weeks, I've been looking for a line-by-line assembler to run on an 805x
CPU. I've asked in a number of lists, newsgroups, etc, and gotten numerous
replies, all of which has convinced me that of the hundreds of millions of
people out there who fancy themselves as programmers, fewer than 1ppm even
know what a debug monitor is. I learned what a debug monitor is the day I
started using microcontrollers, back in the mid-'70's. I find this
unfathomable. Oddly enough, there are many debuggers for the 805x and other
cores, that don't even have line-by-line assembler/disassemblers in them.
Time was, every debugger you saw had one.

Back a few years, an assembler wasn't considered complete unless it could
assemble itself, and, likewise, a compiler wasn't complete until it could
compile itself. Today's tools won't do that in most cases. I think the
problem is that people don't know how to specify and how to finish a piece of
work. It's certainly true of most programmers that they simply don't adhere
to specifications based solely on design requirements. Many CAN do that, but
most won't. I'm not sure what, exactly, this means, but I suspect some
profound truth relating to the general decay of the computer software we see
these days owes its origins to it.
Received on Mon Apr 22 2002 - 00:25:41 BST