[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com]
> Sent: Tuesday, December 18, 2001 7:27 AM
> To: xml-dev@lists.xml.org
> Subject: RE: [xml-dev] s-expressions and XML was Re: [xml-dev] terra
> incog nita
>
>
>
>
> > -----Original Message-----
> > From: Jonathan Borden [mailto:jborden@mediaone.net]
> > Sent: Tuesday, December 18, 2001 9:49 AM
> > To: David Brownell; Joe English; xml-dev@lists.xml.org; Tim Bray
> > Subject: [xml-dev] s-expressions and XML was Re: [xml-dev] terra
> > incognita
> >
> > There are many similarities between LISP and XSLT, excepting
> > of course that XML et al. have been solidly backed by
> commercial folk, at
> > least that is the claim. Perhaps the differences are more to do with
> marketing than
> > technology.
>
> Richard P. Gabriel's Worse is Better essay
> (http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1
> .html see also
> http://www.dreamsongs.com/WorseIsBetter.html) is the classic
> explanation of
> why LISP is a marginal technology today and Unix/C/DOS/Windows/etc. is
> everywhere. Everyone should read it a couple of times a year ... or
> whenever the thought that doing the Right Thing will pay the
> bills starts to
> infect one's consciousness.
>
> Here's "worse is better" in a nutshell ... see if you think
> it fits in with
> XML's success so far.
>
> "The worse-is-better philosophy is only slightly different:
>
> Simplicity-the design must be simple, both in implementation
> and interface.
> It is more important for the implementation to be simple than
> the interface.
> Simplicity is the most important consideration in a design.
>
> Correctness-the design must be correct in all observable
> aspects. It is
> slightly better to be simple than correct.
>
> Consistency-the design must not be overly inconsistent.
> Consistency can be
> sacrificed for simplicity in some cases, but it is better to
> drop those
> parts of the design that deal with less common circumstances than to
> introduce either implementational complexity or inconsistency.
>
> Completeness-the design must cover as many important situations as is
> practical. All reasonably expected cases should be covered.
> Completeness can
> be sacrificed in favor of any other quality. In fact,
> completeness must
> sacrificed whenever implementation simplicity is jeopardized.
> Consistency
> can be sacrificed to achieve completeness if simplicity is retained;
> especially worthless is consistency of interface."
>
>
> Intriguingly, I sat near a member of the W3C Schema working
> group on a plane
> a couple of years ago, and he was reading the Worse is Better essay
> (apparently it was "assigned reading" for the WG). I wonder what they
> concluded from the assignment; it would appear that most recent W3C
> activities are the antithesis of Worse is Better.
> Simplicity is being
> sacrificed for correctness and completeness, and specs are
> held up for years
> while they try to sort out consistency. This is obviously
> the Right Thing
> to do, but does it take XML down the same road to oblivion that LISP
> traveled? Time will tell ...
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
|
