Feeling good about SML

[Eric Bohlman]

On Tue, 16 Nov 1999, Don Park wrote:
> 1. SML shall be easier to learn than XML
> 
> Ideally, one should be able to learn the ins and outs of SML
> COMPLETELY within 30 minutes.  Amount of time spent is not
> important but it can be used to indirectly measure the level of
> required attention span, mental model complexity, amount of
> details one must remember, etc.

Learn by whom?  Learn at what level?  Consider that the formal
specification of a language, to be useful, has to be written extremely
precisely.  Yet the very precision needed will make a specification hard
to read by people who aren't used to reading formal specifications.  Do we
need the complete specification to be completely understandable in 30
minutes to someone who's never read a spec before?  Someone with no
background in logic, math, computer science, physical science, philosophy?
Keep in mind that a comma-separated format for variable-length data is
conceptually quite simple, yet there are plenty of incompatible CSV
formats and brain-dead CSV parsers out there.

Sometimes "easy to learn" really means "A developer unfamiliar with the
tool can start off at 100% productivity without having to acquire any
knowledge that would allow him to command a higher salary," i.e. "easy for
a developer to learn" really means "easy for a manger to Taylorize."

I should also point out that the amount of learning required to be able to
*implement* a tool is almost always greater than the amount of learning
required to be able to *use* that tool.  The XML Recommendation, for
example, is daunting reading for a lot of people because it describes the
language in the terms an implementor needs.  But people who are merely
going to use XML vocabularies, rather than implement XML parsers, need not
master the whole thing.

Think of an XML parser as a device driver.  An application programmer
needs to know how to use a device driver, but not how to write one.

> 3. SML shall be easier to implement than XML
> 
> It should be possible for an average engineer to write a fully
> compliant SML parser within a week.  While there are many XML
> parsers out there now, level of compliance is questionable and
> amount of time and effort to implement them is greater than
> originally intended for XML.

I question why this is important.  Writing a parser is essentially a
system programming task, not an application programming task.  It will be
done very infrequently compared to writing code that uses the parser.  To
me, the main "benefit" of this requirement seems to be to make it possible
for applications programmers to roll their own parser each time they write
an application rather than re-using a standard piece of code.  The claimed
benefit for this is usually that roll-your-own code can be more
"efficient" than general-purpose code, but that "efficiency" is usually
nothing more than micro-optimization.  Such claims seldom take total cost
into account; every roll-your-own parser has to be tested and debugged,
and cutting corners with those activities doesn't reduce your bottom-line
costs; it just smears those costs among several line-items rather than
giving them a line of their own.

This requirement comes off to me as a political concession to support NIH
cultures.


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)