

Will python 3 ever gain critical adoption? - clutchski
http://entitycrisis.blogspot.com/2009/11/python-3-is-it-doomed.html

======
teilo
This topic has been beaten to death by impatient people who have no
recollection or knowledge of the history of language adoption.

~~~
fnid
Do you have any resources for learning about such history? I'd be quite an
interesting read I think.

~~~
teilo
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.

------
smanek
_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._

That worked really well for Perl 6 ;-)

~~~
SwellJoe
I think I detect a hint of sarcasm.

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.

~~~
chromatic
> 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.

~~~
SwellJoe
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.

~~~
chromatic
> ... 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
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.?

