On 10/28/07, Douglas Crockford <[EMAIL PROTECTED]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es4-discuss > -- Programming is a collaborative art. _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
