Why Perl Didn't Win

http://outspeaking.com/words-of-technology/why-perl-didnt-win.html

by aiurtourist • 12 years ago

178 183 12 years ago

outspeaking.com

pyre7• 12 years ago

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.

bmn_3• 12 years ago

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.

BuckRogers3• 12 years ago

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

pyre7• 12 years ago

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

BuckRogers3• 12 years ago

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.

duskwuff6• 12 years ago

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.

raiph6• 12 years ago

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

sago3• 12 years ago

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?

philwelch• 12 years ago

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.

angersock• 12 years ago

Yep. I've heard it put "Ruby is the best of Perl, without the rest of Perl".

McGlockenshire4• 12 years ago

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.

pdknsk• 12 years ago

I immediately knew it was Ultimate Bulletin Board when I read the first sentence of the second paragraph.

nostrademons2• 12 years ago

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.

richardbrevig• 12 years ago

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.

McGlockenshire4• 12 years ago

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

lsiebert• 12 years ago

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.

riobard• 12 years ago

Anyone feeling that Python 3 is gonna do the same to Python as Perl 6 did to Perl?

quanticle• 12 years ago

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.

pyre7• 12 years ago

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/

chhantyal• 12 years ago

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.

drac• 12 years ago

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.

conradfr• 12 years ago

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.

cturner2• 12 years ago

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.

randallsquared• 12 years ago

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.

sulam• 12 years ago

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.

nemo2• 12 years ago

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.

pjmlp6• 12 years ago

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

bad_user2• 12 years ago

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.

claystu• 12 years ago

What do you mean about Go? (And no...I'm not trying to pick a fight--just curious)

nailer2• 12 years ago

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.

nemo2• 12 years ago

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.

sago3• 12 years ago

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

pjmlp6• 12 years ago

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

ufmace• 12 years ago

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.

kamaal2• 12 years ago

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.

beat• 12 years ago

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

silvestrov2• 12 years ago

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)

riffraff3• 12 years ago

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.

aytekin• 12 years ago

Big rewrites = death

frik• 12 years ago

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

perlgeek4• 12 years ago

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.

chrisdone3• 12 years ago

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.

gaius3• 12 years ago

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

biomimic3• 12 years ago

Tcl is Fantastic.

sukilot2• 12 years ago

This sounds less like "perl 5" was a downgrade, and more like, "switching from sysadmin scripts to building enterprise projects (in ~2001-~2008 Amazon.com was written in Perl) made Perl less fun".

_paulc• 12 years ago

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.

b2gills2• 12 years ago

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)

duskwuff6• 12 years ago

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

proveanegative• 12 years ago

Is there an actively maintained fork of Perl 4 (or earlier) somewhere? Sounds like there should be.

perlgeek4• 12 years ago

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

razzmataz2• 12 years ago

The irony here, then, is that Perl 5 took the object system that Python had in 1995 as an example to emulate.

snarfy• 12 years ago

Even Duke Nukem Forever shipped before Perl 6.

mpdehaan2• 12 years ago

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.

kijin2• 12 years ago

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.

McGlockenshire4• 12 years ago

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.

kijin2• 12 years ago

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.

ars2• 12 years ago

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.

pjmlp6• 12 years ago

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

andreasvc4• 12 years ago

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.

jghf2• 12 years ago

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.

pjungwir• 12 years ago

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.

CodeWriter23• 12 years ago

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.

ugexe3• 12 years ago

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

lacker• 12 years ago

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.

Blackthorn• 12 years ago

Perl was dead long before Ruby on Rails was a big thing (Ruby itself was effectively moribund until Rails).

riffraff3• 12 years ago

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.

gaius3• 12 years ago

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.

biomimic3• 12 years ago

Tcl was and still is undiscovered gold.

EdSharkey• 12 years ago

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.

jnbiche• 12 years ago

This is pretty good advice to live by. I should keep this in mind for myself.

juliangregorian• 12 years ago

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.

etep• 12 years ago

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.

chrisdone3• 12 years ago

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.

inDigiNeous• 12 years ago

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!

mrbig4545• 12 years ago

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.

p0nce• 12 years ago

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.

Mithaldu2• 12 years ago

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.

not_kurt_godel• 12 years ago

No, he's right. Perl is shitty. Have you ever read a random Perl script? It's impossible to interpret.

pwr224• 12 years ago

Learning Perl is excellent for a beginner

pwr224• 12 years ago

https://gist.github.com/pwr22/c63c0e3f3309d0c95344

Walkman• 12 years ago

Previous thread: https://news.ycombinator.com/item?id=7866834

jimfuller2014• 12 years ago

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

jerf4• 12 years ago

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.

jrochkind12• 12 years ago

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.

tudorconstantin3• 12 years ago

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

chromatic3• 12 years ago

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?

tudorconstantin3• 12 years ago

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

unlinguaf• 12 years ago

nothing to show for perl6? it's shipping in 2015.

jjn10563• 12 years ago

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.

jjn10563• 12 years ago

and I want to add, I am so looking forward to having this exact conversation 5, 10 and 20 years from now...

Why Perl Didn't Win

Related Stories