4 ms·

> ... with the kind of money and effort being spent on JavaScript, it won't be long before those issues disappear. I thought that too, but Microsoft's "You can

> ... with the kind of money and effort being spent on JavaScript, it won't be long before those issues disappear. I thought that too, but Microsoft's "You can't break the Intranet!" argument was enough to kill ECMAScript 4. I lost a lot of faith in JavaScript's near term future then. In the interest of having a more productive discussion, what concrete signs give you hope that time and money and effort will address JavaScript's missing features?

SwellJoe 17y ago
I was never under the impression that Microsoft alone killed ECMAScript 4. My impression was that pretty much everyone except Adobe was dissatisfied with the process and the resulting standard. I wasn't particularly impressed with what I knew about it, either, to be honest, though my knowledge is limited, at best. The 5th edition fixes several earlier specification failures, that led to incompatible implementations, which will resolve a number of issues with having to maintain multiple implementations of code to support multiple JavaScript engines (though this is less of a concern on the server-side). JavaScript 1.6, 1.7, 1.8, and 1.9, as found in Mozilla browsers, include block scope (with let), generators ala Python, more object methods for Array and String, etc. JavaScript already had closures, first-class functions, reasonable scoping abilities, etc. The biggest arguments against it seem to stem from the fact that everybody has to dip into the global scope a little bit, and that OOP primitives are somewhat...primitive. But, both can be reasonably worked around, even in current implementations. Packages and modules, and advanced OOP have been implemented independently by dozens of people (much as various OO patterns have emerged from Perl's OOP primitives, including Moose, which I know you agree is the current Right Way to do OO in Perl...even though it is not part of the core language). All the major JS libraries that seek to address such things have some sort of module/package and namespace functions built in. ECMAScript 5 even introduces a strict mode, roughly akin to strictures in Perl, and even uses roughly the same syntax to turn it on ( "use strict"; ) and it is available with function scope. So, assuming it becomes no longer mandatory to dip your toe into global scope in every program or library (if only to start your own namespace), JavaScript will have no major issues that I'm aware of. Block scope is already more than most dynamic languages have (Ruby and Python both still lack it, as far as I know, though Perl has it), and I'm guessing that since it's been in the Mozilla JS for some time now, it's inevitable in the spec. Anyway, despite any missing features or misfeatures you might perceive, there are already hundreds of large (hundreds of thousands of lines of code) projects in JavaScript. I just think that adoption will accelerate and expand to the server side, particularly as the few remaining issues are resolved. I wonder what concrete signs you see that make you think that all the money and effort (which is orders of magnitude larger than the amount being spent on Perl, Python, and Ruby combined) won't result in a language and implementations that are adopted widely for a large class of problems currently being solved by Perl, Python, Ruby, PHP, etc.?

SwellJoe 17y ago

I was never under the impression that Microsoft alone killed ECMAScript 4. My impression was that pretty much everyone except Adobe was dissatisfied with the process and the resulting standard. I wasn't particularly impressed with what I knew about it, either, to be honest, though my knowledge is limited, at best. The 5th edition fixes several earlier specification failures, that led to incompatible implementations, which will resolve a number of issues with having to maintain multiple implementations of code to support multiple JavaScript engines (though this is less of a concern on the server-side). JavaScript 1.6, 1.7, 1.8, and 1.9, as found in Mozilla browsers, include block scope (with let), generators ala Python, more object methods for Array and String, etc. JavaScript already had closures, first-class functions, reasonable scoping abilities, etc. The biggest arguments against it seem to stem from the fact that everybody has to dip into the global scope a little bit, and that OOP primitives are somewhat...primitive. But, both can be reasonably worked around, even in current implementations. Packages and modules, and advanced OOP have been implemented independently by dozens of people (much as various OO patterns have emerged from Perl's OOP primitives, including Moose, which I know you agree is the current Right Way to do OO in Perl...even though it is not part of the core language). All the major JS libraries that seek to address such things have some sort of module/package and namespace functions built in. ECMAScript 5 even introduces a strict mode, roughly akin to strictures in Perl, and even uses roughly the same syntax to turn it on ( "use strict"; ) and it is available with function scope. So, assuming it becomes no longer mandatory to dip your toe into global scope in every program or library (if only to start your own namespace), JavaScript will have no major issues that I'm aware of. Block scope is already more than most dynamic languages have (Ruby and Python both still lack it, as far as I know, though Perl has it), and I'm guessing that since it's been in the Mozilla JS for some time now, it's inevitable in the spec. Anyway, despite any missing features or misfeatures you might perceive, there are already hundreds of large (hundreds of thousands of lines of code) projects in JavaScript. I just think that adoption will accelerate and expand to the server side, particularly as the few remaining issues are resolved. I wonder what concrete signs you see that make you think that all the money and effort (which is orders of magnitude larger than the amount being spent on Perl, Python, and Ruby combined) won't result in a language and implementations that are adopted widely for a large class of problems currently being solved by Perl, Python, Ruby, PHP, etc.?