xml-dev - re: re: Re: Feeler for SML (Simple Markup Language)

[rev-bob@gotc.com]

> On 16 Nov 1999 rev-bob@gotc.com wrote:
> > > I guess what bothers me a bit about this whole discussion is the implicit
> > > assumption that it's somehow *bad* to use abstraction to hide the details;
> >
> > I suppose I'd have to go with "dangerous" or "hazardous" - not
> > necessarily "bad".  A conscientious programmer can use such dangerous
> > things to his advantage, but a novice can easily use them as an excuse
> > to become brain-dead.  Considering recent history, I have to refer you
> > to the horde of "WYSIWYG" HTML editors on the market - editors which try
> > to insulate novices from the code.  If these applications were a little
> > bit different in their focus - say, ditching the WYSIWYG myth and
> > generating good code - then they could serve a good purpose.  As things
> > are, though, I cannot consider those applications anything but
> > *bad*...precisely because of their level of abstraction.
> 
> Funny - I would have thought that it was because they sucked, rather than
> because they used abstraction.

And what sucks about them?  IMO, they suck because they take abstraction too far 
without being trustworthy in doing so.  Not only is the sort of abstraction faulty (HTML 
as WYSIWYG?!?!?), but the produced code is faulty...and yet, the products are 
advertised as trustworthy substitutes for knowledge.  This is why they suck - faulty 
abstraction, pure and simple.

> Let's not ditch Java because it makes use of design patterns, or DNS because it allows
> for a nice, friendly, hierarchical model for four-byte long integers. Similarly, let's not
> expect every user of XML to have to think about every tag in their tagset when they
> really want to be *authoring* a document.

Now, call me strange, but I don't see the correlation here.  I'm saying abstraction **CAN 
BE** bad (and hence **IS** dangerous - danger being that which can lead to bad 
results) because it encourages people to think lazily.  Perhaps my point will be clearer if I 
explain that I'm all in favor of automation - but if you don't know what you're 
automating, you will get into trouble.  Heck, my site is automated to the hilt - and yet, I 
control every last byte that comes out.  See the distinction?

> Stupid abstraction is bad. That doesn't mean abstraction itself is bad. annd
> it doesn't mean that you don't want to know about the guts, just that there's
> a time and a place for everything.

I never said abstraction was inherently bad - I called it dangerous because, if not used 
carefully, it can become bad.  Explosives can be used intelligently to collapse a building 
with no collateral damage, or they can be used stupidly.  It is this very versatility, 
coupled with their ease of use, which makes them dangerous.  I'm looking forward to 
www.xml for precisely one reason: XML is strict and unambiguous, in stark contrast to 
HTML's looseness and ambiguity.  This looseness has allowed a lot of bad tools to pop 
up, gaining popularity despite the hideous code they generate - and why?  Because 
they're abstract enough that any idiot can use 'em.

> > If you know what you're doing, shortcuts aren't bad at all.  If your
> > tools are trustworthy (unlike the aforementioned website-in-a-box
> > tools), they can be valuable.  However, recent experience has taught me
> > that the people most likely to produce Web-targeted tools with a high
> > degree of abstraction are aiming those tools at precisely those people
> > who shouldn't be using them.  It's kinda like handing a stick of
> > dynamite and a lighter to a second-grader on the grounds that he doesn't
> > know enough to make the explosives for himself.
> 
> That's silly. Recent experience has also shown me that poorly designed Web
> tools exist at all levels, not just the "Let FrontPage be Your Webmaster"
> level.

True enough - but my point is that FP et al. are sufficiently ill-designed to churn out bad 
code, yet sufficiently well-designed to be easy to use.  This is a deadly combination, in 
that it leads to a proliferation of bad code through the ease of use allowed by a high level 
of abstraction that insulates the trusting user from knowing he's producing bad code.  
There are poorly designed tools in every field; is that an excuse to promote them in a 
new field?

> Your metaphor is misleading and dangerous. A more appropriate metaphor might go
> like this:
> 
>   "It's like a child learning how to talk before he knows the
>    rules of proper grammar."
> 
> In the former, you're assuming responsibility for someone's lack of knowledge
> but your response is to hide it from them for their own safety. In the latter,
> the responsibility is still there, but now it's up to you to demonstrate good
> grammar and in so doing, ensure that the child learns well.

The problem with your new metaphor is that, if the child doesn't know proper grammar, 
he cannot communicate well - and thus, there is a built-in impetus for him to learn how 
to communicate correctly.  With FrontPage et al., there is no such impetus; the "child" 
never knows he is being misunderstood.  A critical level of feedback is missing there; this 
is the dangerous part.  I've seen this happen with HTML; I have no desire to see XML 
tread the same path.  Let the novices play with HTML; it's already broken.  Why should 
we make it easy for them to break XML as well?



 Rev. Robert L. Hood  | http://rev-bob.gotc.com/
  Get Off The Cross!  | http://www.gotc.com/

Download NeoPlanet at http://www.neoplanet.com


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