Why Perl Didn't Win(outspeaking.com)
outspeaking.com
Why Perl Didn't Win
http://outspeaking.com/words-of-technology/why-perl-didnt-win.html
186 comments
The perl developers greatly underestimated the importance of syntactic sugar and familiarity. (Java was helped a lot by looking like C).
PHP was much more friendly towards new programmers than Perl 5, it was so much easier to make simple web pages. So it took over. It didn't matter that Perl 5 was more advanced.
(oh, you uploaded module to same dir and didn't remember to add something to @INC)
PHP was much more friendly towards new programmers than Perl 5, it was so much easier to make simple web pages. So it took over. It didn't matter that Perl 5 was more advanced.
(oh, you uploaded module to same dir and didn't remember to add something to @INC)
> The perl developers greatly underestimated the importance of syntactic sugar and familiarity.
I don't think that's the case. The problem is that the generation of tools that have stuff in common with perl (awk, sed, shell) are completely unfamiliar to programmers which started programming in the last 15 years, compared to those that started 30 years ago.
I don't think that's the case. The problem is that the generation of tools that have stuff in common with perl (awk, sed, shell) are completely unfamiliar to programmers which started programming in the last 15 years, compared to those that started 30 years ago.
Look at how much boilerplate code you need in Perl 5 to create a class versus C++/Java's simple class MyClass { }
You need to assign to a variable named @ISA, you need to return 1; at the bottom of the file. And 'public' members have to be listed in the EXPORT variable.
It is really funny that Perl 5 OO need more boilerplate code than Java!
You need to assign to a variable named @ISA, you need to return 1; at the bottom of the file. And 'public' members have to be listed in the EXPORT variable.
It is really funny that Perl 5 OO need more boilerplate code than Java!
A small correction there, you aren't making them public by putting them in EXPORT. What you're doing is actually using another module to munge the namespace that used your class. In fact by default all functions defined in a package that is used as a class are public by default.
And here's the boiler plate for more modern perl:
And here's the boiler plate for more modern perl:
package MyClass;
use Moose;
1;
Why do you need to return 1 though? That seems pretty ridiculous.
Because that's how [require](http://p3rl.org/require) works:
> to indicate successful execution of any initialization code
Other dynamic languages have problems with "half"-loaded code. This mechanism is a defense against that.
> to indicate successful execution of any initialization code
Other dynamic languages have problems with "half"-loaded code. This mechanism is a defense against that.
It has uses. Sometimes you can also use it to write code that runs like a script if called in script mode (what some people are calling a modulino. If you really hate it there's a number of packages on CPAN to make it disappear.
Also new versions of Perl allow you to define a package scope and skip the '1;' Most Perl programmers don't use this yet since the benefit is very small and the cost is losing some back compatibility. Maybe in a few years it will be more common:
package MyApp::Web { ... }
Like a lot of things in Perl it has a use that might not be immediately evident. Its also possible a more elegant solution could have been found as well. Generally when I write real code I never notice it (the 1; is drowned out by docs and real code.
Also new versions of Perl allow you to define a package scope and skip the '1;' Most Perl programmers don't use this yet since the benefit is very small and the cost is losing some back compatibility. Maybe in a few years it will be more common:
package MyApp::Web { ... }
Like a lot of things in Perl it has a use that might not be immediately evident. Its also possible a more elegant solution could have been found as well. Generally when I write real code I never notice it (the 1; is drowned out by docs and real code.
Technically, you don't need to return 1; you need to return a truthy value. The string "Perl syntax is dumb and hateful" works just as well.
What? I'm not a PERL programmer - I used it a bit before it grew OO features, roughly at the same time I used Turbo Pascal, so really long ago. Yet, in these examples: http://stackoverflow.com/questions/1037312/how-do-i-create-a... I see no boilerplate you speak of. If you look at this http://stackoverflow.com/questions/1037312/how-do-i-create-a... answer you'll see comparison to C++, which isn't exactly in the favour of the latter in terms of conciseness.
And then, even if it was true and you really needed to "add public methods to EXPORT variable" that's no different than modern JavaScript, right? That's how modules work in JS. Having to "return" something at the end of a module is a requirement in Lua, too - again, it's just how the module system works.
Anyway, I don't know PERL, but knowing many other languages I find your claims suspicious. It reads as if you were a recent Java convert who tries to rationalize his decision to leave PERL or something like that.
And then, even if it was true and you really needed to "add public methods to EXPORT variable" that's no different than modern JavaScript, right? That's how modules work in JS. Having to "return" something at the end of a module is a requirement in Lua, too - again, it's just how the module system works.
Anyway, I don't know PERL, but knowing many other languages I find your claims suspicious. It reads as if you were a recent Java convert who tries to rationalize his decision to leave PERL or something like that.
"public static void" is more boilerplate per method than Perl has per module.
You know, that's actually really insightful. I never bothered to learn awk, sed and shell because Perl did it all under one roof. I can only imagine moving from that mess to Perl must have seemed like a revelation to those that came before me, while Perl 5 to Perl 6 is less obvious.
Big rewrites = death
It seems so.
* Perl 6: almost everyone is on Perl 5, or switched to another language
* Python 3: many libraries and devs will stick with Python 2, several devs switched to Go
* PHP 6: unicode rewrite never released, new features backported to 5.3+, several books were published in advance with PHP 6 in the title, next release will be named PHP 7 to avoid confusion
* Lua 5.2+: half of the community stuck with 5.1 as supported with LuaJIT and is many applications (World of Warcraft, Photoshop Lightroom, Facebooks AI platform, etc.)
* VB.Net: many stick with VB 6, many switched to web development
* VBA.Net: everyone still use VBA 6/7 in various Office applications
* ASP.Net: many stuck with ASP coded in VBS/JS, many switched to similar platforms e.g. PHP
The opposite:
* Node.js: it seems many consider the io.js fork based on up-to-date v8 js engine with ES6 support (nodejs 0.11/12 branch fork) and may leave the old nodejs 0.10.x behind
* Perl 6: almost everyone is on Perl 5, or switched to another language
* Python 3: many libraries and devs will stick with Python 2, several devs switched to Go
* PHP 6: unicode rewrite never released, new features backported to 5.3+, several books were published in advance with PHP 6 in the title, next release will be named PHP 7 to avoid confusion
* Lua 5.2+: half of the community stuck with 5.1 as supported with LuaJIT and is many applications (World of Warcraft, Photoshop Lightroom, Facebooks AI platform, etc.)
* VB.Net: many stick with VB 6, many switched to web development
* VBA.Net: everyone still use VBA 6/7 in various Office applications
* ASP.Net: many stuck with ASP coded in VBS/JS, many switched to similar platforms e.g. PHP
The opposite:
* Node.js: it seems many consider the io.js fork based on up-to-date v8 js engine with ES6 support (nodejs 0.11/12 branch fork) and may leave the old nodejs 0.10.x behind
* Angular.js - Don't want to be preaching - but it looks like version 2 will be die in the same way.
How does the generally successful ruby 1.8 to 1.9 transition fit in?
I think maybe is the answer it managed to barely do just as much backwards incompat as it could get away with. (Barely, it drove a lot of people crazy). But it was quite possible to write code that worked in both ruby 1.8 and 1.9, quite intentionally, despite the backwards incompatibilities.
Combined with a commitment from key players (esp Rails) to move to 1.9 and stop supporting 1.8, forcing the issue. And that it happened at a point when ruby/rails were at the peak of their popularity, not already on the downslide (Perl). Which of course effected how much backward incompat you can get away with.
That's the trick, predicting how much backwards incompat you can get away with, of course.
But of course, there's another lesson here too, which the OP astutely calls out in the "greenfield" section -- if you focus too much on stability and supporting existing projects, that's just another way to make the ecosystem go stale.
I think maybe is the answer it managed to barely do just as much backwards incompat as it could get away with. (Barely, it drove a lot of people crazy). But it was quite possible to write code that worked in both ruby 1.8 and 1.9, quite intentionally, despite the backwards incompatibilities.
Combined with a commitment from key players (esp Rails) to move to 1.9 and stop supporting 1.8, forcing the issue. And that it happened at a point when ruby/rails were at the peak of their popularity, not already on the downslide (Perl). Which of course effected how much backward incompat you can get away with.
That's the trick, predicting how much backwards incompat you can get away with, of course.
But of course, there's another lesson here too, which the OP astutely calls out in the "greenfield" section -- if you focus too much on stability and supporting existing projects, that's just another way to make the ecosystem go stale.
What can we learn from this? That we shouldn't attempt major changes that aren't backwards compatible?
Breaking backwards compatibility is a more apt description of that list than major rewrite.
Part of the lesson from Python 3 is that large numbers of people will only spend 3 years deciding whether a 5 year plan to make a major change to a 20 year old language succeeded or not.
Part of the lesson from Python 3 is that large numbers of people will only spend 3 years deciding whether a 5 year plan to make a major change to a 20 year old language succeeded or not.
Agreed. If there's one thing that Bill Gates understood better than everyone else (with the exception of maybe Intel) is that you never break backwards compatibility. You have instantly leveled the playing field for all of your competitors. Why should your users use YOUR new language if there are other languages that already exist and they are just as incompatible as your language?
It's not as simple as that. Eventually continued backwards compatibility hacks will cause non-negligible problems, and some of those same customers may start viewing the competition differently when they finally decide to rewrite or choose a new system to replace their aging one. It's a fine line.
> we shouldn't attempt major changes that aren't backwards compatible?
I think is more about practicality. Incompatible releases are a huge hassle for users; the payout should be equally huge to make it worth the effort of porting.
As the post says, a language should try to be the best choice for new projects: easier and more powerful than other choices, delivering better results with less effort. An incompatible release starts from a position where it requires more effort, so it must deliver much better results in much less time or it will be discarded on practical ground (and all the while having the same feel and strengths as previous releases - you can't make Go, call it Python 4 and expect people will love it). That's very difficult to deliver.
I think is more about practicality. Incompatible releases are a huge hassle for users; the payout should be equally huge to make it worth the effort of porting.
As the post says, a language should try to be the best choice for new projects: easier and more powerful than other choices, delivering better results with less effort. An incompatible release starts from a position where it requires more effort, so it must deliver much better results in much less time or it will be discarded on practical ground (and all the while having the same feel and strengths as previous releases - you can't make Go, call it Python 4 and expect people will love it). That's very difficult to deliver.
And compatibility was big reason why Windows 95 was a success.
I guess we should learn to design languages with extensibility in mind from the outset, so that later incompatible changes are much less likely to be necessary.
io.js has one major advantage over your other examples: it is tracking the same javascript that browsers are running.
When every major browser is moving in the same direction with a language, any server-side counterpart is best served moving in the same direction.
Without browsers, io.js would have likely ended up in the same place as all the examples above.
When every major browser is moving in the same direction with a language, any server-side counterpart is best served moving in the same direction.
Without browsers, io.js would have likely ended up in the same place as all the examples above.
> The opposite:
> * Node.js: it seems many consider the io.js fork based on up-to-date v8 js engine with ES6 support (nodejs 0.11/12 branch fork) and may leave the old nodejs 0.10.x behind
It seems too soon to tell what's going to happen with io.js. It was released just a few days ago.
It seems too soon to tell what's going to happen with io.js. It was released just a few days ago.
You can add IPv6 to that list.
also opposite:
what is considered good c++ has changed pretty dramatically from what I learned in the 90s. Though afaik none of those changes were breaking.
what is considered good c++ has changed pretty dramatically from what I learned in the 90s. Though afaik none of those changes were breaking.
> And Perl 6? Fourteen years and nothing to show for it
... except a nearly feature-complete [1] compiler [2] and an impressive test suite [3]
[1] http://perl6.org/compilers/features [2] http://rakudo.org/ [3] https://github.com/perl6/roast/
> and it'll have to be backwards compatible to all the things violently wrong with Perl 5
Not at all. The whole point about Perl 6 is that it breaks backwards compatibility to fix the things that are wrong with Perl 5.
... except a nearly feature-complete [1] compiler [2] and an impressive test suite [3]
[1] http://perl6.org/compilers/features [2] http://rakudo.org/ [3] https://github.com/perl6/roast/
> and it'll have to be backwards compatible to all the things violently wrong with Perl 5
Not at all. The whole point about Perl 6 is that it breaks backwards compatibility to fix the things that are wrong with Perl 5.
> The whole point about Perl 6 is that it breaks backwards compatibility
I think this is is a contributor to why Perl 6 will never amount to anything. That boat has sailed. Python 3 broke backwards compatibility and to my knowledge everybody is still using Python 2. Python has a lot of energy right now, so that might save it, or it might go the way of Perl when the next cool language comes out and everybody jumps ship.
I think this is is a contributor to why Perl 6 will never amount to anything. That boat has sailed. Python 3 broke backwards compatibility and to my knowledge everybody is still using Python 2. Python has a lot of energy right now, so that might save it, or it might go the way of Perl when the next cool language comes out and everybody jumps ship.
> Python 3 broke backwards compatibility
While this is true, it's possible to write a script that will run on both Python2 and Python3, so long as you have that goal in mind. The breaking of backwards compatibility is the breaking of several APIs and assumptions.
> to my knowledge everybody is still using Python 2
This is mostly because the release of Python 3 didn't see everyone stop everything and immediately start coding in Python 3. Conversion has to bubble up from the major libraries (e.g. Django, Flask, SciPy, etc) first, before people are able to convert.
Also, switching the default Python on Linux distros takes time because you have to go through all of the packages in the package manager looking for Python scripts and make sure that anything pointed at /usr/bin/python will work with Python 3[1].
Another point is that a number of libraries delayed conversion, and didn't consider Python3 to be "stable" until around Python 3.3. Some of other libraries (cough Flask cough) delayed support for a long time because the maintainer just didn't like Python 3.
[1] I know that these aren't always working well though. A while back I found out that Comix (installed via Ubuntu) had "/usr/bin/env python" in the shebang line instead. Launching it from a Virtualenv that doesn't have PyGTK doesn't work so well... :P
While this is true, it's possible to write a script that will run on both Python2 and Python3, so long as you have that goal in mind. The breaking of backwards compatibility is the breaking of several APIs and assumptions.
> to my knowledge everybody is still using Python 2
This is mostly because the release of Python 3 didn't see everyone stop everything and immediately start coding in Python 3. Conversion has to bubble up from the major libraries (e.g. Django, Flask, SciPy, etc) first, before people are able to convert.
Also, switching the default Python on Linux distros takes time because you have to go through all of the packages in the package manager looking for Python scripts and make sure that anything pointed at /usr/bin/python will work with Python 3[1].
Another point is that a number of libraries delayed conversion, and didn't consider Python3 to be "stable" until around Python 3.3. Some of other libraries (cough Flask cough) delayed support for a long time because the maintainer just didn't like Python 3.
[1] I know that these aren't always working well though. A while back I found out that Comix (installed via Ubuntu) had "/usr/bin/env python" in the shebang line instead. Launching it from a Virtualenv that doesn't have PyGTK doesn't work so well... :P
One way to look at things is that Perl 6 breaks backwards compatibility with Perl 5. Another is that Perl 6 has well designed language interop and evolution features that make it so easy to nicely use code and libs from other languages that backwards compatibility becomes irrelevant.
The big problem with Perl 6 has been that the implementation has trailed the ambitions of the design. But that's changing due to pieces like Inline::Perl5 falling in to place. (See my comments nearby for more details.)
The big problem with Perl 6 has been that the implementation has trailed the ambitions of the design. But that's changing due to pieces like Inline::Perl5 falling in to place. (See my comments nearby for more details.)
Well, not quite irrelevant. Just because language interop is easy doesn't make the fact that there doesn't exist the interop for a library you need. That said, it's also a good chance to get good sane default implementations in first. On of the problems with CPAN is finding the best of the multiple modules available that fit the need.
As I said elsewhere in this thread, Inline::Perl5 hasn't been tested against all 130,000 modules on CPAN to my knowledge, but, based on what I know of the tech and its 100% success rate so far, I'm going to assume until I hear otherwise that it already works, or will do so this year, for the vast majority.
In the unlikely event there's a module that doesn't work, then yes, you have to learn and wield a new language that isn't backwards compatible. But it is Perlish, and it is designed to coexist beautifully with Perl 5.
In the unlikely event there's a module that doesn't work, then yes, you have to learn and wield a new language that isn't backwards compatible. But it is Perlish, and it is designed to coexist beautifully with Perl 5.
Ah, I had heard that Inline::Perl5 worked with (some?) XS modules, but wasn't sure I was remembering correctly, and assumed it didn't. Unfortunately, my ability to keep abreast of new Perl 6 developments has taken a big hit the last six months or so, due to increased workload. :(
Perl 6 is a new language. Its not a Python like scenario where people are looking to migrate their existing code bases from 2 to 3.
Perl 6 is for new projects. Perl 5 ecosystem continues evolve untouched. Unlike the Python 2 scenario, where 2.x won't be supported and 3.x series and its library ecosystem isn't ready anymore.
Perl 6 is for new projects. Perl 5 ecosystem continues evolve untouched. Unlike the Python 2 scenario, where 2.x won't be supported and 3.x series and its library ecosystem isn't ready anymore.
Everybody IN ENTERPRISE is still using Python 2. Realistically, most of the Python ecosystem is compatible 2+3, we are seeing new libraries and programs compatible 3.3+-only, and there's no broad reason to use Python 2 anymore, with minor exceptions.
> and there's no broad reason to use Python 2 anymore, with minor exceptions.
If you count big chunks of legacy python 2 code a "minor exception", I agree.
Anyway, the big difference between python 2 -> 3 transition and the Perl 5 and Perl 6 coexistence is that nobody within the Perl community tried to end-of-live Perl 5.
Yes, that means less incentives for migrating to Perl 6, but it also reduces the risk for Perl 5 users.
If you count big chunks of legacy python 2 code a "minor exception", I agree.
Anyway, the big difference between python 2 -> 3 transition and the Perl 5 and Perl 6 coexistence is that nobody within the Perl community tried to end-of-live Perl 5.
Yes, that means less incentives for migrating to Perl 6, but it also reduces the risk for Perl 5 users.
I don't think anyone advocated for converting large legacy codebases 2->3. But 3 should be the "default" for new projects, and only use 2 if they have a reason.
Indeed. While personally I think Tcl is a better language than either, professionally I jumped straight from Perl 4 to Python, bypassing Perl 5 altogether. The combination of needing rigid standards to make a codebase maintainable in big projects, with the dynamic nature of the language meaning that tool support for it was scarce, was a double whammy.
Now that I think about it, not even that big projects, teams of 10 or so devs, getting bogged down in language issues that Python simply didn't have (and no one even wished for tool support for, the was no need!)
Now that I think about it, not even that big projects, teams of 10 or so devs, getting bogged down in language issues that Python simply didn't have (and no one even wished for tool support for, the was no need!)
Absolutely right - Perl 4 had a clear niche (text processing, UNIX system scripting etc) and did this very well. Perl 5 added so much cruft and ugly syntax on top of this in an attempt to try to become more 'general purpose' that it lost its focus. At this point it became easier to switch to Python for 'real' programming.
There are still a lot of problems in the Perl 4 space and to be honest I wish that distributions shipped with a supported version of 4.036.
There are still a lot of problems in the Perl 4 space and to be honest I wish that distributions shipped with a supported version of 4.036.
It would be rather pointless to ship Perl4, as Perl5 is almost completely backwards compatible with Perl4. Most of the parts where backwards compatibility was removed weren't actually used to a large extent. Also Perl5 didn't add that much syntax, and a big reason it was ugly is that Perl4 didn't leave a lot of space for the extra features. Which is also why Perl6 breaks backwards compatibility.
There are also some features that were eventually removed from Perl5, but not really. For example setting $[ was removed (it was a pretty stupid idea), but if you try to use it Perl loads the module arybase which re-implements that feature. (removing it simplified the internals)
There are also some features that were eventually removed from Perl5, but not really. For example setting $[ was removed (it was a pretty stupid idea), but if you try to use it Perl loads the module arybase which re-implements that feature. (removing it simplified the internals)
If you seriously think that Perl5 is less suitable for text processing than Perl4 was, I suspect you haven't actually used the language in a while... it's still perfectly good for that. Perhaps even better, since 5.8 added extensive support for Unicode (without requiring explicit conversions and breaking everything like Python 3 did).
From a quick skimming through the docs[0], Perl 5.8's Unicode support sounds a lot like Python 2's except that the default encoding is latin1 instead of ASCII - i.e. unlike the Python 3 way of explicitly decoding binary data into Unicode text at the point where it's read (where presumably the encoding of the data is known), it will defer the decoding until the data is used (at some completely unrelated point in the program) and decode it with some assumed globally agreed upon encoding. Since there is no globally agreed encoding (Windows even has different legacy encodings between Win32 and the command prompt!) this will appear to work as long as the data is ASCII but later, when you least expect it (and someone inputs a non-ASCII string), give UnicodeDecodeError in Python 2 or garbage data in Perl 5.8.
Ned Batchelder gave an excellent talk[1] that explains how the Python 3 approach to Unicode works. I think it makes a lot more sense once you understand it; the Python 2 way was clearly broken, and it looks like Perl 5 has the same problem but hides it better.
[0] http://search.cpan.org/~jhi/perl-5.8.0/pod/perluniintro.pod
[1] http://m.youtube.com/watch?v=sgHbC6udIqc
Ned Batchelder gave an excellent talk[1] that explains how the Python 3 approach to Unicode works. I think it makes a lot more sense once you understand it; the Python 2 way was clearly broken, and it looks like Perl 5 has the same problem but hides it better.
[0] http://search.cpan.org/~jhi/perl-5.8.0/pod/perluniintro.pod
[1] http://m.youtube.com/watch?v=sgHbC6udIqc
Why are you pointing to the unicode entry doc in an ancient version of Perl?
Also according to perlunifaq the minumum version you should be using is 5.8.1 which the documents for 5.8.0 would of course not mention.
Really if you want good unicode handling you should probably use 5.16.0 or later. If you want the latest version of Unicode there are ways of changing which version of Unicode Perl is compiled with, but it is easier to just use the latest version of Perl, which is 5.20.
http://perldoc.perl.org/perluniintro.html http://perldoc.perl.org/perlunitut.html http://perldoc.perl.org/perlunifaq.html http://perldoc.perl.org/perlunicode.html
p.s. I noticed in the Python talk you linked that no one knew that the pile of poo symbol is in there because the japanese characters for luck and poo are very similar. ( I am unable to find a link to where I first read this ) The Japanese are also responsible for why we call them emoji (e means image, and moji means character. ) http://www.fastcompany.com/3037803/the-oral-history-of-the-p...
Also according to perlunifaq the minumum version you should be using is 5.8.1 which the documents for 5.8.0 would of course not mention.
Really if you want good unicode handling you should probably use 5.16.0 or later. If you want the latest version of Unicode there are ways of changing which version of Unicode Perl is compiled with, but it is easier to just use the latest version of Perl, which is 5.20.
http://perldoc.perl.org/perluniintro.html http://perldoc.perl.org/perlunitut.html http://perldoc.perl.org/perlunifaq.html http://perldoc.perl.org/perlunicode.html
p.s. I noticed in the Python talk you linked that no one knew that the pile of poo symbol is in there because the japanese characters for luck and poo are very similar. ( I am unable to find a link to where I first read this ) The Japanese are also responsible for why we call them emoji (e means image, and moji means character. ) http://www.fastcompany.com/3037803/the-oral-history-of-the-p...
The documentation you're looking at is quite old; I'd recommend looking at the current version for a better view. (The implementation is largely the same; the documentation has just improved quite a bit since then.)
http://perldoc.perl.org/perluniintro.html
Anyways, Perl5's Unicode support is quite different from Python's.
Specifically, it doesn't have distinct "Unicode string" and "byte string" types; instead, it has a single unified string type. These strings may be internally stored as Latin1 or UTF-8, depending on how they were created, but they behave identically for almost[1] all purposes, and there are easy ways to force Perl to convert between the formats. It's still possible to create a nonsensical string if you do something silly like append Unicode characters to a string containing raw UTF-8 data, but that's not something the language can entirely protect you from.
[1]: The only exceptions I'm aware of are functions which explicitly operate on the utf8 status, like utf8::is_utf8(), and bitwise operations like &|^ and vec().
http://perldoc.perl.org/perluniintro.html
Anyways, Perl5's Unicode support is quite different from Python's.
Specifically, it doesn't have distinct "Unicode string" and "byte string" types; instead, it has a single unified string type. These strings may be internally stored as Latin1 or UTF-8, depending on how they were created, but they behave identically for almost[1] all purposes, and there are easy ways to force Perl to convert between the formats. It's still possible to create a nonsensical string if you do something silly like append Unicode characters to a string containing raw UTF-8 data, but that's not something the language can entirely protect you from.
[1]: The only exceptions I'm aware of are functions which explicitly operate on the utf8 status, like utf8::is_utf8(), and bitwise operations like &|^ and vec().
Is there an actively maintained fork of Perl 4 (or earlier) somewhere? Sounds like there should be.
There's really not much point. Perl 5 is 99% backwards compatible with Perl 4, so if you think Perl 4 was great, just use the Perl 5 compiler (but none of the new features).
Perl5 even still supports some of the really ugly features of Perl4 that people generally wish would go away (like &function_calls, and nested'packages'like'this.)
The irony here, then, is that Perl 5 took the object system that Python had in 1995 as an example to emulate.
Even Duke Nukem Forever shipped before Perl 6.
MooseX::Declare makes Perl OO actually pretty good. I like the traits system. Not that I'd pick it as a first starting point for new work, it's nice for using with existing legacy work.
Speaking as someone who lived through this period during the formative years of my programming career, the author has completely missed the most influential language of the time and, in my mind at least, the number reason why Perl lost.
Yes, I'm talking about Java. It's easy to hate now, but Java back then replaced all the server-side Perl programming that I did in the space of about 3 years, from 1994 where CGI programming was king to 1995 and the applets craze to 1999 when I was still regularly having conversations with people about the benefits of Java vs Perl to 2001 when you were actively hurting your career by not learning Java (not least because it seemed like the only people hiring were doing enterprise Java with horrible things like EJB and CMP/BMP).
Why did Java beat Perl? Well, there's a lot to that -- but at least part of it has to do with that fact that Java was simpler and didn't have nearly as many tricks up its sleeves (also known as the write-only problem). This is similar to the argument people today make when picking Go over other options like Scala. I also don't think it hurt that Java came out of Sun, which on the one hand was extremely influential because they sold the hardware everyone with money used, but on the other wasn't influential at all because they were "big iron" to the web's "why would I buy a Sparcstation when I can just put a PC under my desk?"
Fundamentally, though, Java was very successful at becoming the language you wrote code in if you wanted to be taken seriously as a software engineer building web applications and you didn't already have 5+ years of C++ experience. Perl programmers didn't get the same respect, and so Perl died.
Yes, I'm talking about Java. It's easy to hate now, but Java back then replaced all the server-side Perl programming that I did in the space of about 3 years, from 1994 where CGI programming was king to 1995 and the applets craze to 1999 when I was still regularly having conversations with people about the benefits of Java vs Perl to 2001 when you were actively hurting your career by not learning Java (not least because it seemed like the only people hiring were doing enterprise Java with horrible things like EJB and CMP/BMP).
Why did Java beat Perl? Well, there's a lot to that -- but at least part of it has to do with that fact that Java was simpler and didn't have nearly as many tricks up its sleeves (also known as the write-only problem). This is similar to the argument people today make when picking Go over other options like Scala. I also don't think it hurt that Java came out of Sun, which on the one hand was extremely influential because they sold the hardware everyone with money used, but on the other wasn't influential at all because they were "big iron" to the web's "why would I buy a Sparcstation when I can just put a PC under my desk?"
Fundamentally, though, Java was very successful at becoming the language you wrote code in if you wanted to be taken seriously as a software engineer building web applications and you didn't already have 5+ years of C++ experience. Perl programmers didn't get the same respect, and so Perl died.
There were two sides - PHP was eating a ton of share from Perl for people and businesses who just wanted to get some simple web thing going. Sun pulled out the "Java is Enterprise" card early and successfully marketed it as being a professional scalable web programming solution for enterprise class applications with a few targeted buzzwords for whatever market segment they were going for. Perl seemed like it was always looked at as an amateur tool (much as PHP/ASP generally were), while Java was taken seriously in "enterprise" spaces (largely due to Sun's success at marketing Java to businesses).
There's a wrinkle, too. Perl isn't just a web thing. It was (and is) still used in "enterprise" spaces for scripting on servers. It's still out there being used to create scripts rather than applications. In that space Ruby/Python are competing, but there's still plenty of sysadmins who use Perl since it works.
There's a wrinkle, too. Perl isn't just a web thing. It was (and is) still used in "enterprise" spaces for scripting on servers. It's still out there being used to create scripts rather than applications. In that space Ruby/Python are competing, but there's still plenty of sysadmins who use Perl since it works.
> In that space Ruby/Python are competing, but there's still plenty of sysadmins who use Perl since it works.
I don't know how it looks now, but if you login into the likes of HP-UX, Aix, Solaris and so on, usually only Perl is available.
This is what made me learn Perl, back when I was mostly into Python (.com days).
I don't know how it looks now, but if you login into the likes of HP-UX, Aix, Solaris and so on, usually only Perl is available.
This is what made me learn Perl, back when I was mostly into Python (.com days).
I've dabbled in the source-code of many projects. And personally I've never seen projects more incomprehensible than some of the ones I've seen built with Java. Of course, I've also seen well written Java code, however Java projects tend to be massively over-engineered and tasteless. Its popularity doesn't help either, the signal to noise ratio in the pool of Java developers being awful.
On people picking up Go over other options, well that's because people never learn and we are bound to propel shitty languages ad-nauseam.
On people picking up Go over other options, well that's because people never learn and we are bound to propel shitty languages ad-nauseam.
What do you mean about Go? (And no...I'm not trying to pick a fight--just curious)
There is a common theme to early Java discussions and discussions about golang right now. I'll sum it up as "All that power/functionality/expressivness of language x is really a distraction from getting stuff done. Further it complicates the software development model of large disparate groups."
I'm not sure that theme is wrong even, but to many of us who lived through early java, golang's least common denominator approach to developer sourcing is eerily familiar.
I'm not sure that theme is wrong even, but to many of us who lived through early java, golang's least common denominator approach to developer sourcing is eerily familiar.
I agree and have made that point before. Java tried to be a language for "enterprise programming", which tried to keep the language so simple that having lots of people wouldn't muck up your code. IMHO, it failed epically at this, and today we would basically laugh at the idea that Java is good at that, but it was in fact a design criterion back in the day. One could make the case that it sort of succeeded at the isolation bit, but at the cost of making everything so verbose that it's absurd and a constant stream of technologies to deal with this has been coming out for Java ever since.
Despite the taint Java left on it, it's actually a good idea! It's a common use case. After years of programming in Perl in a fairly large programmer environment I can see the virtue of the idea of using a simpler language helping keep a lot of programmers in sync in their code base, instead of living in a world where I can look at the source and virtually instantly tell both when and who it came from due to massive differences in dialect. But Java seems to have failed so badly that it soured everyone on the entire idea, and nobody has tried since.
I think Go actually has a better chance at this, not for any large reason but for a series of smaller ones. Defaulting to object composition, once you understand it, is a powerful-yet-simpler approach to putting objects together than inheritance, and makes it much easier to both use the objects of others and to create objects to use for others, because you don't need to worry about what will be F'ed up in the "child classes", as there is no such thing. Implicitly satisfied interfaces don't sound like they'd be a big change over Java, in practice it's night-and-day to be able to declare interfaces that are automatically satisfied by objects you don't control. Contrast how many ways there are to write the same Go function as there is to write it in, say, Scala. And writing some decent multithreading primitives into the core is probably a good idea for this use case, too.
It won't happen tomorrow or next year, but, arguably, rather than Rust or even Python, the language that Go is the biggest threat to in the long term is Java. And it's a threat for precisely the reasons that people on HN tend to complain about. Indeed, I personally have the same objections that most HN'ers do for personal usage, but right now bar none Go is the language I'd most like to work in, precisely because it was written for the Google use case which also happens to be the one I have.
Despite the taint Java left on it, it's actually a good idea! It's a common use case. After years of programming in Perl in a fairly large programmer environment I can see the virtue of the idea of using a simpler language helping keep a lot of programmers in sync in their code base, instead of living in a world where I can look at the source and virtually instantly tell both when and who it came from due to massive differences in dialect. But Java seems to have failed so badly that it soured everyone on the entire idea, and nobody has tried since.
I think Go actually has a better chance at this, not for any large reason but for a series of smaller ones. Defaulting to object composition, once you understand it, is a powerful-yet-simpler approach to putting objects together than inheritance, and makes it much easier to both use the objects of others and to create objects to use for others, because you don't need to worry about what will be F'ed up in the "child classes", as there is no such thing. Implicitly satisfied interfaces don't sound like they'd be a big change over Java, in practice it's night-and-day to be able to declare interfaces that are automatically satisfied by objects you don't control. Contrast how many ways there are to write the same Go function as there is to write it in, say, Scala. And writing some decent multithreading primitives into the core is probably a good idea for this use case, too.
It won't happen tomorrow or next year, but, arguably, rather than Rust or even Python, the language that Go is the biggest threat to in the long term is Java. And it's a threat for precisely the reasons that people on HN tend to complain about. Indeed, I personally have the same objections that most HN'ers do for personal usage, but right now bar none Go is the language I'd most like to work in, precisely because it was written for the Google use case which also happens to be the one I have.
The same arguments can be said about Perl.
An expressive language is good to work in, because reading 1 line of code instead of 100 is always better for readability and also verbosity is a cause of accidental bugs - one line of code that does the same work as 100 lines is much less probable to contain accidental bugs. Plus, the closer you have code that precisely models the business logic, the more readable it is (assuming that we aren't talking about a retarded, badly designed, non-composable DSL).
However Perl is a heavy language that also lacks common means for abstractions that people do use in Perl, like OOP. Therefore, not only are we speaking about a heavy language, but one in which you get a dozen libraries for doing things like OOP, all of them slightly incompatible with each other. Of course, Moose came along, but Moose was late (i.e. the damage was already done) and I'd argue that Moose is also overly complex. This goes over the principles outlined by Guy Steele in his "Growing a Language" presentation - either a language is very simple, with a core set of orthogonal and powerful features that allows you to build whatever you want on top (i.e. Scheme), or it's a more complex language that provides everything you need. Perl is neither of those. So one can argue that Perl is badly designed.
So you could say that Perl tainted the idea of using expressive languages, just like Java tainted the idea of using simple languages. And actually "simple" in this context is incorrect, because there's nothing simple about Java's flavor of OOP, it's just that people are familiar with Java's blend of OOP, but familiarity is not necessarily about simplicity. But I digress.
And it's a pity. For example right now my favorite is Scala. In my opinion Scala's expressivity is very different from Perl's expressivity, in that Scala's constructs are necessary and almost orthogonal and usually properly used and the abstractions are well defined. I also programmed in Perl and after 2 years of doing it I would still have problems reading code from other people, whereas this never happens to me in Scala and even if that would be the case, I have an IDE to help me out. And in my experience of training rookies to work with Scala, it's not the syntax that's problematic, but rather the design patterns and abstractions used and that have been imported from Haskell and hence are foreign to many developers. Yet in spite of this, I've seen many superficial opinions floating on the web that a language like Scala is too complicated and then when you ask those people why, it turns out that in most cases we are talking about misconceptions and unjustified fear coming from a superficial understanding of a language.
Going back to Go, the problem with Go it that it lacks the means for abstraction that I'm looking for. Go lacks generics for example, which means that building abstractions that involve higher-order functions is not feasible. And I'm sure that Go will get generics at some point, since it is inevitable, however Go is not the type of language to ever implement higher-kinded types and type-classes. I personally need type-classes, being a very different means for ad-hoc polymorphism, when compared with OOP, with different use-cases.
For example I want to work with monads or applicative functors, which in spite of their scary reputation, are just design patterns that aren't very hard to understand, their reputation being a direct consequence of them being explained by Haskell developers with a mathematical mindset. And I want to build generic functions that work over monads or applicative functors, because once you discover their power, it's very hard to go back and life is too short to reinvent the wheel every single time. And Go is not the kind of language that will ever appeal to my needs, whereas languages like Scala, Clojure and arguably Rust are such languages.
But here's the real problem that I'm seeing - scaling a software development team is done in two ways ... you either hire more people, or you hire really good people that can produce better abstractions. This is horizontal scalability versus vertical scalability. And the problem is, in a software development company, these 2 approaches are incompatible. The companies that want to scale horizontally are exactly the companies that prefer familiar languages, whereas the companies for which that isn't feasible (i.e. startups) are the companies that prefer powerful languages.
And of course, you would think that it's better to scale horizontally, depending on the problems solved, but therein lies another problem - the difference between really good people that can juggle with abstractions and juniors is not necessarily one of productivity, but rather in the range of problems they can solve. Given enough difficulty, you can hire how many juniors you want and they might still not be able to solve certain problems, whereas those same problems might be feasible for 2-3 people that are really good. Amdahl's law is also very relevant to software development. The more people you have, the more you introduce concurrency and points of synchronization, which in turn kills the parallelization possible and thus productivity.
What I'm talking about is the software crisis problem, which is still very relevant. And my personal bet is on vertical scalability, which implies working with better tools and abstractions. Because that's how we scaled math and that's how we went beyond the pyramids.
An expressive language is good to work in, because reading 1 line of code instead of 100 is always better for readability and also verbosity is a cause of accidental bugs - one line of code that does the same work as 100 lines is much less probable to contain accidental bugs. Plus, the closer you have code that precisely models the business logic, the more readable it is (assuming that we aren't talking about a retarded, badly designed, non-composable DSL).
However Perl is a heavy language that also lacks common means for abstractions that people do use in Perl, like OOP. Therefore, not only are we speaking about a heavy language, but one in which you get a dozen libraries for doing things like OOP, all of them slightly incompatible with each other. Of course, Moose came along, but Moose was late (i.e. the damage was already done) and I'd argue that Moose is also overly complex. This goes over the principles outlined by Guy Steele in his "Growing a Language" presentation - either a language is very simple, with a core set of orthogonal and powerful features that allows you to build whatever you want on top (i.e. Scheme), or it's a more complex language that provides everything you need. Perl is neither of those. So one can argue that Perl is badly designed.
So you could say that Perl tainted the idea of using expressive languages, just like Java tainted the idea of using simple languages. And actually "simple" in this context is incorrect, because there's nothing simple about Java's flavor of OOP, it's just that people are familiar with Java's blend of OOP, but familiarity is not necessarily about simplicity. But I digress.
And it's a pity. For example right now my favorite is Scala. In my opinion Scala's expressivity is very different from Perl's expressivity, in that Scala's constructs are necessary and almost orthogonal and usually properly used and the abstractions are well defined. I also programmed in Perl and after 2 years of doing it I would still have problems reading code from other people, whereas this never happens to me in Scala and even if that would be the case, I have an IDE to help me out. And in my experience of training rookies to work with Scala, it's not the syntax that's problematic, but rather the design patterns and abstractions used and that have been imported from Haskell and hence are foreign to many developers. Yet in spite of this, I've seen many superficial opinions floating on the web that a language like Scala is too complicated and then when you ask those people why, it turns out that in most cases we are talking about misconceptions and unjustified fear coming from a superficial understanding of a language.
Going back to Go, the problem with Go it that it lacks the means for abstraction that I'm looking for. Go lacks generics for example, which means that building abstractions that involve higher-order functions is not feasible. And I'm sure that Go will get generics at some point, since it is inevitable, however Go is not the type of language to ever implement higher-kinded types and type-classes. I personally need type-classes, being a very different means for ad-hoc polymorphism, when compared with OOP, with different use-cases.
For example I want to work with monads or applicative functors, which in spite of their scary reputation, are just design patterns that aren't very hard to understand, their reputation being a direct consequence of them being explained by Haskell developers with a mathematical mindset. And I want to build generic functions that work over monads or applicative functors, because once you discover their power, it's very hard to go back and life is too short to reinvent the wheel every single time. And Go is not the kind of language that will ever appeal to my needs, whereas languages like Scala, Clojure and arguably Rust are such languages.
But here's the real problem that I'm seeing - scaling a software development team is done in two ways ... you either hire more people, or you hire really good people that can produce better abstractions. This is horizontal scalability versus vertical scalability. And the problem is, in a software development company, these 2 approaches are incompatible. The companies that want to scale horizontally are exactly the companies that prefer familiar languages, whereas the companies for which that isn't feasible (i.e. startups) are the companies that prefer powerful languages.
And of course, you would think that it's better to scale horizontally, depending on the problems solved, but therein lies another problem - the difference between really good people that can juggle with abstractions and juniors is not necessarily one of productivity, but rather in the range of problems they can solve. Given enough difficulty, you can hire how many juniors you want and they might still not be able to solve certain problems, whereas those same problems might be feasible for 2-3 people that are really good. Amdahl's law is also very relevant to software development. The more people you have, the more you introduce concurrency and points of synchronization, which in turn kills the parallelization possible and thus productivity.
What I'm talking about is the software crisis problem, which is still very relevant. And my personal bet is on vertical scalability, which implies working with better tools and abstractions. Because that's how we scaled math and that's how we went beyond the pyramids.
I think that's well written and makes many good points that I agree with, but something that jumps out at me is this:
> I also programmed in Perl and after 2 years of doing it I would still have problems reading code from other people
> I've seen many superficial opinions floating on the web that a language like Scala is too complicated and then when you ask those people why, it turns out that in most cases we are talking about misconceptions and unjustified fear coming from a superficial understanding of a language
That's generally the same thing I see when talking to people about Perl. I don't know the level of knowledge you gained with Perl, so I don't know if it really applies the same, but from the outside, it does look the same.
I generally view this a a problem of language power AND complexity. Complex languages take longer to learn and be comfortable with, but if the complexity is because they provide more power, what you are really doing is front-loading work to make future work easier, which pays dividends in the end. I think this also fits your description of leverage quite well.
> I also programmed in Perl and after 2 years of doing it I would still have problems reading code from other people
> I've seen many superficial opinions floating on the web that a language like Scala is too complicated and then when you ask those people why, it turns out that in most cases we are talking about misconceptions and unjustified fear coming from a superficial understanding of a language
That's generally the same thing I see when talking to people about Perl. I don't know the level of knowledge you gained with Perl, so I don't know if it really applies the same, but from the outside, it does look the same.
I generally view this a a problem of language power AND complexity. Complex languages take longer to learn and be comfortable with, but if the complexity is because they provide more power, what you are really doing is front-loading work to make future work easier, which pays dividends in the end. I think this also fits your description of leverage quite well.
I just wanted to say I agree to everything you just said. I don't feel like I've heard this viewpoint expressed better before.
Having spent a fair bit of time thinking the same way about growing developer teams and bouncing from 1 side of the equation to the other, I've started thinking about it like leverage.
With a lot of leverage, like a requirement for sophisticated developers and powerful languages, you can get huge payoffs. The kind that are unlikely without it. But also like leverage, small, sometimes unavoidable problems can utterly destroy your efforts.
I'm not convinced that I've ever seen a big group of average developers be highly successful, and I have seen that with a small group of great developers. But I've also seen a medium sized group of above average developers completely submarined by the complexities of their language.
With a lot of leverage, like a requirement for sophisticated developers and powerful languages, you can get huge payoffs. The kind that are unlikely without it. But also like leverage, small, sometimes unavoidable problems can utterly destroy your efforts.
I'm not convinced that I've ever seen a big group of average developers be highly successful, and I have seen that with a small group of great developers. But I've also seen a medium sized group of above average developers completely submarined by the complexities of their language.
> I agree and have made that point before. Java tried to be a language for "enterprise programming", which tried to keep the language so simple that having lots of people wouldn't muck up your code.
Wind back 35 years or so and you could have said the exact same thing about COBOL.
Wind back 35 years or so and you could have said the exact same thing about COBOL.
COBOL also failed so epically that it soured its entire core idea for decades. (That's just an additional observation, I'm not saying you claimed otherwise.)
I won't guarantee that Go will experience wild success and become an A-list language, but I will guarantee that barring some major change in approach or leadership, it will not fail so spectacularly as to destroy the entire idea of trying to create a language for programming at scale. While HN bitches, Go's penetration into exactly the space I'm describing marches on and has passed critical mass.
I won't guarantee that Go will experience wild success and become an A-list language, but I will guarantee that barring some major change in approach or leadership, it will not fail so spectacularly as to destroy the entire idea of trying to create a language for programming at scale. While HN bitches, Go's penetration into exactly the space I'm describing marches on and has passed critical mass.
I'm not sure by which measure you are determining that COBOL failed epically. I think the likelihood of Java, to say nothing of golang, having the presence COBOL has 50 years after its creation is essentially zero.
COBOL failed epically at its goal of making programming easy for everybody by creating an "English"-esque syntax that everybody could understand. It failed so epically that it has apparently destroyed the idea so thoroughly that you don't remember/realize that it was a first-class goal of the language.
If you go back and read what I said, notice that nobody could sensibly call Java a generalized "failure" either. It specifically failed to create a language that would be something that could be used by large groups of people easily, and to the extent it succeeded it did so with incredibly grit, perseverance, and tons of third-party tools and terribly abortive efforts over the years, and it also did it so badly that people entirely stopped talking about even trying it. This despite the fact that "how do we write programs in companies with hundreds of programmers working on tons of discrete projects" is by any measure a very large use case for programming languages, and that only Go is directly addressing this use case directly is in some sense a travesty. (Others address it indirectly, by claiming that their features that are really intended for code safety or power may also as a side effect have the ability to make big programming teams function well, if they even claim that.)
If you go back and read what I said, notice that nobody could sensibly call Java a generalized "failure" either. It specifically failed to create a language that would be something that could be used by large groups of people easily, and to the extent it succeeded it did so with incredibly grit, perseverance, and tons of third-party tools and terribly abortive efforts over the years, and it also did it so badly that people entirely stopped talking about even trying it. This despite the fact that "how do we write programs in companies with hundreds of programmers working on tons of discrete projects" is by any measure a very large use case for programming languages, and that only Go is directly addressing this use case directly is in some sense a travesty. (Others address it indirectly, by claiming that their features that are really intended for code safety or power may also as a side effect have the ability to make big programming teams function well, if they even claim that.)
Wasn't COBOL more about "your accountants can understand this"?
Ditto on the Sys Admin side with Python - Perl had modules for everything, but the inbuilt punctuation variables mixed with regexs for everything and the flexibility Perl offered led to a perception that nobody could maintain anybody else's stuff.
Sys admins were still about getting shit done quickly at scale, and Python slowly began to replace Perl. Python 2 had string methods built in, Red Hat switched everything to Python, tool.s like LXML started coming out right when we all had to munge XML all day and suddenly that was it.
Sys admins were still about getting shit done quickly at scale, and Python slowly began to replace Perl. Python 2 had string methods built in, Red Hat switched everything to Python, tool.s like LXML started coming out right when we all had to munge XML all day and suddenly that was it.
This article is pretty much spot on. I lived through this era and experienced the downfall of perl web applications first hand.
My employer produced an amazingly popular perl-based web application, using flat files for data storage because so few shared hosts had DBI and DBD::mysql installed. It's some gloriously horrible code. They did a ground-up rewrite and then hired me to maintain it, right as PHP was becoming popular.
They refused to do a PHP version until it was too late. Someone else translated our code into PHP, then rewrote it a few times before releasing it. Over just a year or two, our marketshare plummeted, and now the UBB is a distant memory. We couldn't deliver a competing product.
Even if perl hadn't lost the deployability battle, the perl 6 fiasco was what let python and company eat away at the mindshare that wasn't concerned with just web applications.
My employer produced an amazingly popular perl-based web application, using flat files for data storage because so few shared hosts had DBI and DBD::mysql installed. It's some gloriously horrible code. They did a ground-up rewrite and then hired me to maintain it, right as PHP was becoming popular.
They refused to do a PHP version until it was too late. Someone else translated our code into PHP, then rewrote it a few times before releasing it. Over just a year or two, our marketshare plummeted, and now the UBB is a distant memory. We couldn't deliver a competing product.
Even if perl hadn't lost the deployability battle, the perl 6 fiasco was what let python and company eat away at the mindshare that wasn't concerned with just web applications.
I immediately knew it was Ultimate Bulletin Board when I read the first sentence of the second paragraph.
Man, I remember UBB. I worked in a dot-com run exclusively by teenagers in 2000, and UBB was the go-to solution for forums. I also remember spending a day writing a Perl CGI script to do polls, since the idea of SaaS or outsourcing widgets on your website was in the far future, and everyone knew that you had to have all the source code for your site in cgi-bin.
Those were the days.
Those were the days.
I remember the days of the UBB. Flat file databases, what memories. I also recall UBB getting hacked because the data separator was a pipe bar and the code didn't check for that on input. SQL injection before SQL. Maybe I dreamt that. Either way, I remember my time with flat file databases.
Yup, that was pretty bad. The resulting filtering ended up causing a lot of trouble for folks not using Windows-1252 or something in the ISO-8859 family, as it'd replace pipes in post bodies with the HTML numeric entity for the pipe in that charset. A similar incident is one of the things that got me hired - I was the only one to actually pick up a phone and call their office and talk to tech support about the sheer size of the possible bug.
The most fun security bug the previous major version had was a side effect of file naming. In order to prevent users from just downloading data files, every data file was given the .cgi extension and was always saved as 0777 because shared hosting sucks and nobody ever used suexec like they should.
The file format for user records is the login name on the first line, and the plaintext password on the second, email on the third. Someone figured out that #, ! and / weren't filtered in usernames. See where this is going yet? If the directory containing member records was available inside the document root, someone could perform trivial remote command execution.
The second most fun was people discovering XSS before it was called XSS. With some creative quoting, you could inject javascript into the markup.
I'm just thankful nobody figured out CSRF, I'd have hated to figure out how to deal with that way back then...
The most fun security bug the previous major version had was a side effect of file naming. In order to prevent users from just downloading data files, every data file was given the .cgi extension and was always saved as 0777 because shared hosting sucks and nobody ever used suexec like they should.
The file format for user records is the login name on the first line, and the plaintext password on the second, email on the third. Someone figured out that #, ! and / weren't filtered in usernames. See where this is going yet? If the directory containing member records was available inside the document root, someone could perform trivial remote command execution.
The second most fun was people discovering XSS before it was called XSS. With some creative quoting, you could inject javascript into the markup.
I'm just thankful nobody figured out CSRF, I'd have hated to figure out how to deal with that way back then...
Weirdly, I updated a perl based web application that used flat files for data storage (a web crawler and search engine) to modern perl not too long ago I hadn't realized that flat file storage was created as a way to get around DB installation.
I'm curious if anyone really expected Perl 6 to arrive like the article describes ("The problem wasn't apparent in 2000."). I was just a junior programmer, and I loved 5.6, but from the beginning 6 sounded to me like it would be a wholly different language, probably never delivered, and certainly never adopted. Maybe I'm projecting, but I felt that was a broad sentiment back then. By 2001 I was writing Python half time or more, and even though I felt a great fondness for Perl while Python left me cold, it still felt like it delivered everything Perl 6 aspired to (if you could stand the lack of regex literals, grr.....). Once Ruby became popular we got all the good things of Perl without the aridity of Python, so there was even less reason to care. In the late '00s I took a few years off programming to do a degree in Classics, and I kept telling myself half-jokingly that if Perl 6 shipped I'd know I'd been away too long. When Parrot was released I figured I'd better get back in the game.
That's not to say Perl 6 wasn't needed. Among programming languages Perl was probably my first love, especially the linguistics tie-ins with $ @ % etc, but write-only was a real problem, and people were moving to Python on the one hand and Java on the other. Maybe PHP killed Perl for low-end cheap hosting, but for larger projects, among people who would never have considered PHP, it lost because picking it seemed irresponsible.
That's not to say Perl 6 wasn't needed. Among programming languages Perl was probably my first love, especially the linguistics tie-ins with $ @ % etc, but write-only was a real problem, and people were moving to Python on the one hand and Java on the other. Maybe PHP killed Perl for low-end cheap hosting, but for larger projects, among people who would never have considered PHP, it lost because picking it seemed irresponsible.
I started calling it out as vaporware around the Holidays 2001. I would be shouted down by certain zealots who would tell me code (pre-Alpha quality) was available for use right now.
At least there are people maintaining Perl 5 at this point.
At least there are people maintaining Perl 5 at this point.
There are commits to Rakudo, a Perl 6 compiler, every day. It's also scheduled to be production ready by the end of 2015.
You might be right. But I have been reading forum posts to this effect for fifteen years, and eventually eveyone switches off. Even if you are right, would you trust your career focus to a software community who had got it this wrong for that long? I am looking forward to checking out a future perl 6 but part of that is now duke nukem forever curiosity - what on earth could be in it that kept those smart people at it for that long?
I'd disagree with the assessment of Python3 somehow being sunset in 2020. This 2020 End of Life stuff is a marketing tactic to sell it. There are companies with 500K line codebases of Python that won't be on Python3 in 2020, if ever. It's just not feasible when new features have to be shipped. Expect pain (not for the companies in question, for Python3), in the form of a fork. The book isn't closed on this one yet.
I can't help but think that we'll eventually be seeing "Why Python3 Didn't Win". Perl and Python both foolishly abdicated the throne. While shots are fired, I think Python3 could still recover with more compromises from its 'leadership'.
I can't help but think that we'll eventually be seeing "Why Python3 Didn't Win". Perl and Python both foolishly abdicated the throne. While shots are fired, I think Python3 could still recover with more compromises from its 'leadership'.
While you may end up being right, Perl6 is a much larger departure from Perl5 (than Python3 is from Python2). Can one even use CPAN with Perl6? Is it even possible to convert existing Perl5 CPAN packages to support both versions at the same time (like all of the PyPI packages that support both Python2 and Python3)?
> Can one even use CPAN with Perl6?
Yes.
At a Perl conference in October last year Stefan Seifert decided it was time for him to have a go at something Perl 6 related. He had never written Perl 6 code before, let alone participated in the project, but within 24 hours he had Perl 6 calling Perl 5 calling Python[1].
That was just a few months ago. Now the Inline::Perl5 module[2] allows folk to use Perl 5 modules, even ones that do C level guts poking in to the Perl 5 interpreter, and to pass data back and forth, do callbacks back and forth, handle exceptions raised by Perl 5 in Perl 6 and vice-versa, use Perl 6 to call methods on Perl 5 objects and vice-versa, and use Perl 6 to subclass Perl 5 classes. Thus he's been able to, for example, create apps in Perl 6 using a leading Perl 5 web framework called Catalyst.[3] He's also having fun with calling Python libs from Perl 6.[4]
There's a lot more going on related to interop between Perl 6 and Perl 5, and more generally between Perl 6 and other languages, but the above is obviously a biggie.
> Is it even possible to convert existing Perl5 CPAN packages to support both versions at the same time
As is hopefully clear, with Inline::Perl5 there's no need to convert.
(Some folk will still want to rewrite some Perl 5 code in to Perl 6, and there are fledgling tools to assist, but they aren't necessary, just a nice option to have.)
[1] https://www.youtube.com/watch?v=m_Y-lvQP6jI&list=UU7PuZDAIVM...
[2] https://github.com/niner/Inline-Perl5
[3] http://www.reddit.com/r/perl6/comments/2k6ii8/nines_apw_talk...
[4] http://www.reddit.com/r/perl6/comments/2n27el/perl6_20141121...
Yes.
At a Perl conference in October last year Stefan Seifert decided it was time for him to have a go at something Perl 6 related. He had never written Perl 6 code before, let alone participated in the project, but within 24 hours he had Perl 6 calling Perl 5 calling Python[1].
That was just a few months ago. Now the Inline::Perl5 module[2] allows folk to use Perl 5 modules, even ones that do C level guts poking in to the Perl 5 interpreter, and to pass data back and forth, do callbacks back and forth, handle exceptions raised by Perl 5 in Perl 6 and vice-versa, use Perl 6 to call methods on Perl 5 objects and vice-versa, and use Perl 6 to subclass Perl 5 classes. Thus he's been able to, for example, create apps in Perl 6 using a leading Perl 5 web framework called Catalyst.[3] He's also having fun with calling Python libs from Perl 6.[4]
There's a lot more going on related to interop between Perl 6 and Perl 5, and more generally between Perl 6 and other languages, but the above is obviously a biggie.
> Is it even possible to convert existing Perl5 CPAN packages to support both versions at the same time
As is hopefully clear, with Inline::Perl5 there's no need to convert.
(Some folk will still want to rewrite some Perl 5 code in to Perl 6, and there are fledgling tools to assist, but they aren't necessary, just a nice option to have.)
[1] https://www.youtube.com/watch?v=m_Y-lvQP6jI&list=UU7PuZDAIVM...
[2] https://github.com/niner/Inline-Perl5
[3] http://www.reddit.com/r/perl6/comments/2k6ii8/nines_apw_talk...
[4] http://www.reddit.com/r/perl6/comments/2n27el/perl6_20141121...
It is a different departure, and it isn't a 1:1 comparison. That's true.
But Python3 is an obvious failure and no one is admitting it, yet. I've seen claims from the core dev team about how Python3 is doing well because it has more downloads from Python.org, which is so stupid I won't even address it. A comparison of PyPI download statistics says it all.
Python3 migration had many ridiculous ways of pushing people to migrate. The answer for Python3's adoption was always something new. It reads like the list of reasons for invading Iraq.
Originally (and today's) overly optimistic EOL for Python2, then automated code conversion utilities, then porting all the major libraries, then 'six' type libraries to allow an ugly PythonX middle ground, then adding 3.x-only new features as a carrot, now the bright idea from the core dev team is to focus on pushing Python3 as the default install on distros. They all failed. Python3 as default on most distros won't do anything either.
All that said, and I think this is the best-case scenario: Python3 will survive and eventually thrive. It will just be a shadow of Python's former glory.
Is that -really- worth forcing unicode handling? For Zeus' sake, I wouldn't think so. This coming from someone who agrees with the change in theory.
But Python3 is an obvious failure and no one is admitting it, yet. I've seen claims from the core dev team about how Python3 is doing well because it has more downloads from Python.org, which is so stupid I won't even address it. A comparison of PyPI download statistics says it all.
Python3 migration had many ridiculous ways of pushing people to migrate. The answer for Python3's adoption was always something new. It reads like the list of reasons for invading Iraq.
Originally (and today's) overly optimistic EOL for Python2, then automated code conversion utilities, then porting all the major libraries, then 'six' type libraries to allow an ugly PythonX middle ground, then adding 3.x-only new features as a carrot, now the bright idea from the core dev team is to focus on pushing Python3 as the default install on distros. They all failed. Python3 as default on most distros won't do anything either.
All that said, and I think this is the best-case scenario: Python3 will survive and eventually thrive. It will just be a shadow of Python's former glory.
Is that -really- worth forcing unicode handling? For Zeus' sake, I wouldn't think so. This coming from someone who agrees with the change in theory.
FWIW, I just founded a new startup and we're using Python3. No major problems so far, and I find it much more pleasant to work with than Python2.5-2.7 (which I used in my last startup, and at Google). Dictionary comprehensions are great, keyword-only arguments have been necessary in a couple cases, Unicode's not a total mess, I like how the standard library naming & packaging has been cleaned up, and I suspect I'll love asyncio when the time comes to use it. The only library we wanted which doesn't support it is Splunk, and that was Splunk's loss (we just switched to PaperTrail).
There's an awful lot of FUD and hate for Python3 on Hacker News, but I've found it's great for a green-field project. And folks with 500KLOC existing systems should know that their technology choices are basically locked in time to when they started the project, anyway.
There's an awful lot of FUD and hate for Python3 on Hacker News, but I've found it's great for a green-field project. And folks with 500KLOC existing systems should know that their technology choices are basically locked in time to when they started the project, anyway.
Man I remember when Splunk were the innovative disrupters. Now they're the ones who won't update their library for the current version of Python.
All the talk has felt like giving up right before the finish line to me; it seems like migration was chugging along and then there was this huge backlash just before every distro made 3 the default, which would basically have been mission accomplished. Arch and to a certain extent gentoo were already there. And then suddenly, after quietly going along with it for 5+ years, everyone wanted to throw their toys out of the pram rather than do a little bit more. It's enough to make one think of conspiracies.
As far as I can see, python 3 is there now; it's the default on my servers, all the libraries support it, and it's a nicer language to program in. And just as that became true, everyone started losing their minds.
As far as I can see, python 3 is there now; it's the default on my servers, all the libraries support it, and it's a nicer language to program in. And just as that became true, everyone started losing their minds.
> Is that -really- worth forcing unicode handling?
I dunno. I'm new to Python (version 2 so far) and I easily spend 25-50% of my coding time fighting with ascii/unicode issues in Python. I wish Python 2.x just did something smarter.
Similar, but not quite as bad, is the need for me to put str() around non-string values in concatenation. Just f'ing doing it for me. I'll write a bunch of code, put together a message in a concatenation only to have it blow up at run-time because of this.
sigh I really miss Perl's implicit behaviors sometimes.
I dunno, maybe this all is making me a better programmer and person, forcing me to really deal with Unicode now, and breaking me of lots of Perl bad habits. But it's really one of the sucky parts of the language.
There's some days, after spending half the day fighting with this issue, that I almost decide to dump the whole thing and switch to Python 3.
I dunno. I'm new to Python (version 2 so far) and I easily spend 25-50% of my coding time fighting with ascii/unicode issues in Python. I wish Python 2.x just did something smarter.
Similar, but not quite as bad, is the need for me to put str() around non-string values in concatenation. Just f'ing doing it for me. I'll write a bunch of code, put together a message in a concatenation only to have it blow up at run-time because of this.
sigh I really miss Perl's implicit behaviors sometimes.
I dunno, maybe this all is making me a better programmer and person, forcing me to really deal with Unicode now, and breaking me of lots of Perl bad habits. But it's really one of the sucky parts of the language.
There's some days, after spending half the day fighting with this issue, that I almost decide to dump the whole thing and switch to Python 3.
> sigh I really miss Perl's implicit behaviors sometimes.
I never had too much of an issue with Perl's implicit behaviours, but it enables some really lazy programming, even from (otherwise) smart people that are gung-ho about Modern Perl. E.g.:
There's also stuff like this[1] for Perl + Unicode. :^P
[1] https://stackoverflow.com/questions/6162484/why-does-modern-...
I never had too much of an issue with Perl's implicit behaviours, but it enables some really lazy programming, even from (otherwise) smart people that are gung-ho about Modern Perl. E.g.:
sub { map { "$_ $_[0]" } @{shift->[0]} }
There's also stuff like this[1] for Perl + Unicode. :^P
[1] https://stackoverflow.com/questions/6162484/why-does-modern-...
The problem is that both support unicode and 2 vs 3 unicode handling are just two different ways to do it.
Which places Python3 firmly in the 'technological churn' category, rather than true technical innovation.
I'd probably agree 3.x is more Pythonic in this regard, but I think it was an ill-advised move. Plenty of reasoning in my last response as to why.
Why not go ahead and use Python3, you may find it works for you. For me, there's a long tail of libraries that don't exist there, and frankly following the core dev teams' example- we should all act in our own best interests. I'm far more productive in 2.x.
I may eventually move to 3.x, but it will have to be based on its merits. Rather than dogma, salesmanship or propaganda. Today it isn't even close to 2.x and we're nearing 7 years since 3.0 was released.
Unlike most things in life such as updating some software package, the "latest version" of a programming language isn't always in your best interests. I think this is a hard mental barrier to break down, especially people coming into Python now.
But I would always recommend learning/using 2.x, not only is it easier to build cool things with it (the whole point), but you have to learn 2.x. You can avoid 3 entirely, without any issue whatsoever.
I'd probably agree 3.x is more Pythonic in this regard, but I think it was an ill-advised move. Plenty of reasoning in my last response as to why.
Why not go ahead and use Python3, you may find it works for you. For me, there's a long tail of libraries that don't exist there, and frankly following the core dev teams' example- we should all act in our own best interests. I'm far more productive in 2.x.
I may eventually move to 3.x, but it will have to be based on its merits. Rather than dogma, salesmanship or propaganda. Today it isn't even close to 2.x and we're nearing 7 years since 3.0 was released.
Unlike most things in life such as updating some software package, the "latest version" of a programming language isn't always in your best interests. I think this is a hard mental barrier to break down, especially people coming into Python now.
But I would always recommend learning/using 2.x, not only is it easier to build cool things with it (the whole point), but you have to learn 2.x. You can avoid 3 entirely, without any issue whatsoever.
Are you using Python 2.X because you are maintaining existing code, or because Python 3 is just plain unsuitable for what you're trying to do?
I hear a lot of complaints about Python 3, but in my (limited) experience, 3 is better than 2.X in practically every situation I've experienced. But I've never had to maintain anybody's old code in it, either.
I hear a lot of complaints about Python 3, but in my (limited) experience, 3 is better than 2.X in practically every situation I've experienced. But I've never had to maintain anybody's old code in it, either.
> Today it isn't even close to 2.x
So are you saying that it's clearly "pulled ahead" in the race? Or that Python 3.x is a significant regression? Your "technological churn" comment makes it seem like you think it's just treading water, which I would interpret to mean a lack of progress vs. a step forward (or back).
So are you saying that it's clearly "pulled ahead" in the race? Or that Python 3.x is a significant regression? Your "technological churn" comment makes it seem like you think it's just treading water, which I would interpret to mean a lack of progress vs. a step forward (or back).
To avoid str() calls with concatenation, use % formatting:
I'd recommend going for Python 3 unless there's a specific reason (library) keeping you on 2.
'%s %s' % ('hello', 'world')
I'd recommend going for Python 3 unless there's a specific reason (library) keeping you on 2.
I'd recommend:
'{} {}'.format('hello', 'world')
I never understood the need for the new style of formatting, or the advantage. Fortunately % formatting is no longer getting deprecated.
The only downside that I've come across is when you do something like:
"%s %s" % blah
> then porting all the major libraries
Yup, this was a gradual process, but by now everything I need is ported, even Django.
> now the bright idea from the core dev team is to focus on pushing Python3 as the default install on distros. They all failed. Python3 as default on most distros won't do anything either.
It worked on me: When Arch Linux made it the default I figured it was finally time to adopt it for my various everyday utility scripts, which resulted in me successfully pushing for it at work as the implementation language for several projects.
Yup, this was a gradual process, but by now everything I need is ported, even Django.
> now the bright idea from the core dev team is to focus on pushing Python3 as the default install on distros. They all failed. Python3 as default on most distros won't do anything either.
It worked on me: When Arch Linux made it the default I figured it was finally time to adopt it for my various everyday utility scripts, which resulted in me successfully pushing for it at work as the implementation language for several projects.
@bane - can I ask why you don't switch to Python 3?
> Can one even use CPAN with Perl6? Is it even possible to convert existing Perl5 CPAN packages to support both versions at the same time (like all of the PyPI packages that support both Python2 and Python3)?
Respectively: Not at all, and not without major contortions. The languages have diverged a lot; even basic tasks like defining a function are not the same.
Respectively: Not at all, and not without major contortions. The languages have diverged a lot; even basic tasks like defining a function are not the same.
> Not at all [can one use CPAN]
You are mistaken. See my nearby comment about Inline::Perl5.
> not without major contortions [can one convert].
One doesn't need to convert (due to Inline::Perl5).
That said there can be valid reasons (eg having fun and learning Perl 6) to want to convert existing Perl 5 code to a Perl 6 equivalent anyway. While some partial P5-to-P6 conversion tools already exist[1] (and I'd be surprised if more don't arrive in the future[2]), conversion of a well written Perl 5 module in to a well written Perl 6 module is mostly a manual exercise.[3]
> even basic tasks like defining a function are not the same.
Could you provide some code to illustrate what you mean?
---
[1] http://www.perlito.org/perlito/perlito5to6.html Incomplete but better than nothing.
[2] https://github.com/rakudo-p5/v5/ is a project to create a Perl 5 compiler written in Perl 6. It parses Perl 5 code and spits out Perl 6 ASTs. It's obviously not a huge jump for it to spit out straight Perl 6 code. One day...
[3] http://jnthn.github.io/css-tiny-presentation/presentation/#/
You are mistaken. See my nearby comment about Inline::Perl5.
> not without major contortions [can one convert].
One doesn't need to convert (due to Inline::Perl5).
That said there can be valid reasons (eg having fun and learning Perl 6) to want to convert existing Perl 5 code to a Perl 6 equivalent anyway. While some partial P5-to-P6 conversion tools already exist[1] (and I'd be surprised if more don't arrive in the future[2]), conversion of a well written Perl 5 module in to a well written Perl 6 module is mostly a manual exercise.[3]
> even basic tasks like defining a function are not the same.
sub foo ($foo, @bar) {
my $qux;
# do something
return $qux
}
Could you provide some code to illustrate what you mean?
---
[1] http://www.perlito.org/perlito/perlito5to6.html Incomplete but better than nothing.
[2] https://github.com/rakudo-p5/v5/ is a project to create a Perl 5 compiler written in Perl 6. It parses Perl 5 code and spits out Perl 6 ASTs. It's obviously not a huge jump for it to spit out straight Perl 6 code. One day...
[3] http://jnthn.github.io/css-tiny-presentation/presentation/#/
Perl5.18 has some limited support for Perl6-style function signatures, but it's still considered "experimental" and requires a pragma to enable. I don't consider that to really be part of the language yet; real-world Perl5 function definitions end up looking like this, at best:
sub foo {
my ($foo, @bar) = @_;
...
}
Yes, that works in Perl 6 too.
So, to recap:
> Can one even use CPAN with Perl6?
Yes.
A Perl 5 coder might write:
(Another important `from` option in Perl 6 that's currently being brought up to production grade is `:from<Java>`.)
The `.` rather than a `->` in the print statement line is another giveaway that this is Perl 6 code. And the `[1]`; is that a Perl 5 or a Perl 6 array literal? It doesn't matter. This line is a taste of how slick Perl 6 interop magic is. You barely notice it, but the language is automatically marshaling data and objects back and forth between languages as necessary.
Of course, the above is a trivial example. But that's not because complex examples don't work; within a few weeks of starting Inline::Perl5 its author Stefan Seifert was demoing a Catalyst app written in Perl 6. That needed fancy stuff beyond mere passing objects back and forth; in this case Perl 6 code had to subclass a class from another language, in this case Perl 5, and have Perl 5 accept objects made with the subclass as if they were Perl 5 objects made from a Perl 5 subclass.
Inline::Perl5 hasn't yet been smoke tested with all 130,000 CPAN modules, and it will no doubt fail with a few, and a similar story applies for the even more immature support for calling Java libs, but this tech ought to be a game changer, at least within the Perl community.
> Is it even possible to convert existing Perl5 CPAN packages?
There's no need. (See previous point.)
But if you really want to, then yes it is possible, and seems to be enjoyable. Reports I've read of P5-to-P6 conversion stories tend to express satisfaction that basic syntax is generally the same, the changes that are necessary make sense, and the final code is a lot shorter, often half the length, and is very readable.
It's not all roses with Perl 6. There's plenty to bitch about. (#1 is still speed.) But use of CPAN modules, and writing Perl 6 code alongside Perl 5 code, are quickly shifting over to the strengths column for Perl 6, not the weakness one.
So, to recap:
> Can one even use CPAN with Perl6?
Yes.
A Perl 5 coder might write:
use Data::Dumper;
print Data::Dumper->Dump([1]);
use Data::Dumper:from<Perl5>;
print Data::Dumper.Dump([1]);
(Another important `from` option in Perl 6 that's currently being brought up to production grade is `:from<Java>`.)
The `.` rather than a `->` in the print statement line is another giveaway that this is Perl 6 code. And the `[1]`; is that a Perl 5 or a Perl 6 array literal? It doesn't matter. This line is a taste of how slick Perl 6 interop magic is. You barely notice it, but the language is automatically marshaling data and objects back and forth between languages as necessary.
Of course, the above is a trivial example. But that's not because complex examples don't work; within a few weeks of starting Inline::Perl5 its author Stefan Seifert was demoing a Catalyst app written in Perl 6. That needed fancy stuff beyond mere passing objects back and forth; in this case Perl 6 code had to subclass a class from another language, in this case Perl 5, and have Perl 5 accept objects made with the subclass as if they were Perl 5 objects made from a Perl 5 subclass.
Inline::Perl5 hasn't yet been smoke tested with all 130,000 CPAN modules, and it will no doubt fail with a few, and a similar story applies for the even more immature support for calling Java libs, but this tech ought to be a game changer, at least within the Perl community.
> Is it even possible to convert existing Perl5 CPAN packages?
There's no need. (See previous point.)
But if you really want to, then yes it is possible, and seems to be enjoyable. Reports I've read of P5-to-P6 conversion stories tend to express satisfaction that basic syntax is generally the same, the changes that are necessary make sense, and the final code is a lot shorter, often half the length, and is very readable.
It's not all roses with Perl 6. There's plenty to bitch about. (#1 is still speed.) But use of CPAN modules, and writing Perl 6 code alongside Perl 5 code, are quickly shifting over to the strengths column for Perl 6, not the weakness one.
I'm practically giddy. :)
P6's speed is still well behind Perl 5, but it's catching up very, very quickly.
And performance improvements won't stop there: https://fosdem.org/2015/schedule/event/perl6_beyond_dynamic_...
P6's speed is still well behind Perl 5, but it's catching up very, very quickly.
And performance improvements won't stop there: https://fosdem.org/2015/schedule/event/perl6_beyond_dynamic_...
Too many people arguing about about function signatures are under the impression that this needs to be part of the core language. Turns out, it doesn't: Perl is flexible enough to have its syntax amended.
As a practical programmer, I have enjoyed signatures and run-time type checking for years, provided by libraries. Even now, these libraries are more featureful than core signatures.
As a practical programmer, I have enjoyed signatures and run-time type checking for years, provided by libraries. Even now, these libraries are more featureful than core signatures.
Respectively: https://github.com/rakudo-p5/v5
While not quite the same as what was asked, it's clear that 'not at all' is not an informed answer
While not quite the same as what was asked, it's clear that 'not at all' is not an informed answer
That module's neat, but CPAN is still out of reach. For one, a lot of important modules in CPAN contain XS components, which don't carry over. Additionally, a lot of the modules that don't use XS are likely to be using unusual features of Perl5 which aren't fully emulated by that shim.
Yes. v5, a Perl 5 compiler written in Perl 6, is promising tech with potentially huge long term (10 years) strategic consequences for Perl 5 and Perl. But it's very early days and it correctly handles only the simplest of modules. I'd hazard a guess that currently less than 1% of CPAN modules pass their tests when loaded by v5.
But Inline::Perl5 is a completely different animal. It handles modules using XS or whatever fine. See my nearby comments for further details.
But Inline::Perl5 is a completely different animal. It handles modules using XS or whatever fine. See my nearby comments for further details.
As its now been pointed out more than once, 'not at all' is not true. I did not claim it could use everything available on CPAN, but was pointing out that you were making a false statement based on, well, i'm not sure what you based your statement on but it was made in such a matter-of-factly way that it needed to be corrected.
I know of a large Python 1.6 code base still in constant use. I don't think this is unique to 'major breaking updates' or Python 3. Hell, there are codebases still in Fortran 77 doing key work.
And why would you need to fork Python 3 to support Python 2 codebases?
And why would you need to fork Python 3 to support Python 2 codebases?
When I was younger I pushed myself to know Perl 5. I tried to learn Perl with one book. It was surprinsingly hard. I took a simpler book. I also failed grasping Perl. Those were the two recommended books for learning.
I've come to realize years after that Perl is simply difficult to learn, lots of little things to memorize. Its community took pride in language arcana. Things that are now simple in other languages are unbelievably difficult in Perl, like "hashes of arrays of hashes" and things like that.
On top of that, it's also difficult to read. No wonder Perl is losing, and to me the faster the world is cleanup from that, the better.
I've come to realize years after that Perl is simply difficult to learn, lots of little things to memorize. Its community took pride in language arcana. Things that are now simple in other languages are unbelievably difficult in Perl, like "hashes of arrays of hashes" and things like that.
On top of that, it's also difficult to read. No wonder Perl is losing, and to me the faster the world is cleanup from that, the better.
Learning Perl is excellent for a beginner
You're incorrect in your realization. The truth is that the older books for learning perl are simply shitty.
If you read Ovid's Beginning Perl, or chromatic's Modern Perl, you'll find they managed to explain the concepts very easily.
If you read Ovid's Beginning Perl, or chromatic's Modern Perl, you'll find they managed to explain the concepts very easily.
No, he's right. Perl is shitty. Have you ever read a random Perl script? It's impossible to interpret.
"No, he's right. Japanese is shitty. Have you ever read a random Japanese scroll? It's impossible to interpret. Even in romaji!"
Rewriting your language, like any other piece of software, is a great way to lose your market position: http://www.joelonsoftware.com/articles/fog0000000069.html
Its a damned if you do, damned if you don't situation.
You have to evolve to survive. If you don't don't you may stay alive for a while. But you will die slowly.
You have to evolve to survive. If you don't don't you may stay alive for a while. But you will die slowly.
People forget that if one is forced to re-write the code, it might as well just use another language.
I mostly agree with Joel there. It's worth pointing out that if doing a from-scratch rewrite of your end-user app is a bad idea, then doing a from-scratch rewrite of your platform that will force all of your users to do from-scratch rewrites of their apps must be orders of magnitude worse.
The "Maintenance and greenfield concerns are very different" section is relevant to my interests:
> The implications for a programming language are difficult to prove conclusively, but simple to explain: an ecosystem focused more on maintaining existing projects than creating new projects will be less attractive for new projects.
Ruby/Rails provides an interesting example here. The ruby and rails community ecosystem (the author is right it's about "ecosystem" more than the language) -- has, in general, done it's best to focus as much as possible on innovation over stability. That is, has tried to choose focus on creating new projects over support for existing projects.
Much to the frustration of some in the ruby ecosystem with existing projects to support.
(Rails, of course, from one perspective is an existing project; from another is a framework, which has generally over it's history cared more about new projects that will be created with Rails than existing projects built on Rails that need to be supported).
Of course, there still are existing projects, and there are still developers participating in the ecosystem who need to support those existing projects. So you can only go so far.
What has this done for ruby/rails ecosystem? Hard to say. Overall it's been successful, but it still can't make the ecosystem as greenfield as a true greenfield ecosystem, which is perhaps why some are leaving ruby/rails for greener pastures -- more than any qualities of ruby as a language, it's just the opportunity to be in a greenfield ecosystem that is attractive, perhaps.
> The implications for a programming language are difficult to prove conclusively, but simple to explain: an ecosystem focused more on maintaining existing projects than creating new projects will be less attractive for new projects.
Ruby/Rails provides an interesting example here. The ruby and rails community ecosystem (the author is right it's about "ecosystem" more than the language) -- has, in general, done it's best to focus as much as possible on innovation over stability. That is, has tried to choose focus on creating new projects over support for existing projects.
Much to the frustration of some in the ruby ecosystem with existing projects to support.
(Rails, of course, from one perspective is an existing project; from another is a framework, which has generally over it's history cared more about new projects that will be created with Rails than existing projects built on Rails that need to be supported).
Of course, there still are existing projects, and there are still developers participating in the ecosystem who need to support those existing projects. So you can only go so far.
What has this done for ruby/rails ecosystem? Hard to say. Overall it's been successful, but it still can't make the ecosystem as greenfield as a true greenfield ecosystem, which is perhaps why some are leaving ruby/rails for greener pastures -- more than any qualities of ruby as a language, it's just the opportunity to be in a greenfield ecosystem that is attractive, perhaps.
I don't think Perl will ever recover from the Perl 6 fiasco, and I'm worried for Python for the same reason.
PHP, on the other hand, handled the PHP 6 "failure" relatively gracefully. There was a bit of stagnation in the days of PHP 5.2 when the devs devoted too much energy to PHP 6 and not enough on improving the current version. But soon, PHP 6 was put on hold and some of its better parts began to be ported to PHP 5. Thanks to this decision, PHP has improved by leaps and bounds since 5.3. Also thanks to the lessons learned, nobody is particularly worried about any breaking changes in PHP for the foreseeable future. Everyone knows that any script that works in PHP 5.6 will probably work just fine in 7.0, so new projects continue to be written in PHP. This peace of mind is very important for languages that carry a lot of legacy baggage.
If there's anything for other languages to learn from PHP, it would be their graceful handling of PHP 6 -> 5.3~5.6. The syntax is still terrible, and the default behavior remains borderline insane, but PHP since 2009 has been an exemplar of how a widely used scripting language should handle new versions.
PHP, on the other hand, handled the PHP 6 "failure" relatively gracefully. There was a bit of stagnation in the days of PHP 5.2 when the devs devoted too much energy to PHP 6 and not enough on improving the current version. But soon, PHP 6 was put on hold and some of its better parts began to be ported to PHP 5. Thanks to this decision, PHP has improved by leaps and bounds since 5.3. Also thanks to the lessons learned, nobody is particularly worried about any breaking changes in PHP for the foreseeable future. Everyone knows that any script that works in PHP 5.6 will probably work just fine in 7.0, so new projects continue to be written in PHP. This peace of mind is very important for languages that carry a lot of legacy baggage.
If there's anything for other languages to learn from PHP, it would be their graceful handling of PHP 6 -> 5.3~5.6. The syntax is still terrible, and the default behavior remains borderline insane, but PHP since 2009 has been an exemplar of how a widely used scripting language should handle new versions.
> Everyone knows that any script that works in PHP 5.6 will probably work just fine in 7.0
This is no longer strictly true. On Friday, the "let's remove all the deprecated stuff" RFC was passed. Anything that causes an E_DEPRECATED in 5.6 will now be a fatal in 7. For example, ext/ereg and ext/mysql are no longer included, and have been shipped off to PECL. Shouldn't be a problem for anyone that doesn't compile their own, really. A few php.ini settings are also now removed, which will fatal on startup.
It'll be safe to say that if your code runs fine under 5.6 with error_reporting set to -1, then you'll probably run under 7 without too much trouble.
This is no longer strictly true. On Friday, the "let's remove all the deprecated stuff" RFC was passed. Anything that causes an E_DEPRECATED in 5.6 will now be a fatal in 7. For example, ext/ereg and ext/mysql are no longer included, and have been shipped off to PECL. Shouldn't be a problem for anyone that doesn't compile their own, really. A few php.ini settings are also now removed, which will fatal on startup.
It'll be safe to say that if your code runs fine under 5.6 with error_reporting set to -1, then you'll probably run under 7 without too much trouble.
You're right, any code that runs without errors in 5.6 will probably run fine in 7.0.
And that's exactly how deprecation is supposed to work! No massive changes, only incremental changes, and even those incremental changes come with at least a couple of years of grace period.
And that's exactly how deprecation is supposed to work! No massive changes, only incremental changes, and even those incremental changes come with at least a couple of years of grace period.
> It'll be safe to say that if your code runs fine under 5.6 with error_reporting set to -1, then you'll probably run under 7 without too much trouble.
Not completely, ext/mysql does not output E_DEPRECATED. Although I guess installing a compatibility library is probably not all that much trouble.
Not completely, ext/mysql does not output E_DEPRECATED. Although I guess installing a compatibility library is probably not all that much trouble.
Calling mysql_connect will cause an E_DEPRECATED. Same with mysql_pconnect.
Source: the manual page. http://php.net/mysql_connect
None of the other ext/mysql functions do so.
Source: the manual page. http://php.net/mysql_connect
None of the other ext/mysql functions do so.
Python will be beaten by those caring about performance for writting applications instead of plain server scripts.
Those will migrate to Julia, Go, or something else.
I used Python a lot in the last decade (2000 - 2004) for automatation and little applications.
Nowadays my choice would be OCaml for the same type of tasks.
EDIT: typo, automatic => automatation
Those will migrate to Julia, Go, or something else.
I used Python a lot in the last decade (2000 - 2004) for automatation and little applications.
Nowadays my choice would be OCaml for the same type of tasks.
EDIT: typo, automatic => automatation
Those caring about performance are already using Python, in combination with extension modules written in C/Cython. You would have to complete your argument by explaining why they would rather switch to a completely new language without a huge (scientific) ecosystem of libraries, instead of writing more extension modules in the places where it really matters.
The appeal of a scripting language is that "automatation and little applications" do not take a lot of friction to write, I'd say OCaml is less suited in this regard.
The appeal of a scripting language is that "automatation and little applications" do not take a lot of friction to write, I'd say OCaml is less suited in this regard.
As someone that cares about performance I don't use Python any longer, except on cases where customers require me to do so.
I don't need to convince others to join any kind of cause.
I don't need to convince others to join any kind of cause.
I don't follow. I am not talking about any kind of cause. However, you made a specific prediction, that "Python will be beaten", and I'm saying you haven't made a proper argument why that is so.
As someone who cares about performance I still use Python for the non-performance critical parts of code, which is the vast majority.
I'm pretty sure that in the end this is just a matter of personal preference, but you make it sound as if there are objective arguments without actually presenting them.
As someone who cares about performance I still use Python for the non-performance critical parts of code, which is the vast majority.
I'm pretty sure that in the end this is just a matter of personal preference, but you make it sound as if there are objective arguments without actually presenting them.
My line of thought while replying to the parent is that if a rewrite is needed, those that are more performance minded, are likely to use a language that doesn't suffer from GIL or a pure interpreter as canonical implementation.
Somehow you can already see it on the interwebs. The majority of Go and Julia users come from Python and Ruby, not from languages that have AOT/JIT compilers on their toolchains.[0]
This is just my gut feeling from almost 30 years watching similar technology transitions.
I have no data to back it up and may be completly wrong.
[0] There is PyPy, but I never saw it being deployed in production systems.
Somehow you can already see it on the interwebs. The majority of Go and Julia users come from Python and Ruby, not from languages that have AOT/JIT compilers on their toolchains.[0]
This is just my gut feeling from almost 30 years watching similar technology transitions.
I have no data to back it up and may be completly wrong.
[0] There is PyPy, but I never saw it being deployed in production systems.
Numba + Blaze boosts numerical python to speeds on par with or greater than julia, with additional out of core, delayed expression and multiple backend capabilities that Julia currently does not have.
This might stem the tide for a while... Then we have pyston which maintains C api compatibility.
This might stem the tide for a while... Then we have pyston which maintains C api compatibility.
Are they written in Python?
Blaze is, Numba is a JIT compiler to LLVM. You can write numpy functions and JIT/Multithread them with just a decorator and zero to few code changes. Blaze makes this transparent to the user, chunks backends, provide out of core array object, abstract expressions etc.
Version number is micro, this is a macro question, to wit, the following:
When I converted a perl script to python and saved 50% LOC I didn't know which version of which I was using. Am only vaguely aware of the Python 2.x vs. 3 issues. Never was aware of Perl 5 vs. 6.
When Python and Ruby fade, I look forward to the hand wringing about how version whatever didn't get pushed out fast enough. But that won't be the reason.
When I converted a perl script to python and saved 50% LOC I didn't know which version of which I was using. Am only vaguely aware of the Python 2.x vs. 3 issues. Never was aware of Perl 5 vs. 6.
When Python and Ruby fade, I look forward to the hand wringing about how version whatever didn't get pushed out fast enough. But that won't be the reason.
But you're not a thousand companies who have built their business on Python 2 and have no interest in rewriting working code when they don't have to. Your "scripts" are pretty much irrelevant.
Define won.
This is the way I see it. Perl5 is still being actively developed, perl6 is coming along nicely, cpan more awesome than ever, and there's still work for a perl dev.
If everyone was using the same language, then we'd all suffer because no one would be getting the new ideas.
Competition keeps things healthy.
This is the way I see it. Perl5 is still being actively developed, perl6 is coming along nicely, cpan more awesome than ever, and there's still work for a perl dev.
If everyone was using the same language, then we'd all suffer because no one would be getting the new ideas.
Competition keeps things healthy.
Perl 6 didn't win because the successors to Perl were Python and Ruby, not Perl 6. Agreed, Perl 6 is a sophisticated language, but Python and Ruby have mature VMs you can use today. For values of "today" ranging back in time upwards of ten years.
Yep. I've heard it put "Ruby is the best of Perl, without the rest of Perl".
Oh man, I remember hating to program Perl. With Perl, there wasn't just one way to do things, but there were 10, and all of those involved different combinations of @{} $[] [#] '%' characters put in seemingly random order and changing completely the context on which they operated, with the logic only clear to those who somehow understood the connection between these symbols and their meaning.
Maybe it didn't win because the language syntax was just a mess, and same variables just in different contexts could mean like 3 different things depending on what way you pass them, what you you return them and what kind of random character is in front of them.
Don't take this personally, just ranting out my feelings for the Perl programming language, and glad that it isn't one of the things I have to know anymore! Good riddance!
Maybe it didn't win because the language syntax was just a mess, and same variables just in different contexts could mean like 3 different things depending on what way you pass them, what you you return them and what kind of random character is in front of them.
Don't take this personally, just ranting out my feelings for the Perl programming language, and glad that it isn't one of the things I have to know anymore! Good riddance!
This was really good. The mix of PHP as a better solution for shared hosting (and its simplicity for beginners) and the horror story of Perl 6 were both big setbacks.
Allison Randal wrote on the death of Perl a while back and had some observations worth nothing to understand how it fell: http://allisonrandal.com/2013/03/31/mythbusters-why-i-still-...
I really liked working with Modern Perl, but rarely do anymore mostly since "nobody uses Perl" kills any suggestion even when it might be the right tool for the job. Ruby has become Perl 6 for me.
Allison Randal wrote on the death of Perl a while back and had some observations worth nothing to understand how it fell: http://allisonrandal.com/2013/03/31/mythbusters-why-i-still-...
I really liked working with Modern Perl, but rarely do anymore mostly since "nobody uses Perl" kills any suggestion even when it might be the right tool for the job. Ruby has become Perl 6 for me.
Perl did win, for a period of time .. expecting an interpreted language to dominate for multiple decades is unrealistic, especially with hardware advances that occur over time.
while I don't do anything with it today, I do know Perl/6 would be in contention for my 'deserted island' language of choice.
yet another dph
while I don't do anything with it today, I do know Perl/6 would be in contention for my 'deserted island' language of choice.
yet another dph
I have to agree; if Perl didn't "win", then who did?
Python? Very popular. Solid language. Probably at some point more adopted than Perl, but not so much so that I can say it "won", partially because of how this list goes on.
Ruby? Same.
PHP? Maybe in the web space but not in general.
Javascript? Even in light of Node, this is still a marginal language out of the browser, especially considered over the past 15 years.
Lua? No.
Perl may not have "won" but it has hardly "lost", and now IMHO the sun is just beginning to set on this entire catagory of 1990s-style dynamic scripting language and there probably will be no further "winner" in this space.
Python? Very popular. Solid language. Probably at some point more adopted than Perl, but not so much so that I can say it "won", partially because of how this list goes on.
Ruby? Same.
PHP? Maybe in the web space but not in general.
Javascript? Even in light of Node, this is still a marginal language out of the browser, especially considered over the past 15 years.
Lua? No.
Perl may not have "won" but it has hardly "lost", and now IMHO the sun is just beginning to set on this entire catagory of 1990s-style dynamic scripting language and there probably will be no further "winner" in this space.
[probably shameless plug] I first intended to write this as an answer, but I ended up with a complete blog post:
http://programming.tudorconstantin.com/2015/01/perl-already-...
http://programming.tudorconstantin.com/2015/01/perl-already-...
Watch out for whoever says that Perl is an ancient technology, because they're either ignorant and completely clueless about what's really happening in the world of computer programming, or they have hidden agendas.
That's a strong statement. Are you quite sure those are the only two possibilities?
That's a strong statement. Are you quite sure those are the only two possibilities?
There's this Perl book called Modern Perl. It is written to help others learn about the new technologies available to Perl world. Do you know about the book? oh, you wrote it :)
So yeah, if they don't have hidden agendas and they say that writing Perl apps means writing apps in an old fashion, the only possible alternative is to be ignorant :)
I think Perl didn't win. I don't know the specific context of Romania, but from where I sit, it's unlikely I'll get paid to program in it in the foreseeable future, if ever.
What's my hidden agenda in agreeing with this article over yours?
What's my hidden agenda in agreeing with this article over yours?
The article has valid points. Hidden agenda is when people say that writing Perl is equivalent to using ancient technologies, solely because Perl had its popularity peak in the nineties - and this might also be a reason why you can't be paid for doing Perl - who would want legacy technologies in their stack?
It's just that, well, it isn't legacy. It's more up to date and much more robust than many of the hip languages.
It's just that, well, it isn't legacy. It's more up to date and much more robust than many of the hip languages.
It's no wonder there are issues with Perl 5 to 6 transition they went from:
> They're going to merge Perl 5.12 and Perl 6
in "mid-2001" to:
> There's a Perl 5.8 on the way
in 2002. ^_~
That said, I think that anyone doing serious Perl 5.x work has long since abandoned the idea that Perl 6 has anything to do with Perl 5.x other than sharing the "Perl" name and Larry Wall. Maybe this is confusing to "outsiders" and the branding needs to change? It's not like the Perl 5.x line is not being maintained. Since Perl 5.10, there were some significant improvements, with consistent point releases coming out.
> They're going to merge Perl 5.12 and Perl 6
in "mid-2001" to:
> There's a Perl 5.8 on the way
in 2002. ^_~
That said, I think that anyone doing serious Perl 5.x work has long since abandoned the idea that Perl 6 has anything to do with Perl 5.x other than sharing the "Perl" name and Larry Wall. Maybe this is confusing to "outsiders" and the branding needs to change? It's not like the Perl 5.x line is not being maintained. Since Perl 5.10, there were some significant improvements, with consistent point releases coming out.
The branding will not change, for BDFL reasons. The best all we can do is coming to grips with Perl 6 not being a successor, but a sibling.
Not sure what 'winning is'... I've had a great career in Perl so far and every company I've worked at has been a startup using Perl (not old legacy code). So that's like almost 20 years and every year someone says, "Perl is dead", etc. And every year I just have a blast programming Perl. I've met a ton of great people and I enjoy contributing to open source. So I would say quite complaining about something you personally don't like and get on with doing something useful.
Previous thread: https://news.ycombinator.com/item?id=7866834
If there was no Ruby, I suspect Perl would still be popular. At one point the scripting language holy wars were "Perl vs Python". That turned into "Ruby vs Python". Similar philosophy, lots of better stuff in Ruby.
Perl was dead long before Ruby on Rails was a big thing (Ruby itself was effectively moribund until Rails).
> Ruby itself was effectively moribund until Rails
I think you might mean "unknown" rather than "moribund", but just in case: no it wasn't, it was quite successful, RAA wasn't CPAN but was quite rich, there were steady improvements to the language and the community outside japan was growing (i.e. most of the european ruby user groups started before ruby on rails). It was just growing slowly, rather than skyrocketing.
I think you might mean "unknown" rather than "moribund", but just in case: no it wasn't, it was quite successful, RAA wasn't CPAN but was quite rich, there were steady improvements to the language and the community outside japan was growing (i.e. most of the european ruby user groups started before ruby on rails). It was just growing slowly, rather than skyrocketing.
Online yes - but a hell of a lot of Tcl was being written too, by people who just couldn't be bothered posting about it.
Tcl was and still is undiscovered gold.
I'm very glad that only game writers are using Tcl for scripting their games. It's a godawful language I'd never want to maintain any real software in. Python and Ruby are bad, but Tcl is a degenerate joke. Let's please leave it undiscovered.
Tcl is the major scripting language used by all FPGA vendors, and sadly it doesn't look like it is going away. You can call Python from it, but FPGA developers (especially those Windows) will make a big fuss about installing an external tool, and should they install Python2 or Python3? Also, the major FPGA programming languages (vhdl and verilog) make tcl look great (or any other language, for that matter).
You may be pleased to learn that game developers do not use Tcl for scripting these days and, indeed, few ever have; see http://wiki.tcl.tk/40487. Their embedded language of choice is, by a large margin, Lua.
Sentiments like this please me greatly. Out of curiosity, what do you prefer?
One of the greatest proof of concept languages out there. Yes, please do not discover.
Anyone feeling that Python 3 is gonna do the same to Python as Perl 6 did to Perl?
Not at all. Unlike Perl 6, Python 3 1) exists 2) has a significant amount of library support and 3) is clearly intended to supplant Python 2. None of those points apply to Perl 6.
As someone who has been both a Perl and a Python programmer, I don't feel like Python3 is going to kill Python. Why?
- Python3 currently exists, and there is a large push to get the majority of the "big" packages to support it (many of which do currently support Python 2.x and Python3).
- It's possible for a Python package to support both Python 2.x and Python3 at the same time or to program the Python 2.x version in such a way that converters like 2to3 can do the conversion for you. I'm aware of no such tools or capabilities between Perl 5.x and Perl 6.
- Python3 isn't as ambitious as Perl 6 is/was.
Edit: As to point #2, I recall that there may have existed (maybe it still does?) some project to use Perl 6's "reprogram the grammar" capabilities to turn Perl 6 into Perl 5. I'm not sure how I really feel about that though. There was also a time when there was some buzz around Parrot VM[1] that was associated with Perl 6 (I don't know if it was some official partnership or just some announcement of Perl 6 support in Parrot).
[1] http://www.parrot.org/
- Python3 currently exists, and there is a large push to get the majority of the "big" packages to support it (many of which do currently support Python 2.x and Python3).
- It's possible for a Python package to support both Python 2.x and Python3 at the same time or to program the Python 2.x version in such a way that converters like 2to3 can do the conversion for you. I'm aware of no such tools or capabilities between Perl 5.x and Perl 6.
- Python3 isn't as ambitious as Perl 6 is/was.
Edit: As to point #2, I recall that there may have existed (maybe it still does?) some project to use Perl 6's "reprogram the grammar" capabilities to turn Perl 6 into Perl 5. I'm not sure how I really feel about that though. There was also a time when there was some buzz around Parrot VM[1] that was associated with Perl 6 (I don't know if it was some official partnership or just some announcement of Perl 6 support in Parrot).
[1] http://www.parrot.org/
Indeed, big libraries supporting Python 3 is rapidly growing http://py3readiness.org
Heck, apart from few - even those which are not supporting Py3k now have alternative package in PyPi. So it's positive sign.
Heck, apart from few - even those which are not supporting Py3k now have alternative package in PyPi. So it's positive sign.
it feels more like Python 3 is similar to the transition between PHP 4 and 5. Painful, sure but ultimately not a deterrent to language adoption.
I'm sad about this, I loved programming Perl a decade ago but the last side project I wrote in Perl was all the way back in 2010.
I'm sad about this, I loved programming Perl a decade ago but the last side project I wrote in Perl was all the way back in 2010.
I would think that the PHP4 -> PHP5 (relative) slow transition was more about hosting support than developer's adoption. Because of of the extreme (and often infuriating) stance on backward compatibility migrations were not that difficult : http://php.net/manual/en/migration5.incompatible.php
It was mostly new things, not different things. I don't even remember the new object model being that hard to pick from the PHP4 one. I think lots of developers got more stuck on the 5.2 -> 5.3 transition.
Isn't Python 2/3 more about libraries and compatibility than hosting ? My personal anecdote is that it deferred me way too long to learn the language seriously. I didn't want to waste time learning an old version but too much things were on it, especially Django and Flask (being mainly a webdev).
PHP7 vs Hack could mirror that though.
It was mostly new things, not different things. I don't even remember the new object model being that hard to pick from the PHP4 one. I think lots of developers got more stuck on the 5.2 -> 5.3 transition.
Isn't Python 2/3 more about libraries and compatibility than hosting ? My personal anecdote is that it deferred me way too long to learn the language seriously. I didn't want to waste time learning an old version but too much things were on it, especially Django and Flask (being mainly a webdev).
PHP7 vs Hack could mirror that though.
No. Python3 delivers concrete improvements on accepted problems with python2. Just the async io and encoding improvements with python 3 justify it. It continues the design spirit that drew devs to python.
When a loved platform stops evolving, as python2 has, there is this lovely period when it continues to be awesome, while requiring you to learn nothing new. Python is here now. But come the day that my new Linux distro links to 3 over 2, I will get organised to move.
When a loved platform stops evolving, as python2 has, there is this lovely period when it continues to be awesome, while requiring you to learn nothing new. Python is here now. But come the day that my new Linux distro links to 3 over 2, I will get organised to move.
No, it doesn't seem like the same issue at all. I used to use Python for most (production) things, between 2003 and 2008. Due to work, I more or less switched over to PHP and Java, and hadn't written any new Python in anger in years until a month ago. Despite all that, doing some simple stuff in Python 3 felt exactly like Python 2 always had. I'm sure that people who use it on the daily will notice and stumble against lots of differences, and porting large codebases is hardly ever fun, but it's fundamentally the same language.
I think it is cool to think of one's self as the hero in the story of their life. You battle adversaries, have little victories, complete long story arcs, find a sweetheart and have romance.
I feel Perl does not deserve to be mentioned in a hero's tale. There's been too much rankling and nincompoopery out of perl's characters given the size of that community. Far, FAR too much griping. Perl is a bummer, and that is why it did not win.
My philosophy is: live the life of a champion - overcome and be a shining light for others. Your war stories should be mostly glorious victories, no matter how mundane the battles or battlefields were.
I feel Perl does not deserve to be mentioned in a hero's tale. There's been too much rankling and nincompoopery out of perl's characters given the size of that community. Far, FAR too much griping. Perl is a bummer, and that is why it did not win.
My philosophy is: live the life of a champion - overcome and be a shining light for others. Your war stories should be mostly glorious victories, no matter how mundane the battles or battlefields were.
This is pretty good advice to live by. I should keep this in mind for myself.
You're both joking right? I find myself wanting to google this guy in 5 years so I can see how much real life kicks his poetic ass.
and I want to add, I am so looking forward to having this exact conversation 5, 10 and 20 years from now...
[deleted]
[deleted]
[deleted]
nothing to show for perl6? it's shipping in 2015.
I started on Perl 4 in the mid-1990s. It was fantastic! I started replacing thousand-line C programs with hundred-line Perl programs that were more robust and worked better, and replacing shell scripts made of awkward sed/awk pipelines with neat, tight Perl. Arrays and hashes as first class data structures? Marvelous!
Then Perl 5 ruined it all. The ridiculous, bloated "object oriented" syntax rendered it basically unreadable, without adding much useful functionality. The layers of syntax options forced teamwork-driven Perl (I wrote about 10k lines of it) to pay close attention to coding standards, closer than more consistent languages, just to not step on each other or have fights.
Then along came Python and Ruby, which shared most of the benefits of Perl (scripting, mostly), but added very clean, elegant OO syntax. Everyone who actually cared about writing decent OO scripts switched. Plus Python had much better math libs, and Ruby soon had Rails.
And Perl 6? Fourteen years and nothing to show for it, and it'll have to be backwards compatible to all the things violently wrong with Perl 5. There's no use case that isn't already covered by Python and Ruby. Unless some new technology comes along and Perl jumps in firstest with mostest (like Ruby did with Rails), no one will really care.
The average age of Perl programmers has been increasing by about one year per year since 2002 or so. I don't see that changing anytime soon.