Required Reading (was Re: Who needs XHTML Namespace?)

[David Megginson]

David Brownell writes:

 > A more balanced characterization is "overengineering" (or perhaps
 > even "academic research") versus "making tradeoffs for simplicity".
 > Or, as it was expressed in that paper, the "big complex system"
 > (MIT approach) versus the "diamond-like jewel" (New Jersey).

Actually, both are MIT, or "the right thing" scenarios; from the
paper:

  How does the right thing stack up? There are two basic scenarios:
  the big complex system scenario and the diamond-like jewel scenario.

  The big complex system scenario goes like this: 

  First, the right thing needs to be designed. Then its
  implementation needs to be designed. Finally it is
  implemented. Because it is the right thing, it has nearly 100% of
  desired functionality, and implementation simplicity was never a
  concern so it takes a long time to implement. It is large and
  complex. It requires complex tools to use properly. The last 20%
  takes 80% of the effort, and so the right thing takes a long time
  to get out, and it only runs satisfactorily on the most
  sophisticated hardware.

  The diamond-like jewel scenario goes like this:

  The right thing takes forever to design, but it is quite small at
  every point along the way. To implement it to run fast is either
  impossible or beyond the capabilities of most implementors.

We're tending more to the big complex system side these days in the
XML Activity, but XHTML itself is probably more of a diamond-like
jewel (small but hard to implement efficiently).

 > Remember, you need to understand that the author of that piece was
 > from the MIT crowd and was trying to explain to that group just what
 > had gone wrong.  What made the LISP community lose so thoroughly to
 > the UNIX/C community -- just as it seemed victory was in reach?

This lesson needs to be learned over and over and over again,
apparently.

 > Somehow he neglected to mention some fairly major issues (LISP needed
 > expensive hardware, vs off-the-shelf UNIX boxen; and also, many people
 > have an illogical aversion to parenthesis :-), though he did tease
 > out some more subtle issues tied to the way UNIX/C prioritized
 > simplicity and usability (== adoptability).

He doesn't mention the groundless aversion to parenthesis (obviously,
some fools try to use editors other than Emacs), but he does mention
hardware in a few places besides the one quoted above:

  Half the computers that exist at any point are worse than median
  (smaller or slower). Unix and C work fine on them. The
  worse-is-better philosophy means that implementation simplicity has
  highest priority, which means Unix and C are easy to port on such
  machines. Therefore, one expects that if the 50% functionality Unix
  and C support is satisfactory, they will start to appear
  everywhere. And they have, haven't they?

  Unix and C are the ultimate computer viruses. 

  A further benefit of the worse-is-better philosophy is that the
  programmer is conditioned to sacrifice some safety, convenience, and
  hassle to get good performance and modest resource use. Programs
  written using the New Jersey approach will work well both in small
  machines and large ones, and the code will be portable because it is
  written on top of a virus.

Users today, who've been brainwashed to think of Unix as something big
and bloated rather than small and lean, might be surprised by this
perspective, but I have done most of my development work this decade
on badly underpowered hardware using Linux, where Windows would have
laughed at me for even trying to boot (I have better hardware now,
thanks, and can actually run Windows 95 for hours without a crash).


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)