Why Perl Didn't Win | Hacker News Reader

Why Perl Didn't Win

outspeaking.com

108 pointsnkurz152 comments

I was a Perl scripter (I never rose to the level of JAPH) from around 1998 to 2002, with my final accomplishment being a two-way HRIS synchronization system between our installation of peoplesoft and our LDAP server (Netscape LDAP server, awesome product).

And then I met Python, and I never wrote another line of Perl, and have written some python code almost every week since then.

There were two personal reasons why I left Perl.

First - I would write some code, it would do what I wanted, but then I would come back in a week (or even a few days) and have no idea how it worked. This is code that I wrote. Yes, I know this is a personal failing (I said these were personal reasons) - but, on the flipside, I've never had anything I've written in Python that I didn't completely understand how it worked any time in the future. Perl just let me write code that was too complex for my brain to comprehend. I blame implicit variables. [edit - and perhaps an over reliance on regex.]

Second, If I hadn't used them for a month or so, I used to struggle with Arrays of Hashes and Hashes of Arrays. Once I eyeballed my template, it all came back, but the syntax imposed enough cognitive overhead that I struggled with that data structure (which is one that you use a lot).

On the flip side - the very first day I was learning Python, I thought to myself, "What if I just drop an array (list) as an object in this hash (dict), or a dict in this list? Will this work?

And it did. Close to zero cognitive overhead.

So, that's why I left Perl - Readability and complexity of what should be bog simple data structures.

Will this work?...And it did. Close to zero cognitive overhead.

This notion of cognitive overhead (or any other kind of overhead) and how it scales (as programs get larger, applications get older, and/or systems become more interconnected) is really what's important to language and system design.

Yet most of what gets bandied about between programmers seems to involve what is nifty or what can save you some kind of overhead on mostly rather small scales. Even if a library or language feature can save you from typing another line of code 1200 times throughout a project, that doesn't necessarily mean it's a no-brainer. Ask yourself: What other kinds of costs are incurred? If your nifty doodad increases compile times by a factor of 10, or completely kills the cache across large parts of your application, or makes large swathes of the code hard to debug, it may not work out cost-benefit wise.

So, that's why I left Perl - Readability and complexity of what should be bog simple data structures.

Ironic in the Alanis sense, because one thing that drew me to Perl in the first place was the bog simple use of Dictionary, as compared to writing the same thing in C.

I felt much the same way, except in reverse - perl data structures did exactly what I meant, python data structures didn't.

I don't think this is a compliment or complaint about either, just a question of different people thinking different way.

I must admit that Perl's autovivification can be nice.

A consideration to you:

You spent 4 years of learning Perl, 4 years in which you likely also massively improved your skills as a programmer, regardless of the Perl angle. Then you went to Python, bringing in your programmer experience, probably started off with a good book and had a much happier time.

So, do challenge yourself and ponder how much of that come from having spent 4 years programming, and how much from actual differences in the languages?

It's an interesting perspective, but, seriously - for the life of me, I struggled every time I wanted to declare/parse/initialize an AoH or HoA on perl. And I'm not engaging in hyperbole when I said that my code was basically completely foreign to me a week after writing it.

Obviously developers (which I am not), and people with more discipline and structure, and write eminently readable and maintainable perl code - but as my day job was network engineering, I was just looking for the lowest cost path to get the job done.

I really did love CPAN though.

That's interesting, because defining an AoH or HoA in Perl is almost identical to how you would do it in Javascript, which is to say it looks a lot like JSON.

If it was the access and assignment semantics, the normal case is also fairly straightforward; use curly braces for hash/dict keys, square brackets for array indices.

E.g.

    my %data =  (
        foo => [
            { bar => 10, baz => 12 },
            { bar => 20, baz => 13 },
            { bar => 30, baz => 14 },
        ],
    );
    print $data{foo}[2]{bar}; # 30
    push $data{foo}, { bar => 40, baz => 15 };

Given, using array and hash references with the built-in push,pop,shift,unshift,keys,values and each used to require some annoying dereferencing that could be confusing.

Do you still find that confusing?

I'll admit to not having looked at it for about 12 years, and, of course, I'm not saying I couldn't figure out after 2-3 minutes over looking over the pattern, but it just never flowed the way it did with Python for me.

   data ={}
   data['foo']= [
      {'bar':10,'baz':12},
      {'bar':20,'baz':13},
      {'bar':30,'baz':14}
   ]
   print data['foo'][2]['bar']
   data['foo'].append({'bar':40,'baz':15})

   for x in data['foo']:
      print x['bar']

Maybe it had something to do with indices always being [] brackets and {} only being used to define the dict structure. Or maybe it got easier sometime in the last 12 years? Or, maybe you could onto something, and having come pre-primed with knowledge hashes/arrays, I just picked up python more quickly.

Anyways, it was just a personal story told as well as I could remember it.

Maintenance. I say this as somebody who loves Perl, quirks and all (actually because of the quirks). It's actually a beautiful language to work in in the same way English is a beautiful language -- it's a beauty because it's a goddamn mess. But it's a rotten language to maintain.

Sure, it's perfectly possible to write highly maintainable code (I have a few 30-40k line Perl projects that I can open up and get right to work on without too much fuss) and you can create some coding standards and stick to them, and write perfectly maintainable code. But Perl is a bit like C++ in the sense that everybody has different standards and those standards change and "non-standard" bits of the language start leaking into your code and you spend as much time unmessing things as you do writing code.

I don't think Perl will ever really die, it's too convenient, but it's definitely never going to enjoy the dominance it once had. It'll fall back to a very good one-off system admin and log processing language with some extra bits, but it's simply a language that the rest of the world has surpassed and Perl 6 just isn't a realistic offering, after a very loooong wait (nor does it fix the issues non-Perlers have with the language -- it's basically fan service).

I was recently asked to add some trivial code to the end of an existing unmaintained Perl script written long ago. Something along the lines of

  $x = `cat FOO 2>/dev/null`;
  if ($x == "foo") {
      system("BAR");
  }

When I tested it I found BAR was executed no matter what FOO contained without any errors or warnings. WTF? After a little more searching I found the problem was that I should have written

  $x = `cat FOO 2>/dev/null`;
  if ($x eq "foo") {
      system("BAR");
  }

I have absolutely no patience for this kind of crap, but I don't have time to replace the whole thing right now so I just suck it up and move on. I can understand how Perl may never die completely but I'm never going to use it for anything new.

This sort of distinction exists in other languages though: Java has == and equals. OCaml has = and == etc. (Not that Perl doesn't have its issues; but this is very low in that list imho)

Ahd in Common Lisp, EQ, EQL, EQUAL, and EQUALP. See http://www.nhplace.com/kent/PS/EQUAL.html for an explanation of why.

Mistakes from other languages are still mistakes.

One could try to call them tradeoffs rather than mistakes, but then you'd have to explain why the programmer benefits from such circuitous thinking.

I don't think that one is a mistake. At least, if it's a mistake, it's not a mistake in the equals operator. PHP attempted to use one set of comparison operators and the fallout has been far worse: there have been security problems due to the semantics of PHP's == operator attempting to guess whether to perform string or numeric comparison when doing password comparisons.

The mistake, if any, is that numbers and strings are unified into one scalar type in Perl. This allows some tricks, such as being able to use sprintf to perform rounding, but it has fallout in other places in the language, such as here. Given that numbers and strings are unified, having two operators for comparison is the correct decision: it makes the semantics much simpler by having the language not guess which kind of comparison to perform.

They're not mistakes; read the article. "Equality" is not the singular, unambiguous concept that many programmers think it is.

But in those languages, the equivalent to ($x == "foo") will return false (almost) all of the time. The poster here says that this expression is true (almost) all of the time in Perl. Why?

But what is $x? Integer? String? Character? Some_Object?

How do you evaluate this, depends on the context. Wasn't that the whole point of a dynamic language anyway?

After learning Haskell, I'm not sure what the benefits of dynamic typing are anymore.

No, not at all. Type coercion is orthogonal to type safety.

Amen, brother! I call this "weak typing". But some others use weak typing to mean different things (like "unsafe typing") [1].

Javascript, PHP and Perl are weakly typed. Smalltalk, Lisp, Python, Ruby... are strong typed. But all of them are dynamic.

[1] http://en.wikipedia.org/wiki/Strong_and_weak_typing#Predicta...

I love dynamic languages with strong typing. You get most of the dev time developments, but without the inherent subtle bugs that creep in via automatic type coercion.

Because if you disable warnings, it silently coerces 'foo' to 0.

This is why disciplined (i.e. non-tiny-script-y) perl code starts off with

    use strict;
    use warnings;

just like disciplined javascript starts off with

    /* use strict */

and disciplined C code enables compiler warnings, and truly disciplined C code makes those fatal, just like in perl you can do

    use warnings FATAL => 'all';

If you don't do that, then you get the short script/one liner style behaviour where, just like sed, awk or bash, it assumes you know what you're doing. If you don't, then you should be asking the VM to help tell you when those problems exist, same as 'set -x' in bash is incredibly useful if you don't plan to add '|| exit 255;' onto the end of every command.

I've been writing perl for over ten years. I think I learned to stick "use strict; use warnings;" at the top of my scripts on day number 1. God only knows why so many other Perl programmers never learnt this.

Those languages are far more maintainable and their communities have far more respect for practices which prevent programming errors.

I don't particularly care how many forms of equality or comparison a language has as long as the compiler or runtime is capable of telling me the particular one I'm using is probably wrong. If == can't be used with strings the damn interpreter should tell me so instead of silently and improperly coercing the arguments.

You should have used strict and warnings. RTFM, I know.

Btw, Java will silently compare references instead of value. Learning a language != increasing vocabulary.

Tell me about it. At least Python can make the difference between equality and identity, while a non-overriden equals() in Java actually means "is X Y?" instead of "is X equal to Y?".

The interpreter does tell you.

    $ perl -e 'use warnings; use strict; print "content" == "foo", "\n"'
    Argument "foo" isn't numeric in numeric eq (==) at -e line 1.
    Argument "content" isn't numeric in numeric eq (==) at -e line 1.
    1

Thanks - I'll try to remember that if I ever have to touch perl again.

That is not what perl and bash do. They distinguish between "comparing as strings" and "comparing as numbers". For example, the strings "03" and "3" are different, but as numbers, they are equal (and, I guess "010" is equal to "8", numerically. I didn't try, because I don't want to know)

For bash, read http://unix.stackexchange.com/questions/16109/bash-double-eq... (especially http://unix.stackexchange.com/a/120235) and weep.

For perl, see for example http://www.perlmonks.org/?node_id=276023

I guess you've never written any bash either, wherein the exact same problem exists except that == and eq are the other way around, for reasons I can't quite remember.

Plus, of course, if you'd enabled perl's warnings system, via 'use warnings;', it would have complained at the use of == on a non-numeric value.

If you don't enable the compiler features that catch problems, then, yes, you can run into problems. Welcome to programming.

Edited to add: I got downvoted within five minutes. If you disagree that my bash analogy is inaccurate, I'd love to hear why.

I did not downvote you, but comparing a language to Bash is certainly in no way flattering, and I would definitely not put it in the "good defense analogy" category.

Comparing a final conditional in a systems-style script that is then calling another program, shell-style, to bash, which is the most common language where you'd execute a conditional then call another program, seems reasonable.

Maybe not flattering, maybe not a good defense, but I think under the circumstances an acceptable comparison.

Thanks for the 'use warnings;' suggestion.

Keep in mind the subject here is maintainence - where small changes with minimal impact to production is the rule and the work is often done by programmers with incomplete knowledge and no patience for explanations. For maintenance you want KISS, not TMTOWTDI.

I'm no big fan of bash but at least bash gets the common case right here without any special settings. For example, if I use -eq instead of == and write

  #!/bin/bash                                                                     
  x=`cat FOO 2>/dev/null`
  if [ $x -eq 'bar' ]; then
    echo baz
  fi

as you imply, bash won't be silent. It will say

  bash-3.2$ ./example.sh 
  ./example.sh: line 3: [: bar: integer expression expected

Equally, bash requires 'set -x' to not ignore errors.

In both cases, the reasoning is significantly to do with backcompat, I believe.

So, yeah, things that have been around a long time often require a setting to be safe in cases that we, ten or twenty or whatever years on, consider common.

Also: I did keep that in mind. That's why I started off suggesting using warnings, rather than (as I normally do for new code) making them fatal :)

Sane defaults are a cornerstone of good language and framework design because for better or worse people don't read the manual before they start using something. If a compiler doesn't do the right thing by default (throwing errors on problems a new user is likely to cause), it's a bad compiler.

What sane defaults are will change over the years.

Perl kept amazing backwards compatibility by adding extra statements to modify how it worked. So "use strict;", "use warnings;" and "use <other_newer_perl_features>;".

Both new code -- using the best OO system of the scripting languages, extendable syntax, etc, etc -- will run at the same time as most of the old and crufty stuff from before testing took over after the Millennium.

Lines that can affect the global behavior of the program are a mixed blessing.

It would have been bad, if the design had been stupid enough to not make declarations file/package based... :-)

""non-standard" bits of the language start leaking into your code"

I work on a small team (C++), so this has never been an issue. If you break coding guidelines someone will notice and let you know.

But this really should be integrated into work-flows. (ie/ into Gitlab, Jira, etc.) There should be some kind of step - before you are allowed to merge code - that checks that you are withing coding guidelines.

Yes, those are called linters: http://en.wikipedia.org/wiki/Lint_%28software%29

Thank you very much for showing me this. I'll definitely look into it.

Learning something new every day =)

> But it's a rotten language to maintain.

I've been diving into some of our legacy Perl and man, the learning curve of the various sigils and implicit variables. Even working with collections was challenging.

I'm working to make it better Perl (I have a copy of Modern Perl on my desk), but that's solely to make it understandable so that we can rewrite it / replace it with something like Salt.

If it's seriously legacy code ... then I'd completely support you rewriting it, and I'd rather see it rewritten as not-perl than left as bad perl, no matter how much I personally do like perl.

This is why I'm glad we're not the 'most popular thing' anymore, these days the same quality of people are producing similarly awful code in node.js and go, and I feel sorry for those languages' communities because of it.

> If it's seriously legacy code ...

Well, I'm removing globally scoped maps shared across several modules and about 6000 lines of code. To be fair to the original author though, he was learning Perl as he went along, and when he learned about references he started using them in new code.

If you don't enjoy Perl code that looks like a cartoonish string of censored profanities, you could always try including 'use English' in your program, which aliases more descriptive names to all those punctuation-mark special variables. See here: http://perldoc.perl.org/English.html

I don't want the popularity we once had.

The same people who wrote unreadable, unmaintainable perl went on to do the same sort of damage in PHP, then python, then ruby/rails, and now node.js/go. They were never a net positive to the community, and I'm not sorry to see them causing problems for somebody else.

(and before somebody says "but that doesn't happen in X" ... yes, it does, even python lets you write code that looks superficially comprehensible but turns out to be so horribly illogical structurally that it's impossible to maintain - I quite like python but I've been there and I was kinda scared because at least wrong perl looks wrong to start with, whereas wrong python looks fine until you realise just how much of a crawling horror it is)

> before somebody says "but that doesn't happen in X" ... yes, it does, even python lets you write code that looks superficially comprehensible but turns out to be so horribly illogical structurally that it's impossible to maintain

It does happen, but due to the design of Python / Ruby / Javascript, it's a lot harder to make happen especially when you use a framework.

As a former Perl dev, unless someone maintains god-like discipline over a Perl code-base; it's a lot easier to come up with unmaintainable spaghetti, that no one save for the original developer fully understands how it works, than it is in other competing languages.

I was thinking the same thing. Didn't say anything because I didn't want to be rude to the "lets cut and paste code from google searches" coders...

If someone really wants to use a language, there is no excuse for not reading a book for that language first.

And when it comes to a "book for that language", Programming Perl really does take the cake.

With python is not the same. Even if the developers is truly bad and do a mess, is a decipherable mess. Requiere truly talent to do a hard-to-understand mess in python, and in that case, is very likely the code was made by a good developer ;)

> Requiere truly talent to do a hard-to-understand mess in python, and in that case, is very likely the code was made by a good developer ;)

Last I checked, the whole "if it was hard for me to write, it should be hard for others to understand" was still a mockery, not a seriously-interpreted excuse. It ignores the fact that the programmer's future self will eventually need to maintain that code. The developer might have skill, but one who writes unmaintainable messes as anything other than a Perl-golf-style mental exercise probably lacks wisdom. :)

Could provide a example on python of non-intentional bad code, like the kind that could be write by a perl coder, that make them not understand it a week later?

Because that is the issue I was talking about is rare in python. Is true that is possible to write bad in any language, but certainly is harder in some of them

Articles which critique Perl as a whole by focusing on Perl 6 always strike me as a bit strange. As someone who works professionally with Perl every day, and starts several new projects using Moose-centric modern Perl techniques every year, the amount of time I or any of my colleagues spend thinking about Perl 6 is negligible.

The modern Perl movement, as far as I can tell, arose in part from Perl hackers who started to treat the wandering Perl 6 project — rife with neat ideas, if not with release engineering — as a skunkworks for Perl 5 extensions. In the gap between the middle-aughts and 2014 that this writer waves away with “is anyone still paying attention?” due to no Perl 6 release, the active Perl world adopted Moose, and many Perl-based Moose-driven technologies — Catalyst, DBIC, and so on.

These technologies, and the communities around them, have thrived on their own ever since. Nowadays when I think about Perl 6, it is often because I am at a Perl conference and Larry Wall is literally at the podium talking about it and I am like “Well. You go, Larry Wall.”

Perl really has reinvented itself in the last handful of years, at least in the eyes of those who make a living inventing new things with it. I can’t call this writer wrong — their perspective is their own. I suppose I can only learn to appreciate the notion that, to hackerly folks who aren’t as ensconced within the modern Perl community as I, the language is this thing from the 1990s that kicked the bucket through one bad decision in the summer of 2000, leaving behind acres of legacy code that’s still being scraped away.

To be fair: this indeed describes a lot of what I am hired to do. It’s just that I replace it all with newer and better Perl…

Perl is sort of like trying to read someone else's brain (in this case Larry Wall's). You get themes and kind of the gist of where it's going, but it never quite adds up to some sort of coherent whole.

The defense has always been that Perl is designed more like natural language than programming language, ok, but: natural languages are a LOT harder to learn than programming languages. Put me in a room with Haskell and I'll learn it in a month. Give me a month of training in french and I'll maybe be able to not make an entire ass of myself if I try to get from point A to point B. Human languages are hard. Design wise -- I'm not sure that's what you want to aim for.

Almost everything you learn is... surprising. Like flattening lists. Useful in a context, maybe, but is that the kind of thing anyone would ever expect? And why is "list" (@) part of the variable name in the first place? It's like "dynamically typed, kind of, except your variable name has to say if it's one thing or many things or many things referenced with keys". What the fuck? I'd rather the python way of "it's a name that points to a thing, whatever that thing is". GOT IT. Simple.

I program in C++ for a living, probably the biggest clusterF of a language ever devised (outside of perl), and the thought of reading Perl still terrifies me.

> Put me in a room with Haskell and I'll learn it in a month. Give me a month of training in french and I'll maybe be able to not make an entire ass of myself if I try to get from point A to point B. Human languages are hard.

To be fair, I don't think this is actually because human languages are all that hard to become competent (note: not fluent) in. It's just that with computer languages you have an endlessly patient practice partner to work with. In particular, I think the complexity of competent Haskell is definitely higher than most spoken languages.

The idea behind Perl being designed akin to a natural language isn't for its ease of learning, per se, but for its ease of expressiveness. English is probably significantly harder to learn than Python, for example, yet it's likely much easier to write a novel in the former than it is to write one in the latter.

The same things could be argued as for why, why C didn't win, or C++ didn't win, or even really PASCAL/Smalltalk/Lisp didn't win. "Winning" is temporary and not the end goal of any language and is best left to be declared by Charlie Sheen like pundits trying to demonstrate their language bigotry.

Is Perl the first tool that some of us think of when solving a problem? It might not be for you but it is frequently for me. Ruby might be your first choice, and really that's fine.

You're not a lesser or better programmer than anyone else if you choose something besides Perl either. Honestly, if you can solve the problems that you need to solve and you can work with your team, that's the only thing that matters. Not that you're using some language that isn't "winning".

As for Perl not having support for recent things like Stripe, that's just silly to argue (the author really should have searched the CPAN). Perl has many new modules, Dancer, Catalyst, Moose, Plack, Starman, Net::Stripe (maintained by me), and full support of AWS's offerings. And, yes modules written in 1999 do get used today, just look at all of LWP.

"Winning" isn't everything. Admittedly, Perl 6 isn't out or even moving forward visibly but doesn't mean that the language is irrelevant. Just watch https://metacpan.org/recent to see the pulse of the community and the new modules released and updated daily.

If this article had been written about natural languages, it might be called "Why French didn't win". It may not be the world's most popular language, but it's extremely useful to a lot of people.

Winning isn't everything. :)

> You need large absolute numbers of users to grow a library. That's why library ecosystems like that of Python, Ruby, and Node.js have grown large in recent years.

Thats where the author missed an important point. None of those library archives have the culture of PAUSE+CPAN to constrain a minimal code quality when it comes to configuration, documentation, regression test and installation. This minimal code quality is constrained by CPAN testers, when a module hits PAUSE, before the module is seen by the unwashed masses who access CPAN.

I've seen many library archives of other languages, but they are all full of junk, undocumented junk, untested junk, and junk that does not configure or install everywhere. The worst example was the LuaRocks system. The quality of the libraries in the Rocks archive had been so bad, that the church decided to remove the module keyword from Lua language, to get rid of this junk. But the code I see for Ruby/Rails, NPM/Node, or PyPy/Python is junk compared to even those Perl modules, that barely managed to convince CPAN testers.

You not only need the absolute numbers, but important you need a core group starting the ecosystem who constrain a coding culture. Raw numbers are not enough. A million apes wont write a Shakespeare novel.

I have pretty mixed feelings on this... I feel that there are more than a few great uses of modules in npm that would never fly in cpan. My biggest issue with node today is that it still relies on python 2.7 for many binary modules.

I have been so very burned by CPAN module quality in the past. Claims to CPAN 'minimal code quality' ring hollow with me. Apache's collection of Java code is MUCH higher quality on average.

To be fair, CPAN is also full of junk. And Acme::* :)

I suspect that all the languages that are "winning" right now will have "lost" 10-20 years from now too.

What's the longest lived language out there right now that's actually still in heavy use? I'd say C. But C has clearly fallen from its position of complete dominance when every new project was written in C (because it was much easier than writing assembly).

C++ had its day as well and lives on in many places, but again, it's no longer the go to language for projects where C isn't the right choice.

How about Java? It was hot stuff in the 90s and it's still huge today, but it clearly didn't "win".

PHP? We'll be living with legacy PHP code bases for at least 10-20 years but does anyone honestly think this will be the language that the startups of 2025 use?

Programming is both incredibly faddish and incredibly fast paced. Today's new hotness is tomorrow's "dead" language.

Give it 5-10 years and I expect to read "Why Python Didn't Win". I expect we'll see a "Why Ruby Didn't Win" in 10-15 years too.

I agree with your point but not the scare quotes. Yes, the field evolves, priorities change, and languages inevitably fall out of favor. However, that losing is inevitable doesn't make the losing less real, and I think it's still very useful to think about why a language fell out of favor. What changes in priority left the language behind? What could have made it more adaptive? What does that say about current programming trends? In 2020, we may well have a "Why Python Didn't Win" article, and I'll really want to read it.

>>What changes in priority left the language behind?

I'm not an expert but let me try. The most common of all is abstraction level at which problems are looked increase with time. Once the problems you solve get complicated increasingly over time, you run into a situation where your tools have to provide syntax and semantics to deal with that. While the previous complicated things get trivial and easier to deal with.

There fore your language has to evolve/grow. This is a double edged sword. If you wish to move ahead and break backwards compatibility to do this, you risk fragmenting the whole ecosystem for very little real benefit(Python 2 - 3 problem). You can keep two system in parallel, plan to support the existing for as long as you can while you work on the new stuff(The Perl 6 Problem). Large changes are difficult to make. Or just stay stagnant and become irrelevant(History if full of such languages). Java is rapidly becoming one such language. Its old, trivial things demand too much code and improvements look like bloat.

In the mean while newer languages which have a clean slate to start with come around and stick for a while. Eventually they must face the same problems.

Have you used Java recently? The last few versions are showing consistent improvement with lambas, date library etc. I can't think of this happening successfully in other languages but it seems to be working well in Java. Also JavaEE and Spring framework have improved massively and the amount of code (and configuration) to do stuff is reducing all the time - much more in the style of rails/django.

I think Java (and C#) will be here for a long while where the enterprise jobs are. Javascript will continue to be popular as long as it's the only real choice in the browser. After that - who knows?

Perl is actually no different. There are a lot of cool things happening in the Perl universe too. But the problem is, the older issues persist. There is a big legacy baggage to carry, and in the overalls the feature adoption is generally slow.

So maybe winning is more like winning for a time period. PERL did win. It won up until early 2000s, then lost. I am guessing it is not getting picked much for new, greenfield projects. I think that is a cut-off metric. One way get there is to find a niche. Maybe it isn't the new use-for-everything language. But at least can become the "ok, use for this one area" language.

C -- still winning in that respect. It is used in many places just because of hardware or time constraints -- drivers, micro-controllers, optimized fast parses, low level socket handling code. It just got specialized. Not used probably for business or back-end systems.

I don't think PERL can claim that same. It seems to me its role has been replaced by Python, maybe Ruby, Java (for web server back-ends).

C++ still winning. None of the current languages including the new contenders like Rust and Go can eat its lunch (as they say) when it comes to performance. Things like games or signal processing. Anything requiring low latency responses will still see C++ being picked. And with C++11 and C++14 it is getting a new breath of fresh air. Whoever is going to contend with, will have a steep hill to climb.

Java? Java still winning. Now if you think of Java as JVM it is winning even more. Java itself if just a very average language that is also fairly performant, explicit, IDE friendly. If you had a lot of money and could hire potentially lots of average or below average programmers to throw at a problem (which I think often is the wrong approach, but if you did), Java is your language. And Android. Don't forget Android. If anything it is winning just because of that.

> Give it 5-10 years and I expect to read "Why Python Didn't Win". I expect we'll see a "Why Ruby Didn't Win" in 10-15 years too.

I think it replaced PERL by in large and but now it is feeling the heat in a lot of areas where it was being used. Scientific community has Julia as a new kid. Server back-ends have Go and Javascript. Not one big threat but little paper cuts here and there.

Ruby, I am not familiar with it much, from my outside perspective it looks like a one-trick-pony = Rails. If something replaces or obsoletes Rails, I don't see Ruby rising and finding a niche. I could be wrong, so anyone please correct me here.

I think the definition of 'winning' people use around here is, if start ups think its a trendy technology to use. So you will see all these new companies stop using a particular language, and then when some conference happens you will see talks around the older technologies have dried out, while people are giving talks on the newer set of technologies.

Its then when you see articles/rants/blog posts on the lines 'Whatever happened to X which was famous $current_years - 5 years back?'

Please note all the focus is around the new technology. Some one is writing a new library around this new DB technology some one is using and is writing about it. Some one just gave a talk on how some scalability problem was solved by a specific feature in the language. Some one just talked about how testing got easier, some one writes about how maintenance efforts got reduced because of a new way in which language deals with type declarations, Or some programming forum is full of questions and the Google auto suggests can tell you your question as you are typing it.

Meanwhile some where in a MegaCorp, your maven can't see beyond the company in house repo. And using a different library takes 3 months of permission cycles. People sitting in there don't get interview calls and hear about people saying that the old technology isn't hip any more.

Only thing that is buying Java some time is the large quantities of enterprise code, which no one has the money to replace.

> ...and then when some conference happens you will see talks around the older technologies have dried out...

So I must live in another planet as the European Java (Devoxx, Jax,...) and C++ conferences keep getting fully booked.

NDC 2014 just had a record count of C++ talks.

Can you fix the bug in "$current_years - 5 years back", please - it's bothering me. If you're going to talk in code, at least get it right ;-)

Oh, come on downvoter - I put a ";-)" at the end of that. There's literally zero tolerance for anything lighthearted here, isn't there?

One might even say that Fortran is still winning!

I gave up on perl when I saw the following code:

$x = $src[$src];

I was confused as hell until I realized that arrays and scalars had different namespaces. That, along with the fact that "or" and || had different precedences were what ended Perl for me. I'm not saying that wonderful code can't be written by Perl, it just wasn't the right language for me in that I hate memorizing one-off rules, which Perl seemed to have plenty of, instead of a language that was more internally consistent.

IIRC, 'or' and || have different precedences in other languages, too - PHP, for example.

If you only want a single namespace for everything, I recommend sticking to only scheme (note: I really love scheme for that property, I'm not being sarcastic).

Once you learn -enough- perl, there's a sort of overall consistency that's actually really nice, but there's a gap ... simple perl is very simple, but mid-level perl is generally a mess until you get to the expert level, and then its awesome again.

There's probably an analogy to text editors here.

I couldn't agree more, and that's why I hate perl.

That gap in the middle makes it really hard to hire perl developers unless they are experts. It's hard to find experts because they think perl code is a mess before they get there.

It's probably the main failing of perl.

Perl lost because PHP took its place on the web development front.

Perl lost because Python/Ruby took its place on admin front.

Perl lost because the new version took forever to get ready and broke compatibility with the old code.

1. True

2. Linux Admin? maybe. UNIX admin? I'd say Perl still on, as it's installed by default (yeah not popular anymore, but a LOT of legacy system still run)

3. cannot comment, as never used new Perl, since UNIX still shipped with old-ish Perl

maybe, just maybe it's not just winning & losing :D every language will find it's place eventually.

On 2: Still 193 unique files in /usr/bin on my system containing the string '/usr/bin/perl'. Only 51 containing '/usr/bin/python'.

are you saying python is more efficient? :P

I have two programming tattoos: a Perl camel and a Ruby ruby. That basically tells the story of why Perl didn't win for me: As soon as I started learning Ruby, I thought, "Oh, a cleaned-up Perl" and never really wrote any Perl code again.

I love Perl's personality, its quirkiness, and its massive amount of libraries. Perl was _massively_ influential on me as a young programmer. But I'm pretty sure that I won't be writing any Perl ever again.

Exactly. Perl 6 was forever delayed, and along came Ruby. Or rather, out from the shadows came Ruby, which was already there before the Perl 6 debacle, and just needed promotion. The Pragmatic Programmer books were pretty good at pointing to this cool replacement for Perl that you never knew was already there (as well as all the buzz from the RoR folks for those of us who weren't in on the beginning)

I don't really think that the people who left perl all went to PHP.

Now if only there was a "Ruby lite" that ran more like Perl 5 (skipping the GC for reference counting and a few other performance shortcuts)

I'm wondering if Swift will fill that role, eventually.

I hope so. That is, I hope there is a version of Swift outside of Apple-land (Clang compiler for LLVM extension???). What little bit I have seen so far looks promising, and it has a significant sponsor to get the language going.

ruby is awesome until I want OO ... then I get about an hour in and find that I've got to write 5x as much boilerplate as I would under Moose/Moo, and there's no proper trait/role system, and then I get annoyed and go back to perl.

If ruby had OO as good as Moose, I'd seriously consider switching. Sadly the projects to port Moose to ruby never seem to get finished.

Moose came out five or six years after I made the move, so I'm not super familiar. Can you expand on some of this? I very, very rarely need 'boilerplate' in Ruby...

Two examples. Note that I'm going to write the boilerplate-ish version in perl as well, because I think it'll be equivalent and that's probably more likely than not screwing up the ruby code. Please correct me if it isn't equivalent.

Most of my object attributes look like one of -

    has foo => (is => 'ro', required => 1);
    has bar => (is => 'lazy', builder => sub { Some::Logic::here() });

which translates through to, in old-school perl style,

    sub new {
      my ($class, $args) = @_;
      my $new = bless({}, $class);
      $new->_init($args);
      return $new;
    }

    sub _init {
      my ($new, $args) = @_;
      die "foo is required" unless exists $args->{foo};
      $new->{foo} = $args->{foo};
      if (exists $args->{bar}) {
        $new->{bar} = $args->{bar};
      }
    }

    sub foo { $_[0]->{foo} }
    sub bar {
      my ($self) = @_;
      unless (exists $self->{bar}) {
        $self->{bar} = $self->_build_bar;
      }
      return $self->{bar}
    }

    sub _build_bar {
      Some::Logic::here();
    }

So far as I'm aware, ruby provides 'attr_reader' which would generate the 'foo' method for me, and of course the above 'new' is built-in.

However, again so far as I'm aware, I'd still have to write the bar() lazy/build accessor, and an initialize() method to do the equivalent of '_init' - and name _build_bar by hand, which is less of a big deal but turns out to be really quite nice.

Plus I'm unaware of any ruby equivalent for the Class::Method::Modifiers CPAN module, although I'd imagine that's pretty easy to write and wouldn't be surprised if there's a gem somewhere that I've missed.

In fact, there's a MooseX gem that brings some of this syntax to ruby already, which suggests that it isn't already there anywhere else or at least that that gem's author didn't find it either; next time I play with ruby I intend to do so with the assistance of said gem and maybe that'll solve my problem, but I'm open to being told I'm doing it completely wrong - this isn't me harshing on ruby so much as complaining that an otherwise rather pretty language isn't something I can enjoy writing and I'd like to fix that.

First of all, thank you so much for writing this out.

> I'd still have to write the bar() lazy/build accessor,

Yes, in Plain Ruby

> and an initialize() method to do the equivalent of '_init' - and name _build_bar by hand,

There's a 'trick' involving Struct that some people use to handle this. If you asked Rubyists, they'd probably say 50/50: http://blog.steveklabnik.com/posts/2012-09-01-random-ruby-tr...

> I'm unaware of any ruby equivalent for the Class::Method::Modifiers CPAN module,

Rails offers this in controllers as {before,after,around}_action, and actions are just methods. You'd have to write it yourself, though, you're right, or use a gem.

> I'm open to being told I'm doing it completely wrong

Naw, though I will say that I very rarely need to do things like this, or when I do, the boilerplate doesn't bother me enough to justify the metaprogramming required to do it in a mega generic way. :)

The Struct thing is neat except that I really, really, really hate positional constructor parameters as opposed to named.

Plus it misses out the whole "I can have required and optional parameters and it just works" part of what I was showing you.

> Naw, though I will say that I very rarely need to do things like this, or when I do, the boilerplate doesn't bother me enough to justify the metaprogramming required to do it in a mega generic way.

Right. Thing is ... you know how people often say "I didn't really find perl that kludgy until I used ruby for a while, and then going back to perl was heinous"? After a couple of years of using Moose, I found going back to anything that couldn't do all of that easily to be heinous.

The last time somebody I knew who writes both perl and ruby tried to port some of my perl code to ruby, they ended up with 3x or 4x as much code per class because I lean more heavily on this stuff than you'd think if you weren't already using it, and got bored about three classes in and decided to wait for somebody to port Moo/Moose to ruby before trying again.

Which is a shame, because I was really hoping they'd finish, stare at the boilerplate, and then find a more rubyish way of writing the whole thing that made it not have boilerplate ... but the fun ran out before any of it ran.

The thing is, my gut feeling is that rubyists probably design their classes -just- differently enough to me that they don't need what they don't have, but I can't figure out how to devise an experiment to figure that out.

If you come up with such an idea, I'd love to hear it, since some sort of comparison that shows how the idioms fall out differently in the two languages would be really nice, but I can't think of one that wouldn't be either trivial or more work than its worth.

Thanks for responding; it's really quite pleasant to have this sort of conversation without getting derailed into language wars :)

> Right. Thing is ...

Absolutely. :)

> I can't think of one that wouldn't be either trivial or more work than its worth.

This is the hardest part about finding examples.

> Thanks for responding; it's really quite pleasant to have this sort of conversation without getting derailed into language wars :)

Agreed. Thank _you_!

I got introduced to Perl in 2006, at a time when trolls were screaming 'Perl is dead' from top of the buildings. Perl was revolutionary to some one like me who had only done C and assembly language programming. And it turned to be a great tool for the job back then(Processing massive unstructured text files). Its still unbeatable in that area.

Back then I saw that people who worked around enterprise projects that used some kind of a relational database used a lot of Java. People who were jumping to the Web 2.0 Bandwagon, used stuff like Python and Ruby largely because of the frameworks. Thereby what's really apparent is tools that are best suited for the job get traction.

Perl is still unmatched for many things. Unixy things like dealing with large quantities of text. Gluing things together, getting stuff done quickly etc etc.

Perl's every day use cases were going way, as database and web heavy things ruled the business scenarios. Perl largely occupied a niche and ruled it. So is Python today(Web frameworks), and ruby. Also Perl reached a very high peak in the 90's. And reaching that kind of level again isn't possible unless Perl does some very new and paradigm changing.

Perl 6 is kind off believed will do that eventually some day. But from what I last heard a few day back in this very forum, there are not close to anything serious even in another 2 years from now.

Articles like this make me sad. Perl is a mature, well supported language with a thriving community. It is not in maintenance mode, a new version has come out every year for the last 4 or five years, all with new features, many more planned. Plus the perl conference attendance has been up every year for the last few years. http://www.yapcna.org

You say I should use something more modern? Are not all languages based off of methodologies from 1950?

And which one of these modern languages do I choose? Rust, Go, Python, Ruby, Java, JavaScript, node.js, coffee, dart, swift, C#, F#, Scala...

Probably many more that I missed but my head already spins. If anyone says they know more than 2 of those languages, then they only know them poorly.

I get tired of some new language coming out every year, along with a new community of trolls to bash everything and tell me I need to drop everything I already know to learn their new mess.

I must say, none of these languages that are in the news impress me. Yet there are many perl modules that do impress me.

I enjoy perl and its community. I like that it is not coupled with any huge corporate sponsorship. It is the bazaar in "The Cathedral and the Bazaar" and that I like.

The final section, which I was anticipating for the whole article, was essentially this:

http://en.wikipedia.org/wiki/Osborne_effect

What killed Perl? An imaginary Perl did.

>> What Killed Perl?

The article is entitled "Why Perl Didn't Win", not "Why Perl is Dead". Perl hasn't been killed.

It's dead to me.

I think there's some good points in this article - and I relate to it, 'cause this is exactly how I learned Perl.

The one other item that I'll add is that some of the characteristics that make Perl awesome for sysadmins, like extremely flexible syntax and the ability to freely access data sturctures in a variety of contexts, can make it more difficult to build proper software development projects.

Maybe it's just my limited experience, but it seems like Perl organizations spend a lot more time on mandating coding styles and debating best practices compared with more structured languages like Ruby or Python.

But as was mentioned in another comment, what you mention as a key appeal for sysadmins is exactly why I can't stand perl. In particular "extremely flexible syntax" makes taking over the sysadmin job from another person, or joining a team, a ridiculous amount of effort. I can't begin to tally the number of hours I've spent with perl code open in one window, and a web browser open to various different perl guides, the documentation, etc. trying to figure out what tricks some script is using that makes it completely incomprehensible to me.

Is it fun? Sometimes, except never when a key service is down and you have users breathing down your neck. Or your website is down. Or really, trying to do any kind of maintenance work. And guess what happens? More crazy patches, probably written in an entirely different style! So now there are $n+1$ different styles in that script, and my successor is going to be even more frustrated with me than I am with my predecessors.

On the flip side, it's been a great education on the difference between maintaining code for your own use and code in an organization...

How does a language win? By being compelling enough to be used for new things. It's not solely a technical concern; it's a concern of the language community and ecosystem.

One of the most valuable 4 sentence paragraphs I've read from an HN post in awhile. (Perhaps 3, but the semicolon really separates 2 sentences.)

The semicolon separates two independent clauses, but they constitute a single sentence.

When we're thinking about language, clauses are probably a better atomic unit than sentences; clauses are a semantic unit, and sentences are really just a syntactic packaging format for some number of clauses. Just like we should be counting expressions (or something) rather than lines of code.

I'll take that comment as a parody?

Sure, whatever you like.

Well played!

As a Perl and Modern/PBP fan, I have to suggest that CPAN has become a poorer resource over time:

>In the olden days, you could expect to find a Perl module for most anything you wanted to do

but also:

Having 57 modules all called Sort will not make life easy for anyone (though having 23 called Sort::Quick is only marginally better

and it seems that every time I look for a useful module on CPAN I find myself in a twisty little maze of packages, all different.

TIMTOWTDI, yes, but which one (or several) of the available modules will have a usable combination of convenient utility and mutual compatibility? Over time, CPAN has started to feel like the house of someone who rescues animals, but cannot let go of any of them.

There are a few things to consider when trying to pick a good/the best module for a problem.

- ask in irc.perl.org. it is very likely to get pointers from very experienced people.

- use metacpan.org and pay attention to the votes/likes it got. and read the reviews.

- each and every CPAN module is automatically tested. look at the stats to weed out problematic modules.

- check out the release frequency and when the last release occurred.

- read the Changes file

- take a look at the tests for the module, is it well tested? are there alot of tests?

If you are past a certain point in your life as a Perl programmer this comes very natural and does not take alot of time.

I agree, but naive new Perl users might benefit from some prominent showcasing of well-known good modules or maybe comparison charts between modules in the same functional niche... Maybe that is a subject better left to Perl bloggers rather than to the neutral CPAN, but first contact with Perl is sometimes an embarrassment of riches.

Anyway, I love the CPAN - whatever I imagine myself wanting to do, five people have done it already !

Well, MetaCPAN has a leaderboard of modules, but it could be a bit more prominent: https://metacpan.org/favorite/leaderboard

I recently spent 4.5 years at a big bank developing identity-management tools. They were written in Perl. The first thing I did was screw up in production: http://www.schmonz.com/2014/06/01/tdd-in-context-1-keeping-m...

So I started carefully making the code testable, then gradually adding tests and refactoring under them, and gradually adopting and taking advantage of Moose, shipping every month all the while. There was never a second screwup.

(Will big banks keep choosing Perl for new projects? Yes, for a long time. It's firmly entrenched. It didn't win, but it'll probably never lose either.)

Would I choose Perl for a new project? That depends. For programmers with taste, discernment, and discipline, Perl-the-language + Perl-the-CPAN can be incredibly and sustainably productive. For other programmers, it's enough rope to quickly cut off bloodflow to your foot, which you can then use Perl to amputate.

In other words, Perl is at the high end of the risk/reward curve. If I could mitigate the risk -- say, by convincing myself that I'll always be in a position to hire great programmers or nobody -- then I'd absolutely want the reward of developing a new system in Perl.

I think the article is a little bit harsh on Perl. Ruby (1995) and Python (1993) wouldn't probably exist without Perl (1987). Hence IMHO it's just a sort of evolution, nothing more. The other two languages learned from Perl's mistakes and were better designed.

At the end of the article, he/she says "the Swift programming language has been public for less than a week and already has more users than Perl 6, and Swift is entirely built on technologies which have been invented since the Perl 6 announcement".

That's simply false; anyone who's been in the programming languages field for a while knows that...

I interpreted that as 'Perl 6 dates back to 2000, while LLVM (upon which Swift is built) dates back to slightly later in the year in 2000.' (although, to be fair, the LLVM website first appeared in 2002.)

I always check on indeed.com to confirm the popularity of things. It looks like Python just broke past Perl on absolute job posting numbers.

http://www.indeed.com/jobtrends?q=+perl+developer%2Cpython+d...

Another perspective: Perl lost because the culture of internet software development moved away from hackers who grokked humor and cleverness towards team-driven business application developers who preferred synergistic framework solutions.

The domain outspeaking.com is owned by chromatic's company.

Afaict chromatic was the first to promote the article with a tweet shortly after it was published and shortly before it appeared here on HN and reddit.

When someone noted this connection on reddit and said they thought chromatic wrote it his response was "I'm not the only person with access to the server. Anonymous wrote that article."

http://www.reddit.com/r/perl/comments/27o6h5/why_perl_didnt_...

Even if it's not chromatic (I think it is), is it not obvious that the OP article is designed to garner inbound links/views (and sell books) rather than provide a balanced picture? Consider the juxtaposition of the deceitful title and well written content. Do you see what the author did there?

My understanding is that chromatic is not the only person at that company that knows Perl, not that has had experience with Perl 6 and/or Parrot. I think it's appropriate to judge the article on it's merits and how well it covers the issue, not the specific views of people that may be associated with it.

Truth be told, I was thinking while reading it that it sounded quite a bit like chromatic but with tones down criticism, and said as much to a friend I fowarded it to. I wrote this "Sounds a lot like chromatic when he was disillusioned, but not yet bitter. Which is to say harsh, but definitely constructive." That it's from the company he's involved in doesn't surprise me. If he wrote it and wants to keep it as aonymous, I think that's perfectly acceptable. If someone else there wrote it, that wouldn't surprise me either; I doubt all of his thoughts and opinions happen in a vacuum.

if ain't php ,think will stick to perl.. first web base language learn..

why down vote,since it my first web base language in 2001. By that time,php is new and .net is version 1. When i got visual studio dvd,my pc run slow. So i moved to php and stick till now.

I never understand the apparent glee with which people perform premature post-mortems on Perl.

You never really see people declaring any other language moribund, and then kicking it a couple of times for fun.

I don't see the point?

No language syntax causes me higher cognitive dissonance than perl. I just find it fugly.

Whenever i read perl code, i feel somebody is cursing me through the source code

Write once, read never.

Speak for yourself! (or maybe, for annoying coworkers???)

It's certainly possible to write functions (subs) with comments about what they do, and use meaningful variable names. The built-in syntax/operators do require some study, though.

For the "Enterprise!" developer pool, there's Java. The 500 line methods are still hard to slog through, though. Too many never got the note about a "business logic layer" and abstraction, and just shove all the details in-line. In which case, the language of mandate doesn't matter much.

> For the "Enterprise!" developer pool, there's Java. The 500 line methods are still hard to slog through, though.

Great straw-man there. I didn't realise that javac required 500 line methods before compilation.

> In which case, the language of mandate doesn't matter much.

It's a lot easier to pass two collections to a method in Java than to a sub in Perl.

--- Java ---

List <Integer> aList = Arrays.asList( new int [] { 1, 3, 5 }); // probably missing some more type stuff in <>

Map <String, String> aMap = new HashMap <String, String> ();

aMap.put( "name", "Joe");

aMap.put( "ID", "42"); // I need to check if Java 8 has map literals a la Groovy...

doSomething( aList, aMap);

...

void doSomething( List <Integer> aList, Map <String, String> aMap) {

System.out.println( "First: " + aList.get( 0) + ", Name: " + aMap.get( "name") );

}

--- Perl ---

&do_something( [ 1, 3, 5 ], { 'name' => 'Joe', 'ID' => '42 });

...

sub do_something {

my( $list_ref, $hash_ref) = @_;

printf "First: %d, Name: %s\n", ${ $list_ref }[ 0 ], ${ $hash_ref }{ 'name' };

}

------

I'm not seeing that much of a difference in parameter passing, other than the explicit reference/dereference syntax.

Of course Java doesn't require 500 line methods. But the bondage and discipline imposed is independent of whether or not readable code will be produced.

I actually like strongly typed languages for larger programs, but prefer something more fast and loose for smaller ones. TMTOWTDI!

I guess that bottom line of what I am trying to say is that not all perl code is unreadable crap. That has more to do with the writer than the language. And, different languages make different things easier.

No final "right" or "wrong" choice for all use cases.

> I guess that bottom line of what I am trying to say is that not all perl code is unreadable crap. That has more to do with the writer than the language. And, different languages make different things easier.

I would agree. It's the same issue Scala faces IMO - it doesn't have to be a complex maze of types and implicit conversions and implicit values, you can, if disciplined, write very understandable and clear Scala.

Sadly though, it seems a lot of developers aren't disciplined.

With great power comes great capacity to write overly clever unmaintainable crap.

> List <Integer> aList = Arrays.asList( new int [] { 1, 3, 5 });

You can drop the inner array, asList takes variable number of arguments.

> // I need to check if Java 8 has map literals a la Groovy...

Sadly not, IIRC they've backed off from literals towards a Guava style static factory methods, which I'm not thrilled about.

> I'm not seeing that much of a difference in parameter passing, other than the explicit reference/dereference syntax.

So let's say I'm a newbie Perl developer just exploring subs.

  sub stuff {
      my ($a, $b) = @_;
      print "$a and $b\n";
  }

  my $a = 1;
  my $b = 2;

  stuff($a, $b);

It works! Hurrah. Feeling clever, I move onto collections.

  sub stuff {
      my (@a, %b) = @_;
      print "$a[0] and $b{A}\n";
  }

  my @a = (1);
  my %b = (A => 2);

  stuff(@a, %b);

And it doesn't work at all. @a has some additional values, and %b is undef.

So yes, let's use references.

  sub stuff {
      my ($a, $b) = @_;
      print "${$a}[0] and ${$b}{A}\n";
  }

  my @a = (1);
  my %b = (A => 2);

  stuff(\@a, \%b);

Except now, I have two ways of working with Perl's collections, two separate sets of sigils, and all because I wanted to pass two collections into a function and Perl treats function arguments as a collection, and Perl implicitly flattens collections.

The difference I see, as a Perl newbie only working with it out of necessity, is that having (because you need it because of earlier design choices) more than one way of operating on data structures, violates the principle of least surprise.

> Except now, I have two ways of working with Perl's collections, two separate sets of sigils, and all because I wanted to pass two collections into a function and Perl treats function arguments as a collection, and Perl implicitly flattens collections.

It's not really two sets of sigils, it's two concepts: "collection", and "pointer to collection". I guess coming from C that didn't bother me too much—once it sunk that references were just (safe) pointers, using them works almost exactly the same:

    int a = 1, *b=&a, **c=&b, ***d=&c;
    printf("%d %d %d %d\n", a, *b, **c, ***d);

    my $a = 1; my $b=\$a; my $c=\$b; my $d=\$c;
    printf("%d %d %d %d\n", $a, $$b, $$$c, $$$$d);

Perl even stole C's pointer syntax to make working with collections nice:

    my $a = [1,2,3];
    printf("%d\n", $a->[0]);

> it's two concepts: "collection", and "pointer to collection". I guess coming from C that didn't bother me too much

Fair point. I guess what bugs me is that you can use collections merrily without references until you want to pass more than one collection to a function - or create a collection that isn't flattened - at which point you have no choice.

Incidentally, I find the -> operator more readable than the explicit dereference ${} stuff:

    printf "First: %d, Name: %s\n", $list_ref->[ 0 ], $hash_ref->{ 'name' };

It's certainly possible to write functions (subs) with comments about what they do, and use meaningful variable names in Assembly too.

I can read Perl, but the only way you'll get me to read it is to write a script with bugs in it and force me to debug it. It's fun in a masochistic sort of way. Anyway, Python and Haskell are my languages of choice now.

Account literally created a few minutes before posting.

YALT -- yet another languagewar troll.

It's not the first time someone has called Perl a write-only language, I heard that joke first in 1996.

Old trolling is respected?

Something like religion then, were people hearing voices long ago got followers -- but today generally are locked up? :-)

Perl has always been the butt of write-only jokes within the PL community; just imagine Perl as Rodney Dangerfield complaining that it "gets no respect." APL is of course, the canonical write-only language, but it is completely honest and accepting about it.

I programmed in Perl for CGI in the mid 90s and didn't see anything wrong with it. It was weird, but I had programmed with much worse before then (Lotus Notes Script...whew), so I wasn't really bothered by it. That being said, I see no reason ever to write another line of Perl again.

Well, not really relevant for either Modern Perl or my point.

(Or that it gets a bit old after a few hundred times on HN, now with newly created accounts. No one want anyone to do the same for other subjects.)

Mid 90s? 20 years ago, just after the release of Perl 5 and before everything else? I understand your opinion... :-)

In one of the WWDC sessions an Apple engineer was adamant one should never choose terseness over clarity, because every line of code is written once by one person, but read many times by many people.

And funny enough Objective-C is taking this quite seriously, being a very verbose language (the new Swift language also keep the verbose method names, enums and properties).

While Perl is exactly the opposite. There's a reason people jokingly call it a write-only language.

It has real implication on its usage. You use Perl for one-off scripts you intend to forget and maybe delete after you run them a few times.

While CPAN happened, I wonder how much Perl was an obstacle in multiple people joining to work on a single library (versus multiple people just downloading it and using it, big difference).

Most of the modern perl ecosystem is libraries built by substantial teams - it's a lot different now than a decade or so ago.

The Modern Perl dialect is basically what came out of the new wave of CPAN (Enlightened Perl) movement which is all about using perl's flexibility in a way that scales to larger teams.

Sadly, every attempt to explain this to people not already writing it results in a deluge of 'write-only' jokes and nobody bothering to actually look at the code, so while the technical capacity is there, the pop culture nature of programming language choice means people generally never realise.

Perl's brand is damaged. No amount of explaining fixes a broken brand.

The best that can probably be done is to create a new language which is, say, a clean subset of Perl 6 and call it something new, focusing the message on how readable and intuitive it is.

There are so many snarky things to say, but my mother taught me to never speak ill of the dead.

Reply on news.ycombinator.com