There's seems to be enough sanity in this thread for me to dare to
participate, good job everyone for avoiding going over the edge ;-)
I just wanted to point out that a sizable subset of ES4 has receieved
substantial usage via the Flash platform (what we call
ActionScript3 and
Flex 2). This subset includes classes, interfaces, namespaces,
packages, optional type checking, and getters and setters. Its
important to note that AS3 is missing a non-trivial # of ES4 features
but I think its fair to say it passes for a half way point between
what
browsers support today and ES4 (if not closer to ES4).
I'm not sure how you measure language success but its very clear that
AS3/Flex2 has been successful in taking ActionScript to higher
level of
"programming in the large" based on our customers successes. The
overwhelming majority of developers prefer AS3 over AS1/2. Sure
it was
only released into the market 16 months ago but Flash moves fast and
over %90 of the world has the AS3 runtime and hundreds of
thousands of
developers have our various SDKs (I think that says something,
although
it certainly doesn't prove anything). There was years of hard work,
false starts and customer research leading up to that release of
course.
I think the biggest colloquial point to make is that developers
used to
static type checking could move comfortably to AS3 whereas before the
language was too loose/dynamic. To make the point bluntly, Java
developers hit the ground running with Flex.
Will ES4 be as successful and will AS3 continue to be successful?
Who
knows, there's more at play than language features. We can say that
real world feedback on AS3 has influenced what Adobe has pushed
for in
ES4 (parameterized types and multi-methods probably top the
list). To
look at JavaScript and ES4 side by side is probably a bit daunting
but
perhaps with AS3 in the middle it looks a little more sane.
I would categorize ES4's evolution as diligent and glacial almost
to a
fault and think that with ActionScript3 and a working RI the spec and
language will be adequately battle tested to keep it from being a
failure. Of course we hope and believe it'll be much more. For
better
or worse, Flash's distribution alone may be a bigger factor than the
existance or non-existance of any particular language feature (of
course
I can't say when our platform will support ES4) but the proof's in
pudding which in this case, I think, is what people put in their
HTML.
That said a lot of the ES4 features are new to me and I'd love to
hear
concrete examples about how these features may not work well
together in
practice (as opposed to unsupported claims that this might be the
case).
Language cohesiveness and implementation feasibility are equally
relevant.
One concern I have is that compilers will be slow for ES4, I realize
compilation speed has been a factor in ES4's development
(evidenced by
the word "optional") but in practice I think a lot of folks will want
those optional features. I don't think ES4 compilers can't be
fast but
it takes time for compilers and their runtimes to mature and real
time
compilation is important for the web. I guess its a matter of having
skilled resources on the problem, on one end of the pendulum javac
seemed to take forever to get fast (remember jikes?) but the mono
guys
seemed to make short work of making mcs fast. Adobe's friends
(http://www.mtasc.org/) have helped us in this area before, the
skills
are out there. I believe the skills/resources/motivation of the
engineers has more to do with it than the language design but I can't
back that belief up.
Cheers and thanks for joining the party...
Tommy
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Mark Miller
Sent: Sunday, October 28, 2007 1:36 PM
To: Dave Herman
Cc: [email protected]
Subject: Re: [TLUG]: ECMAScript ("Javascript") Version 4 - FALSE
ALARM
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
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
