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

[Garrett Smith]

On 10/28/07, Douglas Crockford <douglas at crockford.com> wrote:
> Robert Sayre wrote:
> > Fighting over the name is pointless. It's not a good name, and web
> > developers call it "JavaScript".
>
> The name is exactly the point. A new language should have a new name. The deltas
> from ES3 to the proposed language are larger than ES3 itself. Claims of backward
> compatibility do not change the fact that there is more than enough new material
> in the proposal to make it a new language.
>
Well, depends how "language" is defined. I could communicate verbally
at a young age, but have since learned many new words and English
constructs.

Are you saying that ES4 is not backwards compatible?

> But at this point in time I would resist standardizing the new language simply
> because we do not have enough practical experience with it to know if it is good
> enough to be worth standardizing. I can think of one instance in history when a
> standards committee produced a good, new design, and that was a long time ago.
> The current proposal is no Algol 60. It's not even an Algol 68.
>
> ES3, aka JavaScript, aka JScript, aka ECMAScript is a small language with a lot
> of, as you say, not good names. I am in favor of making careful and modest
> improvements to the language, correcting as much as possible the problems that
> are most troublesome to actual usage.
>
> As responsible stewards of the language, we should not be trying to transform
> ECMAScript into something else. I don't care what you call your new strongly
> typed classical language, as long as you don't call it JavaScript or ECMAScript.

The new feature "toJSONString" does change the language, in a bad way.
It means that every object is serializable.

This is bad because it means that I, as a developer, have the
obligation to provide proper serialization for every ADT I create.
Obligation. Not option. That sucks.

Regarding the "responsible steward" part, you've got a good point. I'm
sure who "we" are (probably does not include me, right?)

The tests Brendan provided provide clear evidence of the poor
performance of such techniques. How come you never mention any of
this, Doug? Well, it's obvious that you make a career out of leading
what, sheep? Sheeple?

I have been on three projects that have followed your advice, Doug. In
fact, I mentioned this to you when I met you. Since then you've
completely ignored every email I've sent to you.

I have analyzed code that followed your advice, too. f(m) and dojo
used to use the power constructor for everything. Dojo no longer does
this.

In fact, at my last project at Yahoo, the people (people, not sheep) I
worked with would get confused by your module pattern and would think
that it was a namespace or part of the namespace. Of course, this was
also compounded by the  advice provided Steve Sauders.

I remember the 1100-1200 line file. All in one file, correctly
following Steve Sauder's advice, and neatly encapsulated in your
Module pattern, correctly following your advice. These were
responsible, hard working people, and I am still friends with one of
them.

I think my boss told me to "change as little as possible" and "don't
break anything." Deja vu.

It took quite a long time to convince these guys to break stuff up
into multiple files. We ended up with 25-30 files/page. Convincing
them not to use the memory-intensive module pattern was more
difficult. They had just grown accustomed to it, let there by you.

This file count is fairly common for RIA development, it's
accommodated by a build.

Oh yeah, speaking of the build process, you mentioned in your seminar
about removing assertions from the production code. Remember? You said
you wanted to make a build script to remove assertions. You do
remember this, don't you?

Anyone who puts assertion code in their code should not be doing a build in the
first place. Assertions don't belong in the code.

Testing is done in a completely separate layer. If you'd done any
real-world application development, you'd not only know that fact,
you'd know how it worked and how it affected development.

Anyone who even considers buildng such system is too out of touch with
real world development to be considered a responsible shepherd.

I sent you such comments before in personal email, while at Yahoo, but
since I never get a reply (from any mail I send you, ever); how can I
know you actually read it? Well, now I know you read the list :-)

Now we can go back and forth with "too much change", "it should be
renamed", et c. But until you can provide facts to state why ES4 will
break the web, you have absolutely 0 credibility.

In preparing evidence for your claims, you will need to provide tests
and real-world evidence. I can bring my friend from the project I was
on and he still has the code, I think.

In preparing your tests,you might consider http://www.jsunit.net/ and
http://www.openqa.org/selenium/

Kent Beck and Robert Martin have sume useful books. They're not about
javascript, but software, process, testing. Great stuff.

Regards,

Garrett

> _______________________________________________
> Es4-discuss mailing list
> Es4-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es4-discuss
>


-- 
Programming is a collaborative art.