[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What is a lightweight language
Paul Prescod <firstname.lastname@example.org> writes:
> XML's tag-redundancy provides much better error recovery and
> readability (at a cost of verbosity).
And at a cost of introducing more errors. If there is a certain error
rate proportional to the length of the message, a longer message will
naturally have more errors.
> S-expressions-as-we-know-them also use the worst possible character
> for grouping because parens happen so often in ordinary text.
And angle brackets are even more common in program text. One popular
XML processor I've used didn't know how to properly deal with program
text (I believe that you ought to use < and > in the program. I
may be wrong on this point.) With this processor you could not use
`>' to compare values because it would confuse the XML tokenizer.
However, you couldn't use < because that is not a binary operator.
(The solution? Well, it involved pasting up a string with character
code 0x3C in it and calling EVAL.)
People tend to be less )confused about misplaced parens than programs
about misplaced comparisons. Were you able to parse that last
sentence or are you hopelessly confused?
> XML is not ASCII text, but Unicode, whereas the Common Lisp and
> Scheme languages predate Unicode.
It is easy enough to imagine a Unicode variant of Lisp or Scheme.
> XML allows text directly as content whereas s-expressions require
> them in quotes.
It is easy enough to imagine an s-expression variant that deals with
this as well.
> I would bet on YAML before s-expressions, but I'd put my money on
> a government lottery before I'd bet on either of them replacing XML at
> this point.
I agree here. S-expressions are concise, easy to parse, and require
virtually no cognitive effort. XML is verbose, difficult to parse and
define, and requires a fair amount of scaffolding and machinery to
use. This makes XML the clear winner in the marketplace. Sigh.
> Even if parens become incredibly popular as a data structuring
> language, one can install an S-expression parser for Java in about
> fifteen minutes.
Hmmm. And writing a compliant XML parser takes how long? Thought so.
I don't think XML will be replaced by s-expressions, but I think
s-expressions are clearly technically superior.