Fog Creek Software
Discussion Board




Can't understand it?  Issues

I understand and can appreciate the gist of what you're saying here, Joel, but the examples you give are just, well, wrong.

HTML wasn't created because SGML was too confusing.  It was created as a shortcut for having to specify an SGML prologue (think 'XML schema') at the beginning of every document.  Along the way, HTML went from a prenegotiated subset of SGML to a non-SGML format, but the fact remains that 'confusingness' wasn't the impetus.

Even worse, HTTP wasn't created because FTP was confusing!  Look at the specs:  the initial HTTP spec is almost of the same complexity as the then-current FTP spec (as a really rough metric, they differ in size by only about 10%).  In many ways, FTP is a much simpler protocol--have you ever implemented it?

FTP doesn't allow you to specify metadata, it doesn't let the client and server negotiate the format to be sent, and it doesn't allow you to use any kind of uniform resource identifier.  THAT is why HTTP was invented.

Tim Lesher
Friday, April 05, 2002

Maybe he was thinking from a user's POV not a programmer's. If you think from a user's POV his points make sense, yours do not. If you think from a programmer's POV the reverse is true.

As customer satisfaction is very important, of course thinking from the customer's POV is what we all should be doing, right?

Robert Moir
Friday, April 05, 2002

No doubt Joel (or someone at Fogcreek) was pissed at having to implement some overblown spec, and he just vented.  That's all I took it as.

tan stafl
Friday, April 05, 2002

Or, to phrase it anothe4r way,  You don't have to understand the entire spec to consume it...just to implement it.

Adam
Friday, April 05, 2002

> Maybe he was thinking from a user's POV not a programmer's.

Hmm, a customer reading an industry spec? I think not...

-james

James Wann
Friday, April 05, 2002

It's all kind of the same thing.  When I am programming,
I act as the user of someone else's API.  If that somebody
bundled in everything that they could ever imagine ever
wanting, then I --- as a user of the API -- am going to be
just as stumped and unhappy as any non-programmer
struggling with some bells-and-whistles application.

User-interface design applies to creating an API.  Oddly
enough, the designers and the end users of an API share
a similar background.  So the prevalence of over-complex
APIs shows that even "familiarity with the user" is not
enough to do good user interface design.  One must rein
in the impulse to add to the interface, since each new part
adds to the mental burden of using the interface.

Jeff Hultquist
Friday, April 05, 2002

Taken to the extreme Joel's words may not be universally applicable, but I think he's put his finger on an important general principle. Simple, lightweight, user-friendly standards are much more likely to take hold than baroque, committee-designed ones, even if they are not quite as powerful or comprehensive. (shades of "Worse is Better"...). Consider the number of people using HTML vs XML, Microsoft Word vs TeX, Macromedia Flash vs SVG... Tons of non-geek grade-school kids are learning HTML these days; those learning XML/XSL/etc obviously number much fewer...

Not to say that complex standards are inherently inferior; some are useful precisely because of their comprehensiveness - Unicode comes to mind...

Daniel Maas
Saturday, April 06, 2002

My "complaint" about it is its trivializing serious technology: telephony protocols, nuclear power, medicine and psychology, everything really. <g>

Christopher Wells
Saturday, April 06, 2002

I see it more as a rant about academia v. practicality. Long winded academic specs v. short practical ones. YMMV IMHO ETC.

Mark W
Saturday, April 06, 2002

*  Recent Topics

*  Fog Creek Home