[TLUG]: ECMAScript ("Javascript") Version 4 - FALSE ALARM

[Mark Miller]

Thank you all for your feedback. Yes, I understand that my "bad smell"
comment may have been less than helpful, though it hardly compares to
some of the ad hominem comments in some of the responses. I will spend
time reading the new overview paper; and I will post further feedback
as I go. In exchange, I suggest that everyone here read Tony Hoare's
Turing award lecture: <http://www.sli-institute.ac.uk/~bob/hoare.pdf>.

In the meantime, I should explain what I'm reacting to. The first
paragraph of the abstract of this new overview paper lists the
following features [with connective text removed]:

# classes, interfaces, namespaces, packages, program units, optional
type annotations,
# optional static type checking and verification, structural types,
duck typing, type definitions,
# multimethods, parameterized types, getters and setters, meta-level
methods, proper tail
# calls, iterators, generators, type meta-objects, stack marks.

Each of these may individually be good ideas. But languages can die of
too many good ideas.
Personally, I have my doubts about several of these (multimethods,
duck typing, proper tail calls). Several of the others are hard to get
right enough to do more harm than good, and few have (parameterized
types, meta-level methods, iterators, generators, type meta-objects).
The problem is the combination. Language features are rarely as
orthogonal as one might hope. The interaction of even a small subset
of the features listed above can take decades of many failed attempts
to work out well.

But even if you have succeeded at integrating together more good ideas
into a coherent language design than have many previous brilliant
language designers, I have another concern: Standards bodies should
not do de-novo design. And they especially should not foist a design
as a standard before there's a substantial track record of usage. How
many large systems have already been written in this proposed ES4
design? E is a much smaller language than ES3, but it has evolved
substantially in ways that surprised me, based on actual experience
trying to use the language.



> [...] Brendan Eich
> has repeatedly explained why a multiplicity of languages on the web is
> infeasible, e.g. at the URL Jeff Dyer linked to
> (http://lambda-the-ultimate.org/node/2504).

Are you referring to the post at
<http://lambda-the-ultimate.org/node/2504#comment-37607>? I'll wait
for a response before responding further to this point.


> So obstructing the progress
> of JS and consequently the open web in the name of preserving the purity
> of a "platonic ideal" of JavaScript strikes me as either a mistake of
> philosophical extremism, a convenient cover for conflicted business
> interests, or a combination of both.

I have now learned ES3 itself quite well. I would not describe it as a
platonic ideal of anything. I think ES3 is already too large, and it
has many broken features (with, this-capture, pervasive mutability,
lack of encapsulation, silent errors, for/in loop dangers, ...).

The question we are discussing is which direction constitutes
progress. Your response assumes your conclusion. Language vendors and
standards committees, constrained by upwards compatibility, can only
grow their language. Once a language gets too large, the best that we
can hope for is that they grow it slowly, incrementally, and
conservatively.

Java 1.5 came after Java 1.4, and it adds many features to Java 1.4.
All the additional features added are each individually arguably good
ideas, and recapitulate some of the elements of ES4's list. Does this
imply that Java 1.5 represents progress over Java 1.4? In this case, I
am quite familiar with the language both before and after. The process
by which 1.5 evolved from 1.4 was much more experience driven and much
more incremental than what I see here. Nevertheless, IMO, Java 1.5 is
a substantially worse language that Java 1.4.

The "convenient cover for conflicted business interests" comment is
the sort of ad hominem nonsense that I hope we can avoid in further
discussions. I have known both Doug Crockford and Allan Wirfs-Brock
for years before they joined Yahoo and Microsoft respectively. The
suggestion that either would act with less than integrity in order to
serve their corporate interests, I find ludicrous and offensive.


> Finally, just to reiterate that the "it's a different language" charge
> glosses a critical aspect of the ES4 proposal, namely backwards
> compatibility. ES4 is not a new language. It is, as the overview
> describes, a significant evolution of ES3.

C++ is approximately backwards compatible with C. With a small number
of changes, it could have been precisely backwards compatible. Should
we consider C++ to be merely a significant evolution of C? The
additions that C++ makes to C are larger than the C language itself.
>From the list from the ES4 abstract I quote above, I fear this may be
true of ES4 vs ES3.

-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM