It just might be possible that Perl 6's crazy long development process can
produce the best-adopted second system around
Unfortunately, I don't share the same optimism as the OP. In the real world, adoption is not only driven by how cool a language is, but the ecosystem of tools and developers around it. There are lots of Perl 5 codebases which won't be migrated because it's too expensive.
The true lesson learned for language developers is: Don't break backwards compatibility. Ever.
The Python community made this mistake, and they acknowledge it. Guido said this won't happen again. But at least for the case of Python 3, the number of breakages is relatively small, and the migration from 2 to 3 while tedious, it's not that hard. Even so, the migration of the whole ecosystem has been really really slow. But I think in the end the community will move.
The Perl case, on the other side, is much worse. Migrating a relatively complex project from 5 to 6 is extraordinarily hard. It's probably the same as a whole rewrite. Also, the community is divided, with some developers keeping the improvement of Perl 5, fixing bugs and adding new features. There is no incentive for migration.
If the migration has been so slow for Python 3, which had a much smaller barrier, I don't see how it could be better for Perl 6.
New languages are able to develop a new ecosystem when they introduce innovative features, e.g. Rust. But Perl 6 while being a nice language, doesn't seem to have any killer feature compared to mainstream languages.
The more I think about it, the more I realize that Perl 6 was misnamed. It should have been treated as a new language with some Perl heritage, not just a new version of Perl.
The Perl 5 diehards aren't going to switch, and people who aren't already Perl hackers are going to think it's the same old Perl that scared them off ages ago.
It's a shame, because Perl 6 is a great language (and I say this as somebody who was put off by Perl 5), and the Parrot VM is particularly awesome.
It also has some of the best error reporting I've seen: it offers a number of possible solutions, and if you try to use a Perl 5-ism that's not supported anymore, it'll tell you what the Perl 6 equivalent is.
Yes, rewriting Perl 5 in Perl 6 would be quite an endeavor. However, that's why Inline::Perl5 was invented. It lets you use Perl 5 libraries in Perl 6 code:
use Inline::Perl5;
use MyProprietaryModule:from<Perl5>;
use YAML:from<Perl5>; # take advantage of p5 cpan
my $foo = YAML::LoadFile('foo.yaml');
my $bar = MyProprietaryModule.someMethod('baz');
So what this allows you to do is use P6 features where they might benefit your project, but still use all the P5 code you've invested in. There are some cases where Inline::Perl5 has problems, such as running P5 code multithreaded, but aside from that I've had few problems using it with stuff from CPAN and with my company's own proprietary code base.
There are also the modules Inline::Python and Inline::Java (for the JVM backend), but I haven't used them.
"The Perl case, on the other side, is much worse. Migrating a relatively complex project from 5 to 6 is extraordinarily hard. It's probably the same as a whole rewrite."
One of the features of Perl 6 discussed in the article is "Fully backwards compatible with the use of Inline::Perl5". So why is it extraordinarily hard to migrate? I admit it is non-trivial, but the designers made it a key point to be backward compatible. No need to rewrite, Perl5 and Perl6 can co-exist in the same codebase.
"There is no incentive for migration."
Have you looked at the features Perl6 provides[1]? They may not seem valuable to you but it cannot be denied that the new features are plentiful and powerful from a programming language perspective. [1]http://www.perlfoundation.org/perl6/index.cgi?the_long_perl_...
I would never say it is likely that any language will be well-adopted. Fortune plays too big a role.
However, what Perl's long development cycle means is that its widespread adoption would depend on new users taking it up. It will be a new language from their standpoint and backward compatibility will be less an issue.
Widespread adoption will also require transitioning of a core group of existing Perl power users. After 15 years, all the emotionally inflamed debates, tirades and rants have probably run their course. Everyone knows where they stand and has had time to come to piece with it...and even the youngest among those who have been there since the decision are long out of short pants. Zealots on both sides have been living together a long time.
> The true lesson learned for language developers is: Don't break backwards compatibility. Ever.
Certainly true, and yet this is the situation that led to a lot of the hate for C++.
The reason for the numerous meanings of the "static" keyword for example is because if you introduce more keywords then you might break peoples code that used those proposed keywords as variable names.
And then of course a large percentage of C++'s baggage is due to backwards compatibility with C in the first place. Without that baggage C++ would be a much better language and yet you can't deny C++'s success from that decision.
So the moral of the story is that you either make a language nobody uses or you continue to cop flak for all your old decisions forever.
>>In the real world, adoption is not only driven by how cool a language is, but the ecosystem of tools and developers around it.
If it gets even half close to where Perl 5 is we can only expect great things from Perl 6.
>>The true lesson learned for language developers is: Don't break backwards compatibility. Ever.
If you look at the whole grammar system and the compiler design of Perl 6 you will see this is precisely what they have done.
>>Guido said this won't happen again.
Not that easy. To compete with newer and powerful tools you have to add features that you need. You can't do that without bloat or breaking things. Again look up the Perl 6 compiler design.
>>Migrating a relatively complex project from 5 to 6 is extraordinarily hard.
This is like saying migrating from C to Java is hard. Of course it is, because 5 and 6 are two different languages.
>>There is no incentive for migration.
There never ever was and should never be, Perl 6 is for new projects. Perl 5 and Perl 6 are two different languages which will have their own evolution path.
>>But Perl 6 while being a nice language, doesn't seem to have any killer feature compared to mainstream languages.
I think the author is mischaracterizing all of these examples; none of them are "second systems" but major revisions of software with large install bases and no built-in update mechanism. They are reliant on distributions and third parties to provide any form of automatic update; oftentimes the upgrade path without distribution-level support is painful for an average user.
Certainly, in the case of PHP, it was a very painful process to get major adoption of 5 - especially as so many of the users are reliant on managed hosting. It took a long time for the install base to grow there; PHP 7 will similarly take a long time to get up there. At least the decision to scrap 6 (a decision also taken in light of all of the literature out there describing the features of 6) was a pragmatic one; PHP 7 is now just around the corner.
What the author is describing are two general problems for any software development where there is a large install-base: development cycles and release management. Just look at uptake numbers for operating systems for an example as to why this is absolutely not a problem confined to scripting languages or even OSS software: http://en.wikipedia.org/wiki/Usage_share_of_operating_system...
The transition from PHP3 to PHP4 and from PHP4 to PHP5 wasn't that painful. At the time, most PHP open source projects simply avoided OO concepts due to their slow implementation in PHP4 and to be downwards compatible with PHP3. It solved the transition as they only slowly adopted class based OO later in PHP5 era. Also the transition period of parallel version of PHP4 and 5 was between 2004 and 2008 - long enough so that most shared hosters were able to make the switch. PHP6 failed, and most planned features were backported to PHP5.3+. As several books were published in the months before the planned PHP6 release, the next PHP version will be named PHP7 to avoid any confusion. Nevertheless, PHP7 isn't a bigger change than let's say PHP 5.2 to 5.3. Overall I would say, PHP's developers and the community has done a great job. Modern PHP.net and HHVM are certainly better than their reputation. The same goes for MySQL and MariaDB.
Adoption of PHP5 was a pain, but still it was quicker than adoption of Python 3. At least the community was all behind PHP5 and there was a major push towards it.
I think PHP has dodged the bullet by taking PHP6 apart and reintroducing features piecemeal in PHP 5.3+.
> Well, after a little over six years of development, we discovered that we were never going to see a PHP 6 at all. Having seen how long Perl 6 had taken, and how long PHP 6 was taking, the number 6 is associated with failure. So they cancelled PHP 6 and voted to change the name to PHP 7.
Uh, what? Did the author do the most basic of research?
PHP 6 was a real thing, a development branch. But it dragged on for years.
Due to delays, they made an interim release in the 5.x series, PHP 5.3. It backported some stuff from 6.
Eventually, PHP 6 was killed off because it just wasn't going to work. So they made another 5.x release, PHP 5.4, backporting more stuff from 6, and adding some other features.
After that, with PHP 6 dead and gone, work focussed on the PHP 5.x series again. So out came PHP 5.5 (2013) and PHP 5.6 (2014).
During this time, some people did some experiments and realised it was possible, by breaking internal (not userland) compatibility, to greatly improve PHP's performance. This project became phpng. Since it would break so many (internal) things, they decided that if it should be merged into PHP, it needed to go into a new major version.
It was after this that the ridiculous version number vote was held. I don't see why we ever had that debate, really. PHP 6 was a thing and was killed off, re-using the version number was silly. Anyway, the number chosen was PHP 7.
Fast forward to the present day: PHP 7 has gone into feature freeze and should be released in a few months. Alongside the performance improvements of phpng, it has some other new features developed independently, and includes a few deliberate backwards-compatibility breaks.
tl;dr: the time line goes: 5.2 release, work begins on 6.0, 5.3 release, 6.0 killed off, 5.4 release, 5.5 release, 5.6 release, 7.0 in development.
So for anyone wondering about this, phpclasses was the answer to PEAR, which itself was trying and failing to be CPAN. PEAR ended up being laughable and underwhelming, while phpclasses ended up being a breeding ground for some of the worst PHP code on the planet.
Nobody should be using it and anyone pointing to anything on it as a good example should be laughed at.
Meanwhile, the article author probably needs to read this slide deck from the PHP6 team explaining exactly where the breakdown occurred:
There's nothing that will convince the Python 3 haters. So silly. I use nothing but Python 3 and I rarely if ever find I can't move ahead for lack of a library. The Python2 only libraries are just being replaced with more up to date alternatives. This article is total FUD and garbage from yet another Python 2 ideological holdout dogmatist.
This article would have you believe that if you tried to use Python 3 that within hours you would hit a library roadblock that would be a showstopper. Completely wrong, and you have to ask why the author wants to create this perception.
Python 3 works beautifully and is a pleasure to program.
If you WANT to hate Python 3 then you'll find no lack of ways to hate on it for the next 20 years (HEY! I found some package built by a fellow Python2 holdout! See, it simply is not possible to write the code to upgrade it! PYTHON 3 IS FINISHED! THE SKY IS FALLING!) etc etc ...
If you want to succeed with Python 3 then that's easily done, you just get on with it.
No one using Python 3? Flat out lie. Prove me wrong by scientifically explaining your assertion that no one uses Python 3. Lies, spoken to back the wishes of the Python2 holdouts to sabotage Python 3 - they hate Python 3 and will say any lie to bring it down and spread the FUD. I'm wrong? Prove it in detail with science. Alternatively make vague, handwavey statements about downloads, as though that defines how many people are writing code today with a language.
Which article did you read - I don't see any of the claims you are suggesting they made. I even did a search for the word, "library" - it never appears.
If anything, based on my read of the article (twice, I had to read it a second time after reading your comment) - I think it's actually written by a Perl advocate who is ruminating on the future of Perl 6, and just using Python as an example of a team that shipped code fast and limited the amount of stuff they broke.
Did you read a different article? The author only had positive things to say about python3 except its adoption (which has been noted to be an issue multiple times before this article existed). You are blowing the author's intent way out of proportion.
As someone writing applications using Python 3, I found the switch to be easy and I haven't had any problems with libraries. I've switched from some of the old ones I was using to more modern alternatives that are being actively developed.
It annoys me that there are people on Python 2 that haven't really tried to make the switch and stand on the sideline shouting insults at Python 3. It's a tremendously self destructive thing to do for all involved.
To anyone looking to get started with Python, there's no real reason to start with Python 2 these days.
Some current facts: ~17% of packages on PyPI support Python 3 and ~5% of packages downloaded from PyPI are downloaded for Python 3.
If you start a project today then yes, start with Python 3. But if you have a Python 2 codebase you're likely to have (1) one or more dependencies that haven't been ported yet, (2) no solid economical reasons to convince your employer to switch or (3) no sufficient technical reasons in switching at this point (which may change as more Python 3.x versions are released).
I was scared off of Python3 until recently for no good reason. When I started a new development effort I made the switch and have had almost no problems besides a few small configs I had to work through. Besides that and going over some new syntax and recommended techniques I spent maybe 1-2 days all in. It's seriously not that big of a deal.
The problem isn't that there are problems with going to Python 3. The problem is there isn't enough benefit to make any change worthwhile for most users.
I have my problems with the Python 3 implementation. Unicode is great, but standard library APIs should understand each other without the need to call decode.
I like the way the change was rolled out, though:
1. Find a defined amount of cruft that needs to be fixed backwards incompatibly, so you do not take 15 years for it or fail completely. Release a new major version.
2. Make one or two minor releases to the older version to ease the upgrade.
3. Then STOP developing the older version, work with the community and perfect the new version to get everyone on board.
I think it is the perfect middle ground. If you do this constantly you will not have the need to change everything at once and will also not amass cruft.
The problem with the justification of the author for 15 years of Perl 6 development is, that Perl 6 will have issues, too. Are you going to change them all at once again and take another 15 years for Perl 7?
The problem with the justification of the author for 15 years of Perl 6 development is, that Perl 6 will have issues, too. Are you going to change them all at once again and take another 15 years for Perl 7?
Learning from experience, one of the design goals of Perl6 was the ability gracefully evolve. Thus you get an object system with meta-object protcol, and you can extend the syntax through user-defined grammars. This probably also factored into the decision to have Rakudo support multiple backends.
> Unicode is great, but standard library APIs should understand each other without the need to call decode.
If one "standard library API" generates integers and an other consumes strings, would you expect the second one to take the output of the first one without conversion?
This post made me move to Python 3.
I replaced all print statements, in the code I am currently working on, with print functions, and yum-installed python3 versions of the libraries.
The code ran correctly on first try. Guess I was lucky, should have made the shift earlier!
Does your code use division, and do you have unit tests for at least those parts? Because the same code will compile and run in either version, but you'll get different results, depending.
This is ridiculous. The author makes it sound like perl6 is more of a success than python3 -- despite python3 being used for real projects for years now, and perl6 being "slow and about to have its first release" (just like it was for the last, I don't know, 7 years?). I mean, come on.
IMHO, the practical best-case scenario for Perl 6 at this point is a Lisp-like status where the language itself does not see much commercial use, but ideas from it fuel innovative attempts in existing and new languages. That would be the best-case though, and it might just bomb and be forgotten within months, which in fact seems to be the common expectation from many.
In any case, this was one of the most unabashedly biased articles I've seen on HN, with badly made attempts at revisionistic history. Perl is still my favourite scripting language, but even I have to admit that Perl 6 has little hope of adoption, and Perl 5 is dying a slow and painful death: due to the momentum, clarity and leadership and P6 took away from it. A few ported-back features gained can't possibly make up for the lack of a cohesive vision that resulted from nobody being sure of the status of the Perl 5 language. Subroutine arguments have long languished in interminable bikeshedding due to this (despite actually having a few enthusiastic implementors - a rare phenomenon in P5 world now!), and we have embarrassments like autoderef and smartmatch[1] which reduce people's trust in the language even more.
What makes the situation truly infuriating though, is the snarky and superior attitudes taken by most P6 folk, just like this article exhibits. Even if you begin with an attitude of collaboration, it soon begins to feel like you're talking to King Joffrey, with that ever-condescending smile of his.
So what is different about the Ruby approach to language evolution? The community has moved forward relatively painlessly from 1.8.x to 1.9.x to 2.x, all of which had breaking changes. Why has change been such an issue for e.g. Python?
I wonder if Typescript will serve as a lesson to us all. It feels like the next generation of JavaScript, and (can) compile to ES(really old) without adding too much ugly Dart-like cruft.
Another interesting subject only slightly touched on here has been the degree to which Perl 6 features have been slowly rolled in to Perl 5; maybe Perl 5.30 will look a great deal like Perl 6.
Javascript seems destined to eventually dominate the "scripting" language space. It just has unstoppable momentum now. The pace of evolution of the language and the implementations puts Perl, Python, PHP and Ruby in the shadows. And I say that as someone that really likes Ruby and is happy enough writing Python.
Typescript may serve as another showcase for Microsoft tactics to influence and steer a language (JavaScript/ES6 & 7). http://en.wikipedia.org/wiki/Embrace,_extend_and_extinguish You know the Java vs. MS Java (later transformed to C#) - both MS Java/J++ and C# as well as Typescript were guided by Anders Hejlsberg (former Turbo Pascal fame).
I can run Fortran IV code on a modern compiler without change.
2015-1966=48 years. And counting.
Ada95 was a very easy transition from Ada83.
Pay attention to users ! Backwards compatibility is MANDATORY for a language.
Please consider the time it takes for a new language to be fully developed and to take hold. These major revisions are simply new languages, because they _break backward compatibility_.
Yes, and in the mean time: Go, Rust, Dart, Julia... maybe someone someday will get the sweet spot of performant code that is just plain fun to write. I guess that was the idea with PyPy, but after 15 (?) years that goal is still a ways away.
With regard to Python 3's print statement, I don't understand it. Or rather, I don't understand why they changed only the print statement. If nothing else, raise and assert should have had the same treatment.
And Python 3's unicode handling isn't sane. Or rather, it is saner internally, but not sane on the interface. I mean, recreating `cat` is bad enough. Python 3 made unicode handling slightly easier and byte handling gratuitously harder.
But this is probably bikeshedding.
Personally, the bigger problem is not creating a relatively frictionless upgrade path. If you can't run things on the new version without manual editing, you won't move over unless everything you depends on moves over. Catch-22. Python is slowly moving over, largely because a) it's not generally too difficult to port the code (and largely automated to boot), and b) you can relatively easily write code that works on both versions.
My main problem with Perl 6 is that it seems overly large and complex. It is very different from Perl 5, there is effectively no up to date tutorial, and I'm overwhelmed by Perl 6's apparent complexity.
Perl, Python, and PHP: or why PHP just sucks because I can't figure out its benefits and Python 3 sucks because change and Perl sucks because Perl. Every language solves some problems well and some not so well. Why does everyone (figuratively) bash other languages simply because they aren't quite right for your particular use case??
This was a fascinating article to me, a python2 user.
I suspect there are three large subsets of readers, where the process described for "their" language is familiar, and those for the other two languages sound like tales of "inside baseball."
I am familiar with the progress and arguments related to python2/3. I am aware, from a distance, of similar issues with perl5/6 and php5/6/7.
It occurs to me that I haven't heard about similar breaking shifts for other currently active languages, including C and C++. I'm dimly aware that Java recently moved to 8(?) and 9(?) is starting(?). And I wonder about Fortran, which I'm dimly aware still has active users and some standards process.
Can anyone who is familiar with these languages' progress characterize them as breaking and angst-ridden, or smooth and relatively trouble free, and say why? What's different about the process and community from the three languages in the article?
For a possible initial point of contrast, my impression of the three languages' changes are that they are all but new languages that are easy to read for anyone familiar with previous versions.
I think that Brooks' Second System Syndrome assumes that there is actually a compelling reason for the second system. A language is more subtle in that the value there is mostly in the convention of how to do things. In any case where you make a big change to a language there are always going to be people who either don't agree with the change or simply don't think the change is worth the bother.
There are zillions of proposals for new languages around at any particular moment in time. Very few ever become popular. If you significantly change a currently popular language then there is a good chance that you will fall off the side into unpopularity.
Except Perl 6 isn't a "Second System", but rather a "Third System"; Perl 4 (for whatever god-forsaken reason) is to this day still mentioned in the Perl documentation in various places, despite being about 2 1/2 decades old and having been effectively abandoned in favor of Perl 5 for nearly as long. Perl 4 and Perl 5 are pretty much entirely different languages, and Perl 6 is just an extension of that heritage.
The 5->6 transition might be more painful because of how long Perl 5 has been around and in active use, but this isn't exactly new to a whole lot of veteran Perl programmers.
Unfortunately, most of this post is just content-free snark, pissing on certain (phases of) languages with no effort whatsoever to provide any insight beyond the author's prejudice.
Apparently the "gratuitous negativity" guideline doesn't apply to content.
Edit: And let's not forget that 99% of the criticism levelled at those languages has nothing at all to do with Second System Syndrome. That very valid subject is apparently just an excuse to go on a rant.
[+] [-] ceronman|11 years ago|reply
The true lesson learned for language developers is: Don't break backwards compatibility. Ever.
The Python community made this mistake, and they acknowledge it. Guido said this won't happen again. But at least for the case of Python 3, the number of breakages is relatively small, and the migration from 2 to 3 while tedious, it's not that hard. Even so, the migration of the whole ecosystem has been really really slow. But I think in the end the community will move.
The Perl case, on the other side, is much worse. Migrating a relatively complex project from 5 to 6 is extraordinarily hard. It's probably the same as a whole rewrite. Also, the community is divided, with some developers keeping the improvement of Perl 5, fixing bugs and adding new features. There is no incentive for migration.
If the migration has been so slow for Python 3, which had a much smaller barrier, I don't see how it could be better for Perl 6.
New languages are able to develop a new ecosystem when they introduce innovative features, e.g. Rust. But Perl 6 while being a nice language, doesn't seem to have any killer feature compared to mainstream languages.
[+] [-] amyjess|11 years ago|reply
The Perl 5 diehards aren't going to switch, and people who aren't already Perl hackers are going to think it's the same old Perl that scared them off ages ago.
It's a shame, because Perl 6 is a great language (and I say this as somebody who was put off by Perl 5), and the Parrot VM is particularly awesome.
It also has some of the best error reporting I've seen: it offers a number of possible solutions, and if you try to use a Perl 5-ism that's not supported anymore, it'll tell you what the Perl 6 equivalent is.
[+] [-] muraiki|11 years ago|reply
There are also the modules Inline::Python and Inline::Java (for the JVM backend), but I haven't used them.
[+] [-] somebehemoth|11 years ago|reply
One of the features of Perl 6 discussed in the article is "Fully backwards compatible with the use of Inline::Perl5". So why is it extraordinarily hard to migrate? I admit it is non-trivial, but the designers made it a key point to be backward compatible. No need to rewrite, Perl5 and Perl6 can co-exist in the same codebase.
"There is no incentive for migration."
Have you looked at the features Perl6 provides[1]? They may not seem valuable to you but it cannot be denied that the new features are plentiful and powerful from a programming language perspective. [1]http://www.perlfoundation.org/perl6/index.cgi?the_long_perl_...
[+] [-] brudgers|11 years ago|reply
However, what Perl's long development cycle means is that its widespread adoption would depend on new users taking it up. It will be a new language from their standpoint and backward compatibility will be less an issue.
Widespread adoption will also require transitioning of a core group of existing Perl power users. After 15 years, all the emotionally inflamed debates, tirades and rants have probably run their course. Everyone knows where they stand and has had time to come to piece with it...and even the youngest among those who have been there since the decision are long out of short pants. Zealots on both sides have been living together a long time.
[+] [-] Negitivefrags|11 years ago|reply
Certainly true, and yet this is the situation that led to a lot of the hate for C++.
The reason for the numerous meanings of the "static" keyword for example is because if you introduce more keywords then you might break peoples code that used those proposed keywords as variable names.
And then of course a large percentage of C++'s baggage is due to backwards compatibility with C in the first place. Without that baggage C++ would be a much better language and yet you can't deny C++'s success from that decision.
So the moral of the story is that you either make a language nobody uses or you continue to cop flak for all your old decisions forever.
[+] [-] kamaal|11 years ago|reply
If it gets even half close to where Perl 5 is we can only expect great things from Perl 6.
>>The true lesson learned for language developers is: Don't break backwards compatibility. Ever.
If you look at the whole grammar system and the compiler design of Perl 6 you will see this is precisely what they have done.
>>Guido said this won't happen again.
Not that easy. To compete with newer and powerful tools you have to add features that you need. You can't do that without bloat or breaking things. Again look up the Perl 6 compiler design.
>>Migrating a relatively complex project from 5 to 6 is extraordinarily hard.
This is like saying migrating from C to Java is hard. Of course it is, because 5 and 6 are two different languages.
>>There is no incentive for migration.
There never ever was and should never be, Perl 6 is for new projects. Perl 5 and Perl 6 are two different languages which will have their own evolution path.
>>But Perl 6 while being a nice language, doesn't seem to have any killer feature compared to mainstream languages.
Seriously?? Have you even looked at Perl 6.
[+] [-] raiph|11 years ago|reply
Are you willing to share any details of the project you migrated?
[+] [-] agumonkey|11 years ago|reply
[+] [-] choult|11 years ago|reply
Certainly, in the case of PHP, it was a very painful process to get major adoption of 5 - especially as so many of the users are reliant on managed hosting. It took a long time for the install base to grow there; PHP 7 will similarly take a long time to get up there. At least the decision to scrap 6 (a decision also taken in light of all of the literature out there describing the features of 6) was a pragmatic one; PHP 7 is now just around the corner.
What the author is describing are two general problems for any software development where there is a large install-base: development cycles and release management. Just look at uptake numbers for operating systems for an example as to why this is absolutely not a problem confined to scripting languages or even OSS software: http://en.wikipedia.org/wiki/Usage_share_of_operating_system...
[+] [-] castell|11 years ago|reply
[+] [-] pornel|11 years ago|reply
Adoption of PHP5 was a pain, but still it was quicker than adoption of Python 3. At least the community was all behind PHP5 and there was a major push towards it.
I think PHP has dodged the bullet by taking PHP6 apart and reintroducing features piecemeal in PHP 5.3+.
[+] [-] cygx|11 years ago|reply
[+] [-] TazeTSchnitzel|11 years ago|reply
Uh, what? Did the author do the most basic of research?
PHP 6 was a real thing, a development branch. But it dragged on for years.
Due to delays, they made an interim release in the 5.x series, PHP 5.3. It backported some stuff from 6.
Eventually, PHP 6 was killed off because it just wasn't going to work. So they made another 5.x release, PHP 5.4, backporting more stuff from 6, and adding some other features.
After that, with PHP 6 dead and gone, work focussed on the PHP 5.x series again. So out came PHP 5.5 (2013) and PHP 5.6 (2014).
During this time, some people did some experiments and realised it was possible, by breaking internal (not userland) compatibility, to greatly improve PHP's performance. This project became phpng. Since it would break so many (internal) things, they decided that if it should be merged into PHP, it needed to go into a new major version.
It was after this that the ridiculous version number vote was held. I don't see why we ever had that debate, really. PHP 6 was a thing and was killed off, re-using the version number was silly. Anyway, the number chosen was PHP 7.
Fast forward to the present day: PHP 7 has gone into feature freeze and should be released in a few months. Alongside the performance improvements of phpng, it has some other new features developed independently, and includes a few deliberate backwards-compatibility breaks.
tl;dr: the time line goes: 5.2 release, work begins on 6.0, 5.3 release, 6.0 killed off, 5.4 release, 5.5 release, 5.6 release, 7.0 in development.
Edit:
> JIT to the Zend engine
...what? No, PHP 7 does not have that.
> Asynchronous IO and functions
...PHP 7 doesn't have that either?
> Standalone Multi-threading Web Server (HHVM)
...huh?
> phpclasses.org
Oh, so that's why the author is so confused.
[+] [-] McGlockenshire|11 years ago|reply
So for anyone wondering about this, phpclasses was the answer to PEAR, which itself was trying and failing to be CPAN. PEAR ended up being laughable and underwhelming, while phpclasses ended up being a breeding ground for some of the worst PHP code on the planet.
Nobody should be using it and anyone pointing to anything on it as a good example should be laughed at.
Meanwhile, the article author probably needs to read this slide deck from the PHP6 team explaining exactly where the breakdown occurred:
http://www.slideshare.net/andreizm/the-good-the-bad-and-the-...
The postmortem starts on slide 60, but the rest is worth reading.
It had nothing to do with second system syndrome at all.
[+] [-] meritt|11 years ago|reply
Correct PHP 7.0 changes: https://wiki.php.net/rfc#php_70
[+] [-] forgottenacc56|11 years ago|reply
This article would have you believe that if you tried to use Python 3 that within hours you would hit a library roadblock that would be a showstopper. Completely wrong, and you have to ask why the author wants to create this perception.
Python 3 works beautifully and is a pleasure to program.
If you WANT to hate Python 3 then you'll find no lack of ways to hate on it for the next 20 years (HEY! I found some package built by a fellow Python2 holdout! See, it simply is not possible to write the code to upgrade it! PYTHON 3 IS FINISHED! THE SKY IS FALLING!) etc etc ...
If you want to succeed with Python 3 then that's easily done, you just get on with it.
No one using Python 3? Flat out lie. Prove me wrong by scientifically explaining your assertion that no one uses Python 3. Lies, spoken to back the wishes of the Python2 holdouts to sabotage Python 3 - they hate Python 3 and will say any lie to bring it down and spread the FUD. I'm wrong? Prove it in detail with science. Alternatively make vague, handwavey statements about downloads, as though that defines how many people are writing code today with a language.
[+] [-] ghshephard|11 years ago|reply
If anything, based on my read of the article (twice, I had to read it a second time after reading your comment) - I think it's actually written by a Perl advocate who is ruminating on the future of Perl 6, and just using Python as an example of a team that shipped code fast and limited the amount of stuff they broke.
Are you sure we're reading the same article?
[+] [-] RubyPinch|11 years ago|reply
[+] [-] aidos|11 years ago|reply
As someone writing applications using Python 3, I found the switch to be easy and I haven't had any problems with libraries. I've switched from some of the old ones I was using to more modern alternatives that are being actively developed.
It annoys me that there are people on Python 2 that haven't really tried to make the switch and stand on the sideline shouting insults at Python 3. It's a tremendously self destructive thing to do for all involved.
To anyone looking to get started with Python, there's no real reason to start with Python 2 these days.
[+] [-] svisser|11 years ago|reply
If you start a project today then yes, start with Python 3. But if you have a Python 2 codebase you're likely to have (1) one or more dependencies that haven't been ported yet, (2) no solid economical reasons to convince your employer to switch or (3) no sufficient technical reasons in switching at this point (which may change as more Python 3.x versions are released).
[+] [-] bsdpython|11 years ago|reply
[+] [-] unoti|11 years ago|reply
[+] [-] allendoerfer|11 years ago|reply
I like the way the change was rolled out, though:
1. Find a defined amount of cruft that needs to be fixed backwards incompatibly, so you do not take 15 years for it or fail completely. Release a new major version.
2. Make one or two minor releases to the older version to ease the upgrade.
3. Then STOP developing the older version, work with the community and perfect the new version to get everyone on board.
I think it is the perfect middle ground. If you do this constantly you will not have the need to change everything at once and will also not amass cruft.
The problem with the justification of the author for 15 years of Perl 6 development is, that Perl 6 will have issues, too. Are you going to change them all at once again and take another 15 years for Perl 7?
[+] [-] cygx|11 years ago|reply
Learning from experience, one of the design goals of Perl6 was the ability gracefully evolve. Thus you get an object system with meta-object protcol, and you can extend the syntax through user-defined grammars. This probably also factored into the decision to have Rakudo support multiple backends.
[+] [-] masklinn|11 years ago|reply
If one "standard library API" generates integers and an other consumes strings, would you expect the second one to take the output of the first one without conversion?
[+] [-] berntb|11 years ago|reply
[deleted]
[+] [-] tokai|11 years ago|reply
The code ran correctly on first try. Guess I was lucky, should have made the shift earlier!
[+] [-] a3n|11 years ago|reply
[+] [-] task_queue|11 years ago|reply
[+] [-] jsn|11 years ago|reply
[+] [-] sundarurfriend|11 years ago|reply
In any case, this was one of the most unabashedly biased articles I've seen on HN, with badly made attempts at revisionistic history. Perl is still my favourite scripting language, but even I have to admit that Perl 6 has little hope of adoption, and Perl 5 is dying a slow and painful death: due to the momentum, clarity and leadership and P6 took away from it. A few ported-back features gained can't possibly make up for the lack of a cohesive vision that resulted from nobody being sure of the status of the Perl 5 language. Subroutine arguments have long languished in interminable bikeshedding due to this (despite actually having a few enthusiastic implementors - a rare phenomenon in P5 world now!), and we have embarrassments like autoderef and smartmatch[1] which reduce people's trust in the language even more.
What makes the situation truly infuriating though, is the snarky and superior attitudes taken by most P6 folk, just like this article exhibits. Even if you begin with an attitude of collaboration, it soon begins to feel like you're talking to King Joffrey, with that ever-condescending smile of his.
[1] http://www.perlmonks.org/?node_id=961344
[+] [-] RVuRnvbM2e|11 years ago|reply
[+] [-] peteretep|11 years ago|reply
Another interesting subject only slightly touched on here has been the degree to which Perl 6 features have been slowly rolled in to Perl 5; maybe Perl 5.30 will look a great deal like Perl 6.
[+] [-] cageface|11 years ago|reply
[+] [-] unknown|11 years ago|reply
[deleted]
[+] [-] castell|11 years ago|reply
[+] [-] punch_card|11 years ago|reply
[+] [-] thraxil|11 years ago|reply
[+] [-] nercury|11 years ago|reply
Except, um... PHP.
[+] [-] mathgenius|11 years ago|reply
[+] [-] TheLoneWolfling|11 years ago|reply
And Python 3's unicode handling isn't sane. Or rather, it is saner internally, but not sane on the interface. I mean, recreating `cat` is bad enough. Python 3 made unicode handling slightly easier and byte handling gratuitously harder.
But this is probably bikeshedding.
Personally, the bigger problem is not creating a relatively frictionless upgrade path. If you can't run things on the new version without manual editing, you won't move over unless everything you depends on moves over. Catch-22. Python is slowly moving over, largely because a) it's not generally too difficult to port the code (and largely automated to boot), and b) you can relatively easily write code that works on both versions.
[+] [-] recurve28|11 years ago|reply
[+] [-] PebblesHD|11 years ago|reply
[+] [-] a3n|11 years ago|reply
I suspect there are three large subsets of readers, where the process described for "their" language is familiar, and those for the other two languages sound like tales of "inside baseball."
I am familiar with the progress and arguments related to python2/3. I am aware, from a distance, of similar issues with perl5/6 and php5/6/7.
It occurs to me that I haven't heard about similar breaking shifts for other currently active languages, including C and C++. I'm dimly aware that Java recently moved to 8(?) and 9(?) is starting(?). And I wonder about Fortran, which I'm dimly aware still has active users and some standards process.
Can anyone who is familiar with these languages' progress characterize them as breaking and angst-ridden, or smooth and relatively trouble free, and say why? What's different about the process and community from the three languages in the article?
For a possible initial point of contrast, my impression of the three languages' changes are that they are all but new languages that are easy to read for anyone familiar with previous versions.
[+] [-] k__|11 years ago|reply
[+] [-] upofadown|11 years ago|reply
There are zillions of proposals for new languages around at any particular moment in time. Very few ever become popular. If you significantly change a currently popular language then there is a good chance that you will fall off the side into unpopularity.
[+] [-] yellowapple|11 years ago|reply
The 5->6 transition might be more painful because of how long Perl 5 has been around and in active use, but this isn't exactly new to a whole lot of veteran Perl programmers.
[+] [-] collyw|11 years ago|reply
[+] [-] makeitsuckless|11 years ago|reply
Apparently the "gratuitous negativity" guideline doesn't apply to content.
Edit: And let's not forget that 99% of the criticism levelled at those languages has nothing at all to do with Second System Syndrome. That very valid subject is apparently just an excuse to go on a rant.