Further, people like GVR say things like "In a decade we figure python 3 will be pretty widespread", and "Python 3 isn't really ready for primetime yet, don't use it". Is it really a groundbreaking blog post to mention that people aren't using it now, and that it doesn't work quite the way author expected.
Of course the original author also claimed Python 3 is attempting to maintain some backwards compatibility based on a module which interfaces a system call. And then complains that it should just be a clean break from the past. And after that complains that the new thing isnt the old thing. If that confuses you, don't worry I'm confused too.
In this case I am my own resource, having been a programmer for some 25 years, and observed the slow, but steady adoption of many languages.
The wishlist for 3.0, PEP 3100, was created in August, 2004. PEP 3000 was created on April 5, 2006, and marked the beginning of the development process. A year and a half later, 3.0 was released, and it hasn't even been a year since.
I think Python 3 suffers from attempting to be compatible with Python 2. It should have been a clean break with major repairs and reconstruction, as the original Python 3000 was intended to be. Hang the expense, let's make this language _right_, and Python 2 be damned.
We don't actually know about Perl 6 yet. It's still got a few more months before it's feature complete enough for use in any general case (and performance will probably take another year or two after that to come up to snuff).
But, I strongly suspect that both Perl 6 and Python 3 will be blips on the radar of language history (even while I expect to write quite a bit of code in both before then), as JavaScript will take the place of both for a large class of problems. But it'll be seven to ten years before that shift becomes apparent.
> JavaScript will take the place of both for a large class of problems. But it'll be seven to ten years before that shift becomes apparent.
I'd believe that more if ECMAScript 4 hadn't fallen apart. I'm familiar with the PHP argument that design quality in a language doesn't necessarily harm adoption, but you do need some sort of extensibility to program more than a couple of thousand lines of code.
I think you and I have talked about this in the past. From what I know of the process and where ECMAScript 4 was going, I am not of the opinion that anything particular great has been lost by its falling apart.
JavaScript/ECMAScript evolution has not stopped just because a design-by-committee extension effort failed. There are a few issues with JavaScript for programming in the large, but they won't last. More importantly, perhaps, I think that even if they weren't being fixed at a rapid clip, JavaScript would still end up an extremely popular language, probably even the most popular language, for many classes of problem. Web applications, in particular, but most applications will be web applications in the future, so the planets are aligning for JavaScript.
I will also add that damned near every major technology company has some sort of serious JavaScript effort underway, as we speak. Google, Apple, Adobe, Microsoft, are all extremely serious about JavaScript. Several well-funded teams are building JavaScript engines, some of which are not tied to a particular browser or limited to only running within a browser. Perl and Python will never have that kind of money behind them. Java was in the same position 15 years ago, but it was never a particularly good language for the Perl and Python market (as evidenced by the fact that dynamic language programmers tend to hate, or merely tolerate Java). JavaScript, on the other hand, not only had incredible corporate backing, it also has a large amount of nerd mindshare. Most of the Perl, Python, Ruby, etc. hackers I know don't mind working in JavaScript, and find it a pretty nice language. I certainly enjoy it. Sure, it is lacking a lot of niceties of those other languages, but with the kind of money and effort being spent on JavaScript, it won't be long before those issues disappear.
So, while Java took over the programming marketplace for several years, to the sound of much gnashing of teeth by dynamic language programmers, it never really won mindshare among the folks who programmed for enjoyment (FOSS, in particular). I don't think JavaScript will run into those impediments. It's a good language, and a few nitpicks about missing features or misfeatures aren't going to stop it from being a juggernaut that rolls over most other dynamic languages in terms of popularity.
> ... 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?
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.?
