is ES4 getting too bloated?
On 10/21/07, Yuh-Ruey Chen <maian330 at gmail.com> wrote:
Hey all,
I've been watching ES4 development and occasionally contributing input, and I have noticed a somewhat disturbing trend. ES4 is getting ever more and more complex.
I understand ES4 is a multi-paradigm language and so must be packed with features, but I don't think we want a repeat of the C++ template problem (where it took nearly a decade just to get most compilers near compliance with the C++ spec). My point is that although a significant update to ES is needed, if it takes too long to implement a conforming compiler/interpreter for it, the adoption of new features is going to be slow. Heck, I wonder how willing MS would be to provide a fully (or near enough to it) conforming interpreter for ES4 if the spec is so large.
Tamarin will be included as a plugin for IE.
Small proposals like bug fixes and reformed with and company, or proposals that generalize syntax to make the language more elegant are perfectly fine by me. But we already have such huge features like classes, generators, namespaces, type system, and now generic functions. Perhaps we should start deferring more features to ES5?
Which features do you feel are unjustified? Can you bring a specific issue?
I may be able to add some input and some experience implementing ES4.
We have chosen to implement the ES4 language creating a compiler and 2 VMs one in C and one in Java. We started with a partial implementation of ES3 which did support a small subset of ES3 with classes but no VM design and a very limited library. We currently have most of the ES4 language implemented and running. While it has been hard (what challenging programming enterprise worth the effort is not difficult!), I think the language actually wears better once implemented and used, compared to trying to write a spec - which is awfully difficult.
I agree the ES4 language is somewhat large and complex. The compatibility constraints with ES3 certainly take a toll in terms of freedom of change and expression. However, we've found that implementing the whole language is quite feasible in a relatively short amount of time with a reasonably small team. We started about 12 months ago and have implemented most of the language with a very small team and budget. We expect to be complete Q1 next year.
Like any language, you can use the features to write incomprehensible code, but you can also use the features to write very readable, maintainable and more safe code than was ever possible with ES3. While I started with concerns like you have voiced, the more I use the language, the more I like it.
What we've experienced is that while the spec may seem complicated, implementation is often more elegant than the spec may seem to predict. This is not criticism of the spec and I certainly have very high praise for the TG1 team, but we've found that while some of the spec may seem complex, actual usage is often very intuitive. Furthermore, for implementers, there is great leverage of some features across the entire language. For example: adding namespaces, packages, units, block scope and prototypes may seem quite a mouthful to express in the spec -- for implementers, there is an elegant design in all this and once you have the basics of namespaces and block scope you can more easily implement many language features such as getter/setters by using those facilities.
Lastly, as an implementer, having access to the technical materials: grammar, wiki and most importantly the reference implementation and test suite, has been invaluable and greatly accelerated our efforts.
Michael O'Brien
Don't get me wrong - I love most of the new features (some others I'm just indifferent too). But I'm not implementing the interpreter; I would be a user of it. My concern is that of the implementator's burden, and from my point of view, if it takes a long time to implement ES4, it'll be a long time before I can get to use ES4 in practice. What Michael O'Brien just posted sounds very promising though.
I haven't had the time to look at the whole spec as a whole, and since the spec is rather disorganized atm with a bunch of proposals, I'd have a hard time doing that in any case. But what I've seen so far is pretty good. I do kind of feel that there is some redundancy, i.e. there are distinct features that seem to overlap a lot. For example, packages and namespaces are both used to make programs more modular, albeit in different ways. Likewise for program units and packages. But like I said, I don't have a clear view of the spec as a whole, so I'll wait until there are good prose sections describing the usage of features before coming to a conclusion.
-Yuh-Ruey Chen
I know of two industry-scale implementations under way, in addition
to Mozilla's Tamarin project, and Michael O'Brien (mbedthis.com), all
implementing ES4 in the next six to nine months. There's no reason,
zero, apart from will to do something else, why Microsoft (which has
enormous resources, in expert people and money) couldn't do likewise.
Perhaps they yet will -- we don't really know what's coming in IE8 yet.
Give the overview at www.ecmascript.org/es4/spec/overview.pdf
a read and let us know what you think.
On 10/21/07, Brendan Eich <brendan at mozilla.org> wrote:
I know of two industry-scale implementations under way, in addition to Mozilla's Tamarin project, and Michael O'Brien (mbedthis.com), all implementing ES4 in the next six to nine months. There's no reason, zero, apart from will to do something else, why Microsoft (which has enormous resources, in expert people and money) couldn't do likewise. Perhaps they yet will -- we don't really know what's coming in IE8 yet.
Ah, the old can't vs won't debate...
MS could have implemented position:fixed for Microsoft, could have fixed a number of known bugs in JScript, et c.
Give the overview at www.ecmascript.org/es4/spec/overview.pdf
a read and let us know what you think.
"JSON JSON35 is a popular, lightweight, language-independent, textual representation for structured data. It uses a subset of ES3 literal syntax. ES4 provides serialization of data to JSON format through the toJSONString protocol and deserialization through the static method string.parseJSON."
I think it is a bad idea.
I think it is not a critical feature.
String.prototype.parseJSON, returns an object. This is makes no sense.
The current proposal, Object.prototype.toJSONString, complicates objects with responsibility that they should not necessarily have. It will be easy to misuse. It will conflate Object.prototype with implementation details possibly leaking into places they shouldn't. Instead of keeping reduced access, it maximizes access. It does not allow the functionality to be tested and debugged independently.
If these features go in the language, implementations and library authors will be required to handle this method for all objects, of any type, forever. The change will be permanent and intractable.
This feature is not critical; it can be added at any time. The flip side to that is that once added, it cannot be removed. ever.
There are other possible ways JSON could be integrated into the language.
-
JSON could be a host object, something like the XML object.
-
A built in JSON object
A built in JSON object would keep the JSON serialization/parsing independent. It will be easy to learn, easy to extend, easy to read and maintain code that uses it, and it will fulfill the requirements. It won't complicate Object.prototype.
JSON.parseFromString( s ); JSON.toJSONString( jsonObject, pretty );
- A JSON Interface
A JSON interface can be implemented to allow a class to have the JSON Methods as instance methods.
function parseFromString( s, pretty ) : <T>
function toJSONString( );
Test this out with three different types, say: Object, Map, and Array.
Also, If JSON is in the langauge, there would probably need to be some sort of JSONError Error object.
Garrett
(fwd to list - I clicked the wrong button again...)
On 10/21/07, Brendan Eich <brendan at mozilla.org> wrote:
I know of two industry-scale implementations under way, in addition to Mozilla's Tamarin project, and Michael O'Brien (mbedthis.com), all implementing ES4 in the next six to nine months. There's no reason, zero, apart from will to do something else, why Microsoft (which has enormous resources, in expert people and money) couldn't do likewise. Perhaps they yet will -- we don't really know what's coming in IE8 yet.
Give the overview at www.ecmascript.org/es4/spec/overview.pdf a read and let us know what you think.
"RegExp objects can be called as functions (equivalent to invoking their exec method)..."
Example: /foo/('foo')
What is the purpose? To save five characters? e,g, ".exec"
I don't see how it fulfills a use case. It would seem to make code more hot-doggable, and potentially confusing (less explicit)
function bork( a ) { if( a( "foo" ) ) {
} }
Doesn't it look like "a" is a function? Well, maybe in ES4, it's a RegExp.
If I were the code reviewer on that, I would ask the person to use .exec. Why? Because it's confusing. Not everyone will expect that.
Come refactoring time, the next guy who looks at the code will have to familiarize himself right away. He might not be a JavaScript expert whose keen on the latest features. Maybe he's a Backend guy.
Contrast to that:
function mork( a ) { if( a.exec( "foo" ) ) { // Ah, a looks like a RegExp.
} }
How is this feature, callable regexps, justified? Why not just let programmers use .exec?
I say: It's not necessary, it makes the code less explicit. YAGNI!
Garrett
/be
-- Programming is a collaborative art.
On 10/22/07, Brendan Eich <brendan at mozilla.org> wrote:
I know of two industry-scale implementations under way, in addition to Mozilla's Tamarin project, and Michael O'Brien (mbedthis.com), all implementing ES4 in the next six to nine months. There's no reason, zero, apart from will to do something else, why Microsoft (which has enormous resources, in expert people and money) couldn't do likewise. Perhaps they yet will -- we don't really know what's coming in IE8 yet.
Give the overview at www.ecmascript.org/es4/spec/overview.pdf a read and let us know what you think.
I like a lot that overview, can we send the PDF and preview links in the wild or better wait ?
didn't saw at all things as "like" and "wrap", and I love the concept :)
perfectly make sens when you have is-like-a/has-like-a relationship in a prototype based language
On 10/22/07, zwetan <zwetan at gmail.com> wrote:
On 10/22/07, Brendan Eich <brendan at mozilla.org> wrote:
I know of two industry-scale implementations under way, in addition to Mozilla's Tamarin project, and Michael O'Brien (mbedthis.com), all implementing ES4 in the next six to nine months. There's no reason, zero, apart from will to do something else, why Microsoft (which has enormous resources, in expert people and money) couldn't do likewise. Perhaps they yet will -- we don't really know what's coming in IE8 yet.
Give the overview at www.ecmascript.org/es4/spec/overview.pdf a read and let us know what you think.
I like a lot that overview, can we send the PDF and preview links in the wild or better wait ?
Please wait a day or so, an announcement will be made. The final copy will have some bug fixes.
On 22/10/2007, Brendan Eich <brendan at mozilla.org> wrote:
Give the overview at www.ecmascript.org/es4/spec/overview.pdf a read and let us know what you think.
Page 17: "In addition, any value in the language converts to a member of AnyBoolean (undefined, null, zero, and the empty string converting to false and everything else converting to true)."
Doesn't NaN belong in the category that autoconverts to false too?
Thank you...
Hey all,
I've been watching ES4 development and occasionally contributing input, and I have noticed a somewhat disturbing trend. ES4 is getting ever more and more complex.
I understand ES4 is a multi-paradigm language and so must be packed with features, but I don't think we want a repeat of the C++ template problem (where it took nearly a decade just to get most compilers near compliance with the C++ spec). My point is that although a significant update to ES is needed, if it takes too long to implement a conforming compiler/interpreter for it, the adoption of new features is going to be slow. Heck, I wonder how willing MS would be to provide a fully (or near enough to it) conforming interpreter for ES4 if the spec is so large.
Small proposals like bug fixes and reformed with and company, or proposals that generalize syntax to make the language more elegant are perfectly fine by me. But we already have such huge features like classes, generators, namespaces, type system, and now generic functions. Perhaps we should start deferring more features to ES5?
-Yuh-Ruey Chen