Re: [tlug] ruby and python in Japan

["Stephen J. Turnbull" <stephen@??>]

Curt Sampson writes:

 > The Common Lisp standard, while long, is quite readable and provides
 > a fairly easily understood definition of the language, with plenty of
 > examples. The ECMAScript standard, on the other hand, appears almost as
 > if it was designed to be very difficult to understand; I've never seen a
 > computer language standard as bad as that one.

Eh?  I agree with your evaluation of the usefulness of the standards
for programmers, but I think "just plain" bad is missing the
historical context.

The ECMAScript standardizers faced the task of specifying a syntax
without constraining the semantics. ;-)  No wonder it's unintelligible:
there's literally nothing there for a human being to grasp.  It's
definitely unfair to compare it to computer science's attempt to match
the Harry Potter series.  Really, you can count the peers on the
fingers of one hand: K&R, Stroustrup and Ellis, CLTL.  The Smalltalk
book I guess, but I haven't read that in about 2 decades so I forget.

ASN.1, ISO-2022, ISO-8859, ISO-10646, and any number of RFCs are very
similar to ECMAScript.  That's just the way it seems to be with wire
protocols, which is really what ECMAScript is: a wire protocol for
talking to DOM implementations.

But even with essentially semantic standards, how about the XHTML
standard, which basically reads like a Python program:

    try:
        # this will never work!
        import XML
        import HTML4
    except:
        include_random_caveats()
        arbitrarily_resolve_multifarious_internal_contradictions()
    return "Got that?  Raaaaaiiiiiight!  No second chances, Buster!"

The Haskell98 and R5RS reports are rather, er, "concise".  (Go ahead,
tell me that you understood the notion of "IO Monad" from Haskell98 or
"call with current continuation" from R5RS!)

 > Common Lisp standardized a large library, and it's what everybody uses.
 > ECMAScript standardizes little or nothing in the way of a library,

Like Scheme, that's the whole point.

 > and even libraries that have independent standards, such as DOM, are
 > quite inconsistently implemented, to the point where you are constantly
 > writing platform-specific code when using the library.

That's not ECMAScript's fault, though.  The DOM implementations
predate the DOM standards by decades, and the main commercial
implementers (Microsoft and Netscape) had strong strategic reasons not
to conform until forced to.