Lists Home |
Date Index |
- From: firstname.lastname@example.org
- To: email@example.com
- Date: 16 Nov 99 18:36:47 -0500
> On 16 Nov 1999 firstname.lastname@example.org 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"
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
> 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:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)