[pmwiki-users] Re: semantics vs. styles
jo at durchholz.org
Sun Mar 27 13:30:36 CST 2005
Patrick R. Michaud wrote:
> On Sun, Mar 27, 2005 at 12:53:45PM -0500, Radu wrote:
>> The problem that many pro-standard people keep bringing up as a
>> reason for the existence of standards and against ad-hoc objects is
>> communication: *without a standard, there would be no way from
>> different systems to interact; *having an all-encompassing standard
>> (with all the ad-hoc objects built here and there) would make the
>> parsers very heavy and open the way for conflicts (as we sometimes
>> get when applying different recipes)
> Yeah, I've heard that argument many times before from pro-standard
> people, and I just don't buy it. People who make that argument must
> ignore the success of the Internet itself, in which consensus and
> implementations are achieved *before* standards are defined for them,
> and systems working without some pre-defined standard are still able
> to interact.
Well, try setting up DNS, mail, ntp, or anything else that requires
interacting with software from somebody else. You'll instantly see the
disadvantages of that approach: you may be able to set up your server
correctly, but all sorts of nearly-correct software will still not able
to interact properly with your server. Even if it does, some things
don't work as they should, will generate error logs and error messages,
making everybody nervous.
In effect, not having reliable standards means that you'll constantly
being updating the server configuration to keep up with the newest
almost-compatible generation of software out there. It's essentially a
permanent job guarantee - but not the kind of job for me, nor the kind
of job I'd like to pay somebody for.
Of course, insisting on standards is just as problematic: it would need
a way to enforce adherence to standards, and sticking to closely to
standards also stifles progress. What's pissing me off is just those
deviations from the standards that are simply due to laziness, lack of
quality control, or pure neglect.
In another vein, some standards just plain suck. Everybody is fawning
about CSS and how it obsoletes doing layouts by tables, it still doesn't
cover everything, particularly not tables with multiple variable-width
columns. Instead it has become more and more difficult to find out where
a given display detail (position, z position, color, whatever) comes
from: there's a long, long hierarchy of classes, ids, ad-hoc styles, end
user definitions, and (finally) browser implementation errors that
debugging CSS has become a nightmare.
> And as for "heavy parsers and conflicts", I can't see that the
> restrictive standard we have now has eliminated this. An extensible
> web parser already has to be able to understand and parse XML, DTDs,
> and CSS (each with their own syntax and validators), and even with
> the restrictive standard there are still plenty of conflicts.
That's because the standards have been designed to cover all situations,
even those that aren't well-understood. Trying to cover everything has
led to exceeingly complicated standards (with the associated bug counts
in the implementations, and in artifacts that try to use these standards
as well...), trying to cover things not well-understood has led to
It's a mad, mad world.
(Oh, and there's the old sarcastic engineer's saying: "The nice thing
about standards is that there are so many to choose from." XML is even
worse, it allows everybody to define his own standard, though it's
called a DTD. OTOH that has advantages too.)
> Extensibility doesn't require making a heavy parser -- it ought to
> have been possible to create an extensible language within a
> well-defined syntax. Programming languages do it all the time --
> i.e., creating new functions in the language doesn't require me to
> rewrite the parser or compiler.
The boundary between what should be fixed and what should be
user-definable has been well explored. Languages with an extensible
syntax were all the rage several decades ago - until people noticed that
code became unreadable except for the programmer who had defined the
syntax. That wasn't until several years after the start of that hype.
Morale: defining the boundary between fixed and variable elements has
always been a process of trial and error. Getting right the way that
variable elements are integrated and interact is a Hard Problem as well,
and (almost) never works on the first attempt.
And: there's no reason to assume that the current flood of new
techniques (CORBA, SOAP, UML, CSS, XML, etc. etc.) got that boundary at
the exactly right position.
And: PmWiki got the boundary better than most Wikis, but it may also
have to adjust its idea of where it should be - over the years, as
experience garners new insights.
(Enough philosophy for tonight *g*)
More information about the pmwiki-users