Re: ECMAScript Harmony
On Fri, Aug 15, 2008 at 1:40 PM, Garrett Smith [EMAIL PROTECTED] wrote: [snip] There remain challenges, in particular getting off of the untestable and increasingly unwieldy ES1-3.x spec formalism. Unit tests: * help developer understanding * provide examples for discussion * provide conformance suite for implementors * define boundaries on what is and what is not supported* The tests could use a custom test runner or use an existing one. It would be useful if the testrunner could be run in a browser. It would be helpful to have code comments in the tests, indicating exactly which rules of the spec are being tested, so that the reader can quickly go to that section of the spec (spec in HTML). Real code examples in the spec would be useful, too. I can easily see a bookmarklet used to capture and execute the example selection of the spec. This seems like literate programming to me where the program is a set of unit tests. [snip] Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: types
On Wed, Aug 13, 2008 at 10:48 PM, Brendan Eich [EMAIL PROTECTED] wrote:
On Aug 13, 2008, at 8:02 PM, Peter Michaux wrote:
Reading the recent news about ES4 removing more of its old features
and morphing into Harmony, it seems that the related ideas of classes,
types and type checking are the surviving major new features.
It would be more accurate to say that members of the committee see value in
some or all of:
1. Classes as higher-integrity factories than constructor functions that use
closures for private variables;
1(a). possibly related by single or multiple inheritance, but in the
simplest case with zero inheritance.
1(b) with this-bound (self-bound) methods, non-extensible instances, and
other possibly differences from function constructors.
2. Like patterns, which are syntactic sugar for shape tests, assertions
about the structural type *at the present moment* of a given object.
3. Structural types, related by record width subtyping.
4. Optional type annotations, which provide both
4(a). a write barrier on a variable to prevent it from referring to an
object that does not satisfy the types constraints;
4(b) a guarantee that the object denoted by the annotated variable will not
mutate away from the type's constraints.
[snip]
How large are the JS programs you write? What other programming languages do
you use, and at what scale?
I'm not sure if these two questions are rhetorical or not but anyway...
A single web page can be somewhere up to 10K lines which is reasonably
hefty page given JavaScript is not very verbose.
Just out of curiosity, are there many folks on the committee that
write JavaScript applications? I ask that question with zero snark
factor. I have the impression the majority of members are language
implementers and that may be a completely unfounded impression.
I don't use any other language at a larger scale partly because
JavaScript is the language in the browser and that is where I
currently work. Some spare time is spent in Lisp/Scheme.
I often wonder if it is necessary that ECMAScript is a language which
covers all bases and it good at all scales. We have plenty of
languages that already try to do that (and don't.)
JS programmers write type checks and code with latent type systems in mind
already. You do it. Doing this by hand, and often implicitly, can be
pleasant at smaller scale, with no need for shorthands such as like
patterns, or always/everywhere guarantees such as type annotations provide.
Closures and constructors are enough for (1).
Scaling up across people, space, and time (even with only one programmer,
time is a problem; one forgets latent types that the program relies on)
leads many people to want more automation. YMMV.
Automation of type checks or shape tests does not mean static typing.
Runtime checks and more advanced systems such as PLT-Scheme's Contracts can
go a long way. But writing all the checks by hand is a tedious waste of
programmer time, and it's costly enough that programmers tend not to do it.
I'm not arguing against type annotations with this comment but I don't
see much difference in terms of remembering to have type checks
between writing
function(a) {isInt(a); ...
and
function(a:int) { ...
I believe that a:int actually is intended to assign a type to the
variable a and the isInt only checks the contents of a at the moment.
I'd rather the second be sugar for the former and the variable is not
typed at all.
This seems good when prototyping, but it backfires at scale.
Are these
type-related features what the community of ECMAScript 3 programmers
were really asking for emphatically years ago?
Some are, you've heard from Neil already.
But you're dismissing the other things than classes and types that I
mentioned, which could be grouped into two categories:
1. Better modularity and integrity through name hiding. This includes the
generative Name object idea, but also let as the new var for block scope
(const and function in block too).
2. Conveniences: destructuring, spread-operator/rest-params,
iterators/generators, expression closures.
Yes these generally seem like good features.
Is the community really
asking for now with the surge of functional programming?
False dichotomy alert.
[snip]
As I mentioned in my reply to Neil, my statements were misleading.
Having types in a functional language is clearly possible and even
common. I don't have anything against objects having types.
Your points 1-4 above and the differences of opinion and preferences
seem to be a big obstacle to overcome in a committee by consensus.
Peter
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: types
On Wed, Aug 13, 2008 at 11:24 PM, Neil Mix [EMAIL PROTECTED] wrote: [snip] Your statement above implies that types and functional programming are mutually exclusive. Are they? I don't see it that way. No they aren't and I didn't mean to imply that. I intending to compare the interest in class-based OOP that was all the rage many years ago when ES4 first started and now where there is more emphasis on a functional style which can, and often do, still have types. I see. To which I say, why not both? First-class, lexical functions are a _relatively_ easy thing upon which to agree and were added to the language before such a large process was put in place for evolving the language. A committee agreeing by consensus on a OOP system seems like a nightmare that may not happen. The single-inheritance, multiple-inheritance, mixins, interfaces, public, private, protected mess seems intractable since no one seems to think any language does it all perfectly. A CLOS-type system might be best. Who really knows? It is a huge problem and perhaps requires dictator-style leadership (and that may not work either as multiple implementations must get on board.) First class functions may be all the rage with the kids these days, but I don't take that to mean OO is dead in the water. It's just not new and exciting -- you simply depend on it without thinking about it. ;) I use OOP frequently in JavaScript but it isn't usually the style in ES3 or class-based like proposed ES4. It's the style I think is appropriate to the situation. That may draw a slight performance penalty but the code is certainly more robust than the ES3 style. I've been deep into Objective-C lately. I sorely miss the closures, but the bendable static typing sure works out elegantly. I've already gotten through some pretty intense refactorings that just worked once they compiled without warning. That *never* happens to me in JavaScript. Do that a few times, suddenly I'm gaining confidence in my ability to refactor, and before I know it the code doesn't feel so big and complicated anymore. I'm not fearing the dark corners. It's a nice feeling. Different strokes :) Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: types
On Thu, Aug 14, 2008 at 12:33 AM, Brendan Eich [EMAIL PROTECTED] wrote: On Aug 13, 2008, at 11:37 PM, Peter Michaux wrote: [snip] Your points 1-4 above and the differences of opinion and preferences seem to be a big obstacle to overcome in a committee by consensus. We shall see. The committee now has the chance to reason together, to understand one anothers' positions and state them fairly. This happened in Oslo more than in any past meeting, IMHO. This is grounds for greater hope than I had before Harmony. It's possible we'll get just (1) and (2), but we discussed legitimate use-cases for all of (1-4) in Oslo. Time preference for a successor spec will help defer the less useful ideas, if we work together well. Implementation before standardization, and user-testing, will help. There's no silver bullet, but what's the alternative? Rejectionist clinging to ES3-till-2018? I want the language to move forward also. It seems as though the ES4 of a year ago bit off too much and various pieces have been dropping slowly over time. The recent news makes it seem like the group has decided to take a fresh look at a much smaller set of goals for Harmony. If getting a new major revision of ECMAScript out is important in a timely fashion then perhaps the whole types and classes part doesn't belong in Harmony? The Harmony version, which I suppose will be numbered 4 already stands to be very different from ES3. * New standard format with improved clarity * Reference implementation * programming in the small changes (destructuring, let, rest argument, ||=, etc) * new object properties (e.g. Array extras) these additions to the language directly address things that programmers are working around daily. If a standard could be completed sooner, and have Microsoft's agreement and implementation, that may be more valuable than waiting to get consensus on the type/classes issue which would also take longer to implement. It seems to me that the parts of JavaScript which have kept it relevant over the years have been the parts it shares with Scheme: garbage collection, lambdas, untyped variables. If it hadn't been for these features, I think projects like GWT would have sprung up earlier to abstract away what would be a very painful experience programming directly in JavaScript. It seems natural to me to build on that success of borrowing from Scheme with the Array extras and let, for example. Proper tail calls were another feature generally agreed to be in ES4 for a long time but dropped in favor of type-checks and I hope tail calls make a return, as you know. With regard to the types/classes issue, has anyone proposed a solution to the multiple window problem in my original post where an object is created in one window and its type is being tested or compared with similar objects created in another window? If that problem cannot be solved elegantly, isn't the whole types/classes issue a bit of a dud anyway? The whole point of types is to be able to identify an object by it's type and if that cannot be done across windows it seems to be a big problem to me. [snip] Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: types
On Thu, Aug 14, 2008 at 12:49 AM, Brendan Eich [EMAIL PROTECTED] wrote:
On Aug 13, 2008, at 11:52 PM, Peter Michaux wrote:
[snip]
I use OOP frequently in JavaScript but it isn't usually the style in
ES3 or class-based like proposed ES4. It's the style I think is
appropriate to the situation. That may draw a slight performance
penalty but the code is certainly more robust than the ES3 style.
Sorry, curious again: what do you mean by ES3 style?
The direct use of the constructor/prototype system
function MyClass() {}
MyClass.prototype.foo = function(){};
-
Most of the time, I'm using hashes of closures as Paul Graham calls
them or durable objects as Douglas Crockford calls them. One very
useful part of this system is the function-valued properties of the
returned object can be moved to another object or otherwise passed
around. this doesn't matter or need to be fixed if one of these
properties is used as a callback because there is no use of this and
it is not a message passing OOP system.
Another option is returning a single function from a constructor where
the returned function is a dispatch and takes message strings. This
manually built message passing system can give getters, setters,
catch-alls, multiple inheritance, mixins, private, public, etc without
needing the language to support any of them. If JavaScript didn't have
prototype-based inheritance it could be built this way.
A multi-method system could be built quite easily.
There are so many ways to do OOP and so many opinions on how it should
be done, it is great the language allows people to build the system
appropriate to their situation.
I can understand the desire to have some form of OOP support built
into the language and that already exists with prototypes. It seems
that now the idea for Harmony is adding sugar with Object.freeze on
top to give the appearance of classes partly so that type checking is
possible. I suppose people can use this built-in sugar when it
appropriate and continue to build their own OOP systems as needed
(perhaps less frequently. Getting agreement on what the class sugar
should provide, if that is going to be the approach. But could this
goal delay Harmony too long and cause another Oslo a year from now? By
that time, if types/classes are out of Harmony, it may be possible to
have some of the valuable programming in the small features
scheduled to be included in IE9. Actually seeing any Harmony features
in IE9 will be a sign of major success, I think.
Peter
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: types
On Thu, Aug 14, 2008 at 12:58 PM, Neil Mix [EMAIL PROTECTED] wrote: On Aug 14, 2008, at 12:30 PM, Brendan Eich wrote: I took Neil's point to favor not only a separate lint-like tool (which some find painful to procure and remember to run), but possibly something like Cormac's idea I mentioned a few messages ago: a type checker that runs when the code loaded in a web app seems complete, and gives warnings to some console -- but which does not prevent code from running. Neil, how'd that strike you? It could be built into some developer- extension for the browser, so you wouldn't have to remember to run jslint. Logistically I prefer to run the checks before it gets to the browser (i.e. via Makefile as the first step of build-package-deploy in a complicated (read: mature) in-house development environment) Each time you make a minor change to your code you need go through build-package-deploy in order to test? I wouldn't stand for that kind of overhead! ;-) Avoiding this overhead is one of the advantages of using a language like JavaScript. If you are interested in a lint program to do your checking then the following could be made to work now with ES3 function(a /* : int */, b /* : string */) [snip] Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ECMAScript Harmony
On Wed, Aug 13, 2008 at 2:26 PM, Brendan Eich [EMAIL PROTECTED] wrote: [snip] We talked about desugaring classes in some detail in Oslo. During these exchanges, we discussed several separable issues, including classes, inheritance, like patterns, and type annotations. I'll avoid writing more here, Is there more to read elsewhere? I'd like to know concretely what desugaring classes means. [snip] Thanks, Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
types
Reading the recent news about ES4 removing more of its old features and morphing into Harmony, it seems that the related ideas of classes, types and type checking are the surviving major new features. Personally I've never quite understood why classes, types and type-checking have been such a fundamental part of the proposal. I've kept my fingers still about this for several reasons (mostly does my opinion even matter?) but all of this type business seems more trouble than it is worth to me (i.e. a daily JavaScript programmer.) Are these type-related features what the community of ECMAScript 3 programmers were really asking for emphatically years ago? Is the community really asking for now with the surge of functional programming? - Looking in the new wiki page on types http://wiki.ecmascript.org/doku.php?id=harmony:types I have a question about the use in browsers where multiple windows/frames are involved. If a Date object, d, is created in one window and passed to a second window, will Date.contains(d) in that second window be true or false? I would want it to be true, in this case. The same question applies to non-built-in classes where the same class name may be used in two windows with different class definitions. I would want this to be false. Because of the second example, it seems the result would necessarily be false. This makes the test somewhat useless and goes back to duck typing where the code using an object needs to inspect the object for the methods it will call. The problem with duck typing is when different classes provide identically named methods and the reason that in ES3, one way to test if an object is an array is too look for an oddly named method like Array.prototype.splice. I suppose what I'm asking is, given ECMAScript is mostly in the browser and multiple windows/frames are part of that environment, is this contains type check really good enough? Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: ECMAScript Harmony
On Wed, Aug 13, 2008 at 8:26 PM, Kris Zyp [EMAIL PROTECTED] wrote: We talked about desugaring classes in some detail in Oslo. During these exchanges, we discussed several separable issues, including classes, inheritance, like patterns, and type annotations. I'll avoid writing more here, Is there more to read elsewhere? I'd like to know concretely what desugaring classes means. I would too, I assume this is based on Mark's proposal for Classes as Sugar (http://www.mail-archive.com/es4-discuss@mozilla.org/msg01624.html). Thanks for the link. Mark's proposal looks like something that could perhaps be handled with macros. What I've thought would be a great way to add classes to ECMAScript is to give ECMAScript macros and then let folks build their own class macro libraries. That is essentially what has happened now but the wrapping of the prototype-based system and the lack of macros has lead to ugly code. Folks are going to continue with their own wrapping of the built-in prototype system anyway even if there is one sugar wrapping included in the language. Different situations require different OOP features. Some situations more complex than others. For example, if the built-in sugar doesn't have mixins and someone needs mixins then they will need to wrap exactly the same prototype system that Mark's proposal wraps. This brings up an interesting post from what is getting close to a year ago. On Nov 12, 2007 Brendan Eich wrote: On Nov 12, 2007 YR Chen wrote: Macros have been proposed and discussed before - they're somewhere on the wiki. AFAIK, they've been deferred to a future ES5. Researchers on the list may be willing to speak to macros with more authority than I have. I'll just say that apart from the fun with C- like syntax (which can be handled; we're close to specifying standard ASTs for ES4), sound hygiene theory is still a research topic. I expect good results from academia in a year or so, and hope that TG1 will take advantage of them. In the mean time, I think it would be very wrong to defer syntactic conveniences until after macros are done. With macros, conveniences that de-sugar in ES4 could be re-specified (and implemented at the same time) cheaply, for sure -- but users deserve convenient syntax sooner than after macros. Given the time lines, will hygienic macros now be ready before or in time for ES4? Perhaps classes don't need a hygienic macro system and hygienic macros can come later. [snip] Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: Why packages and namespaces?
On Jan 28, 2008 12:04 AM, Peter Michaux [EMAIL PROTECTED] wrote:
Here is a concrete problem. I tried this in the reference implementation...
package org {
public var ecmascript = {a: 1};
}
package org.ecmascript {
public var a = 2;
}
org.ecmascript.a // 2
How do I access the org.ecmascript.a that has value 1?
How does the programmer writing the org package know that his a will
be clobbered by the a in the org.ecmascript package? Isn't the
point of packages to avoid this type of problem?
Is this not considered a big problem? It seems like one to me.
Peter
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Re: Why packages and namespaces?
Thanks for reposting Brendan's explaination. I did look around but
didn't find it.
On Jan 27, 2008 11:45 PM, liorean [EMAIL PROTECTED] wrote:
I think Brendan had a nice explanation of that some time back:
On 10/08/2007, Brendan Eich [EMAIL PROTECTED] wrote:
There's more work to do, including rationalizing and minimizing
concepts including units and packages. A couple of notes:
A package is a named pair of namespaces (public and internal), some
rules for using those namespaces within the package body, and some
special forms for importing names from the package's public namespace.
[snip]
Here is a concrete problem. I tried this in the reference implementation...
package org {
public var ecmascript = {a: 1};
}
package org.ecmascript {
public var a = 2;
}
org.ecmascript.a // 2
How do I access the org.ecmascript.a that has value 1?
How does the programmer writing the org package know that his a will
be clobbered by the a in the org.ecmascript package? Isn't the
point of packages to avoid this type of problem?
Thanks,
Peter
___
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
Why packages and namespaces?
What it the reason for ES4 having both packages and namespaces? It seems like both can be used to protect the global namespace from clutter and otherwise avoid identifier clashes. When to use one and when to use the other? Thank you, Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: proper tail calls
2008/1/24 Nathan de Vries [EMAIL PROTECTED]: On Thu, 2008-01-24 at 20:04 +0100, Chris Pine wrote: It was agreed that implementations would always be free to implement PTC... Really? That wasn't the impression I got. My understanding is that if PTC isn't a requirement, it should not exist. As a programmer, I don't want to need to keep track of whether which implementations support my programming style. Do we really want ES4 and Stackless ES4 (for example)? I believe that is the situation now with ES3 and that an ES3 implementation can use proper tail calls if it wishes to. The string tail doesn't even appear in the ES3 spec. [snip] PS: What's the go with everyone including long lists of CCs? Isn't everyone here on [EMAIL PROTECTED] For this list, reply doesn't default to the list. To post to the list, I think folks just hit reply all and don't clean up the list of CCs. Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: proper tail calls
On Jan 21, 2008 9:59 AM, Erik Arvidsson [EMAIL PROTECTED] wrote: On Mon, Jan 21, 2008 at 8:57 AM, Peter Michaux [EMAIL PROTECTED] wrote: I think Haskell and ES are in different situations as a developer chooses a Haskel implementation for execution. ES4 code for the web is almost certainly going to run on multiple ES4 implementations. If there are no requirements for proper tail calls then they cannot be depended upon and are useless. As long as all the implementations have the exact same call stack limitation then that holds true. However, I think it is unreasonable to enforce one call stack size fits all. I think we can all agree on that having explicit tail calls at compile time enforces all runtimes to have proper tail calls? I think enforces would be better as strongly encourage. An non-conforming implementation could pretend it is conforming and just lie. Suurrre we'll do that as a proper tail call, no problem, good idea. ;-) Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: proper tail calls
On Jan 21, 2008 10:50 PM, Brendan Eich [EMAIL PROTECTED] wrote: On Jan 21, 2008, at 8:12 PM, Maciej Stachowiak wrote: How about something like tailcall or tailreturn. Or just tail f(x, y), Dave Herman's suggestion. tail looks great and any of these three suggestions seem far better than goto. (I'm still hoping this explicit version is optional.) Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Re: proper tail calls
On Jan 18, 2008 10:49 PM, Brendan Eich [EMAIL PROTECTED] wrote: On Jan 18, 2008, at 9:36 PM, Peter Michaux wrote: [snip] Some of the shorthand terminology that has developed in the conversations is a bit unfamiliar to me. Hopefully my questions below are not ridiculous. Is it not reasonable for the spec to simply require implementations to have proper tail calls? The I,X original proposal from the wiki required this. It's reasonable, maybe, if we can agree on the rules and they are not too complicated, but the crucial question is about usability, human factors, avoiding silent bad surprises: will programmers wanting proper tail calls be surprised when they nest an implicit (built-in among the primitive types) conversion in a big state machine, and silently defeat proper tail calls from that particular call site, leading to explosive stack growth in the worst case? I'm thinking in terms of Scheme and tail calls. If a Scheme programmer puts a recursive call in a non tail position they get explosive stack growth. If the programmer was required to explicitly state they wanted a tail call then the explicit system you are suggesting would throw an error, correct? It seems like having types in ES4 is adding quite a bit of difficulty to when a proper tail call can occur. The Scheme folks don't have to deal with that, I suppose. This concern of course led to the ticket; the principle familiar to Python folks is EIBTI (E Is Better Than I). Not just for readers (clarity of intent) but for writers (I want PTC or error here). Is it not acceptable for the spec to require certain implementation internal optimizations? PTC is not an optimization, it's a storage rule. Schemers know to count on it, and do. For ~12 years, JS hackers have lacked it, on the other hand. And JS hackers have standard looping statement forms. But PTC is helpful for state machines, which you do see on the web; you even see setTimeout(fun, 0) flows to empty the JS stack in order to avoid overflow. PTC is worthwhile, and we have included it among approved proposals for a long time. The question remains: explicit or implicit syntax; if explicit, statement only or operator form? I think implicit tail calls are one of the most exciting proposals for ES4. Can it be implicit with the option of making it explicit so that it throws an error if the call is not in tail position and will produce the explosive stack growth? This would have the same feel that the language is unsafe but has optional safety features like optional types. ES3 doesn't have any mandatory safety syntax and to me it would be best to keep all safety syntax optional. Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
proper tail calls
Will proper tail calls be implicit in ES4 or will there be a need for special syntax? I hope it is just a required optimization but then I read this ticket http://bugs.ecmascript.org/ticket/323 and it seems there is a suggestion that the spec will only require proper tail calls with a goto statement. Is it not reasonable for the spec to simply require implementations to have proper tail calls? Is it not acceptable for the spec to require certain implementation internal optimizations? Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
Is ES3 good enough? Was incrementally strengthening ES3 paradigms considered?
I've been reading the blogs and fuss over the the ES4 proposal. It seems to me that if ES3 was so horribly inadequate then big changes to the language would be welcomed unanimously. It must be that ES3 is sufficient to get by well enough that we have the luxury to argue about the worth of the proposed changes. Was incremental change to the ES3 language ever considered at the beginning of the process for ES4? It seems there are many places where the ES3 language could be improved without changing it's character (ie adding classes). If ES was developed in a hurry then perhaps there was plenty of room to strengthen the paradigms it already contains. If work had continued on ES immediately after ES3 was released, isn't that what would have happened? There are things that cannot be done with ES3 that could be added... Could the Self aspect of ES be strengthened? For example, more control over prototypes and the prototype chain would make programming with that model of inheritance a stronger competitor to class-based inheritance. The read/write __proto__ property could be standardized. Objects could have multiple prototypes like in Self. A obj.clone() function. Could the Scheme aspect of ES be strengthened? Tail recursion and let statements seem like good additions. What about macros? Please! Binary download for hiding code seems to be something people have been trying to achieve through obfuscation but cannot truly do with ES3. Complete support for secure mash-ups seems essential and not just because Douglas Crockford says so. Developers want to mash-up and are doing it now even with the security risks to their unknowing users. Adding types, classes and interfaces is drawing inspiration from languages with other models of programming. The new look of ES4 is very Java-like. Are the screams from the Java programmers enough to control the future of ES? Adding these constructs seems like an attempt to try to please everyone. This is the classic anti-pattern in marketing. There is an argument that the changes in ES4 are needed for the open web to keep up with rich platforms like Flash and Silverlight. As far as snazzy, sparkley user interfaces go, the ES3 language isn't the problem here but rather it is HTML, the DOM and CSS. Even if Internet Explorer and all browsers suddenly implemented these other standards correctly an HTML/JavaScript/CSS page wouldn't be very impressive compared with a Flash animation. I gulped last weekend when I saw a friend's flash portfolio with sound, video and vector graphics and then thought about my rectangular tabbed panes and drop down menus. I won't be able to do any of the Flash-like stuff with ES4. This paragraph isn't intended as an argument against changing ES but I don't think change to ES should be justified by the keeping up argument. Has ES3 proven itself to be such a disaster that trying to improve it incrementally while retaining its character is obviously the wrong choice? Was ES founded on such poor choices (Self and Scheme) that we should be moving to completely different style of programming (Java)? I wouldn't be writing this email had others not spoken up. It seems somewhat inappropriate and rude to speak against what Brendan Eich is proposing since it is his language. Peter ___ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
