On Incremental Updates
On Oct 3, 2011, at 9:49 PM, Andrea Giammarchi wrote:
Dear All, while I had the opportunity to ask directly to Brendan Eich this question, I would like to ask you 5 minutes of your precious time to understand common concerns from the JS community, summarized under my point of view in this post:
webreflection.blogspot.com/2011/10/dear-brendan-here-was-my-question.html
I would like to thank you in advance for your time and all possible answers/considerations/questions you may come up with.
My answer at JSConf.eu may have been unclear (to you if not others), so I elaborated on twitter:
On Mon, Oct 3, 2011 at 4:49 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:
Dear All, while I had the opportunity to ask directly to Brendan Eich this question, I would like to ask you 5 minutes of your precious time to understand common concerns from the JS community, summarized under my point of view in this post: webreflection.blogspot.com/2011/10/dear-brendan-here-was-my-question.html I would like to thank you in advance for your time and all possible answers/considerations/questions you may come up with.
Everyone else here is, I'm sure, better qualified to answer that question, but here's my take on it. I'm not opposed to some kind of a 5.3 release to get some non-breaking performance additions into the spec, but I would disagree with the general notion that some of the other language changes aren't a priority. Block scoped bindings, modularity, and private name objects can't be simulated with the type of simple conversion that coffeescript does. Hopefully something will be done about the complicated "class" pattern so that we don't need a million different incompatible libraries. Finally, let's not forget all the work done in ES5 involving property attributes that might follow the same fate unless the configuration of them is easy as seen in the object literal extensions.
As much as every JavaScript advocate usually cringes at the comparison of JavaScript to Java, it is a little funny that right now I think they are in a little bit of the same situation. The JVM and JavaScript are both becoming highly desirable targets of alternative programming languages. I think this is awesome, and important, but we can't let the language stagnate just because there is innovation in other languages that target the platform. Java now looks like a dinosaur and people have been predicting that while the JVM will live on, the language will start to die. I'd hate to see the same thing happen to JavaScript.
On the other hand, I'd also hate to see ES4 part 2.
Brendan, thanks for the follow up, I also discovered the existence of bettween, great!
Russel, ES4 part 2 is what I'd like to avoid too and this is my point indeed.
I am not saying that let, yeld, {block scope}, and destructuring is not welcome and cool, these are all part already available since ages in Mozilla browsers extensions, and scripts themselves if type contains the version attribute.
However, I find a bit paradoxical/hilarious a situation "like this" in 2013 web pages:
<script type="application/javascript;version=es6" src="es6code.js"
</script> <noscript> <script type="text/javascript" src="es5code.js" </script> </noscript>
In these days any sort of effort is spent to create polyfills for ES5.1 since this is the step forward the web needed since 2005.
Following the current ES6 direction we won't be able to fill the gap except including a revisited version of CoffeeScript in every single page in order to inject a routine per each non compatible browser able to grab scripts content on the fly and parse them in order to obtain cross platform compatibility.
An intermediate release with just 3 new constructors such StructType, ArrayType, and ParallelsArray, could be a much easier target for all browsers, desktop and mobile.
Same could be the introduction of Object.createClass({... definition ...}), if class has still any sort of meaning in a prototypal language.
The "let" concept could be introduces in a less breaking way. We do not have the ability to fake it but we all have the ability to block pieces of code:
{ var local = true; } typeof local; // "undefined"
A directive like "use strict,blockscope"; could be friendly and the engine could change all scoped var into let statements.
This could potentially break some code due difficulty to shim properly the syntax for older engines, but developers can decide if they want to "take the risk", avoiding variable names conflicts in the same scope, or not.
As summary, all I am saying is that ES5 and ES5.1 has been the best thing happened ever to JavaScript as we know it while ES6, and all its new syntax changes, will take years before it can be widely adopted and improved, and these years in between will put JavaScript into an even worse position where JS developers will ask themselves: what is exactly JavaScript ?
Thanks in any case for your answer.
Best , Andrea Giammarchi
On Mon, Oct 3, 2011 at 9:18 PM, Russell Leggett <russell.leggett at gmail.com>wrote:
As much as every JavaScript advocate usually cringes at the comparison of JavaScript to Java, it is a little funny that right now I think they are in a little bit of the same situation. The JVM and JavaScript are both becoming highly desirable targets of alternative programming languages. I think this is awesome, and important, but we can't let the language stagnate just because there is innovation in other languages that target the platform. Java now looks like a dinosaur and people have been predicting that while the JVM will live on, the language will start to die. I'd hate to see the same thing happen to JavaScript.
I don't think there is any evidence that Java's decline relates to any addition or lack of addition to the language. Java's decline simply reflects the decline of runtime it is particularly well suited for. Similarly JavaScript's future is more closely tied to the future of the browser than to changes in the language.
Please note that I did not say that JavaScript should not change. The important work of this group contributes to the overall vitality of the platform and improves the work of many, many developers.. I am only pushing back on the evidence supporting change for change sake.
On the other hand, I'd also hate to see ES4 part 2.
I am encouraged by the potential for class features to be dropped from ES.next. I wish we had more experimental implementation work tried by developers before specs. I wish we had more user-study information from the existing class-like libraries to inform the discussions. The feature is too complex to know the answers intuitively.
jjb
On Oct 3, 2011, at 9:18 PM, Russell Leggett wrote:
On the other hand, I'd also hate to see ES4 part 2.
Having been there I can assure you that the current state of ES.next development is nothing like ES4. The most import difference is that ES4 incorporated core concepts that were still computer science research topics.
There are no such research risks in the proposed ES.next features. There is a lot of language design and engineering to be completed, but nothing that truly breaks any new ground that hasn't been tested in other successful languages.
The other big difference is that ES4 never really got to the point of having a real specification draft because it never got out of the research stage. The specification work for the ES6 is well underway. By the end of this calendar year many of the new ES.next features will be completely specified in the draft enabling browser builders to start building and interoperable implementation of those features. Sure there is a lot on the table, and eventually we may have to cut some features to make our target dates. But that's just the reality of software engineering.
Regarding, incremental updates: A well designed language is a collection of orthogonal features that can be used in powerful combinations to solve problems. The individual features need to be designed to support such composition. In doing such design, often some semantic detail or usage case will move from one feature to another features. When you design and release features in isolation you loose the opportunity for making such trade-off. To make matters worse, each released feature constrains what can be done with future features. It's a bad idea to design language features in isolation.
A successful language has too evolve over a multi-decade lifetime. Changes and extensions can't all be accomplished at one tine, so there has to be incremental evolution. However, the sweet spot for language evolution is neither very frequent very small changes nor very seldom very large changes. It's something in the middle. This is the path we are trying to follow in TC39 with ES.next.
Dear All, while I had the opportunity to ask directly to Brendan Eich this question, I would like to ask you 5 minutes of your precious time to understand common concerns from the JS community, summarized under my point of view in this post:
webreflection.blogspot.com/2011/10/dear-brendan-here-was-my-question.html
I would like to thank you in advance for your time and all possible answers/considerations/questions you may come up with.
Dear All, while I had the opportunity to ask directly to Brendan Eich this question, I would like to ask you 5 minutes of your precious time to understand common concerns from the JS community, summarized under my point of view in this post: http://webreflection.blogspot.com/2011/10/dear-brendan-here-was-my-question.html I would like to thank you in advance for your time and all possible answers/considerations/questions you may come up with. Cheers, Andrea Giammarchi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111003/37c233d0/attachment.html>