Live data from Hacker News

Why Perl Didn't Win

outspeaking.com

51–60 of 187 posts

Re: Why Perl Didn't Win

#51
post #23

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…

> 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…

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

Re: Why Perl Didn't Win

#52
post #36
post #33

Earlier quoted context omitted.

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 su…

What can we learn from this? That we shouldn't attempt major changes that aren't backwards compatible?

Re: Why Perl Didn't Win

#53
post #20

You know what rocked? Perl 4. 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" s…

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!)

Re: Why Perl Didn't Win

#54
post #19

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

People forget that if one is forced to re-write the code, it might as well just use another language.

Re: Why Perl Didn't Win

#55
post #29

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.

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.

Re: Why Perl Didn't Win

#56
post #23

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…

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

Re: Why Perl Didn't Win

#57
post #51

Earlier quoted context omitted.

> 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…

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

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.

Re: Why Perl Didn't Win

#58

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 p…

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.

Re: Why Perl Didn't Win

#59
post #36
post #33

Earlier quoted context omitted.

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 su…

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.

Re: Why Perl Didn't Win

#60

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 ti…

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.

There are commits to Rakudo, a Perl 6 compiler, every day. It's also scheduled to be production ready by the end of 2015.
Post reply on HN