Hacker News Reader

Comment by wazoox | Hacker News Reader

I've made a presentation on this very subject to a hackers conference in 2013. It's very clear to me, it's because of Perl6. In 2013, Perl was 26 years and Perl6 was 13 years already, half as old as Perl itself but nothing close to production ready.

The launch in fanfare of Perl6 in 2000 had a general chilling effect on Perl: many people considered from that point that there was no point learning and using Perl 5, because Perl6 was "just around the corner" and was "the future of perl".

It's just last year that people finally came to their mind : Perl6 became Raku and is a different language, period. And Perl 5 is supposed to get out of its 20-years of maintenance cycle by becoming perl 7 and changing some defaults it should have done back in 2007 or so...

Well. That's life.

View on HN

As someone who learned both well after the 2000s, it was painfully obvious to me that Python was easier to learn/use and had a lot more momentum than Perl (this was around 2012). I think that's really the nail in the coffin in that they both cover the same scripting niche, but Python won out and less people began to use Perl. Also, Perl5 has a modules approach in that there are several potential OO frameworks like Moose, while Python had it as part of the base language which a lot of people prefer. Python also became a solid data science and numerical methods language, so it ended up winning out. I never thought Perl5 was bad, just not as good as Python. As far as P6/Raku, I think the language design is good, but I won't use something like that professionally until it reaches a certain quality and production readiness. It really is pretty neat and is like a superior Python without the useful frameworks.

Edit: the Python REPL approach was also much better for debugging scripts than how I had to do things in Perl.

In one of my previous positions, part of my work was maintaining legacy build and automation scripts, many of which were written in Perl.

The one thing that stood out to me, was what happened when I had to show somebody else what a script did. (I was always showing somebody with some programming experience, but not always with the matching language).

It didn't matter what language they had experience with, Python was always easy to walk them through the code. I know this sounds scary to most, but when you are low on people and even lower on resources, you do what you can.

When I needed to explain Perl to somebody without Perl experience, the eyes would glaze over as soon as @ and $ and % characters started showing up (re: immediately).

It's not that Perl isn't a great or powerful language. It is. I use Perl style regex almost every day. Perl taught me hashmaps.

But Python code looks familiar to a lot more people. No mystery symbols. No needing to explain that the @ symbol is an array, except when reading from it. Then you use $.

When I explain Python code to someone who doesn't know Python, they ask me about the actual code. Why I made certain decisions regarding the design or functionality.

When I explain Perl code to someone who doesn't know Perl, they tell me it looks like gibberish.

> When I explain Perl code to someone who doesn't know Perl, they tell me it looks like gibberish.

I had a very brief experience with Perl in school around 2001-ish.

All those concepts you brought up made me never want to touch it again. The language just comes across as a tool made out of necessity in the 1980s / 1990s, but then better tools came around.

But, more importantly, I will never apply for a job that lists Perl. It's just a relic from the past.

> But, more importantly, I will never apply for a job that lists Perl. It's just a relic from the past.

Good. More Perl jobs for me then. Although I kind of got bored with Perl and would probably enjoy coding in Ruby or D or even Crystal.

That's not the issue.

The bigger issue is avoiding jobs where the management chose an "impossible" stack. IE, a stack where the technology choices actively impede productivity.

Unless the job basically involves modernizing something that's been around for a few decades, why would anyone do new development in an outdated language?

Most Perl jobs today involve either maintenance or modernizing some existing codebase. I wouldn't start a new project in Perl, other than simple scrips that I wouldn't write in bash or a sub 5k loc web service, but I'd probably rather do that one in Node.js.

After working a python shop for few years one thing I always liked was it was rare that you could tell who wrote what bits of code. Not sure why that was... it might have been how the language itself forced certain idioms. But typing this out I also think it could be the shop’s practice of face to face code reviews. Before you’d merge anything into master you’d always snag somebody to sit next to you and look over your code.

So it could have been the language, but it could have been the culture too.

Python and Go are both like that. The language really encourages a single way of doing things, so when a new programmer sticks 20 lines of new logic in the middle of someone else’s file, it quite often aesthetically blends in. I like it, but sometimes there’s a trade off against power and flexibility.

Python has magic methods, metaclasses and decorators, which gives you quite a bit of flexibility when you need it. Maybe not quite to the extent of Ruby, but more than Go.

I've had to read other people's Perl code before, and that experience basically made "flexibility" a bad word in this area for me.

Please stop the ^$%@#$%#@^@$%^&( nonsense, Perl hackers. That's not flexibility, it's childish bravado. Write code that people can read. If some of that precious "flexibility" is lost in the process, that's a net gain actually.

Long live Perl golf. Can't we have a bit of fun with our language in this anodine, Python-dominated world?

> No needing to explain that the @ symbol is an array, except when reading from it. Then you use $.

Perl is stuffed with unforced errors like this. Lack of named parameters! Reading from filehandles by putting angle brackets around them! Filehandles being a distinct type from scalars! Hashes and arrays not being usable in the same way scalars are (can't put them inside an array or a hash, have to use a reference)! Even at the time, this stuff was distinctively bad. I wrote loads of Perl in the late '90s, and as soon as Python became viable, i leapt at it, because the language was so much simpler and more uniform.

All this is particularly wild considered in the light of the fact that awk, an explicit precursor to Perl, has a significantly simpler syntax. How did Larry Wall look at awk and think "i know, what i need to do is take out the named parameters, and add some more sigils!".

I do wonder if, it hadn't been for Perl, there might have been room for awk to grow into something more general. Probably not. But i don't see any technical reason why not.

I agree with you on a lot of this. Complex (nested) data structures are a real pain in the ass in Perl, especially back in the early 2000s.

However, named parameters have been a thing for ages. It's extremely common to call functions using an anonymous hash like so:

  $sock = IO::Socket::INET->new(PeerAddr => 'www.perl.org',
                              PeerPort => 'http(80)',
                              Proto    => 'tcp');

By named parameters, i mean:

  sub double($value) {
      return $value * 2;
  }

Which you can't write in Perl (or at least couldn't in 1998). You have to write this:

  sub double {
      my $value = shift(@_);
      return $value * 2;
  }

"Named parameters" probably isn't the right name. This is such a basic feature of programming languages that i don't even know what it's called.

"Unrolling @" was a common bugbear amongst Perl programmers and caused a few I know of to leave for Ruby or Python. Normal, parenthesised parameters were considered experimental until not that long ago so is it any wonder Perl failed to compete with Ruby and Python?

The term you are looking for is "pass by reference".

Perl does not have pass by reference, you have to use pointers if you want to do it. It will even go so far as to duplicate an entire array or hash you pass to a function, which can surprise novice Perl programmers when they build a giant data structure and start passing it around only to discover their program running slowly. Or worse, finding their changes to the structure being undone when the function exits.

> The term you are looking for is "pass by reference".

Nope, just parameter declarations. I also kind of doubt the by-value semantics will surprise anyone the way you describe: If you pass things by value without explicitly taking a reference, the structure (arrays and hashes, specifically) will be flattened into the argument list. If you're unaware of this, things will probably go wrong long before you've had time to be surprised by stuff getting copied...

It can certainly catch C programmers who are used to arrays devolving to pointers in the background when passed as parameters.

> But Python code looks familiar to a lot more people. No mystery symbols. No needing to explain that the @ symbol is an array, except when reading from it. Then you use $.

I learned Perl first and used it professionally for a number of years but switched to PHP and Python more or less for this reason. Perl had a great package manager, performed well, etc. but no matter whose code it was, it required more work to read code and even seasoned developers would waste time on bugs which turned out to be some magic syntax quirk which was too easy to miss. perltidy helped a lot but why not start with a language where many of these problems can't exist?

The other big reason was error handling: Python's reliance on exceptions is a huge win for stability & avoiding certain security bugs. Perl code was harder to read with all of those return code checks and even seasoned developers would mess up more complex scenarios.

Perl almost encourages obfuscation. Some folks took pride in writing hard to read Perl code - and the language gave them all the rope they could hang themselves with.

For that reason I always disliked Perl, quite strongly, and from the beginning (I've first seen it in the '90s).

Bad, naive language design, that's all. The prevalence of Python nowadays is a sign of maturity.

This is the correct answer. Python and Ruby pretty much ate Perl's lunch. Depending on whatever you were working, one of those two languages, was almost always a strict improvement over Perl.

The only place really shines comparatively is in CLI one-liners. But even there, awk is usually a better tool.

I agree that Python and Ruby ate Perl, but for me they are not strictly an improvement. Just spoons of a different colour. Python is more novice friendly, but for someone who uses language every day it is not a problem to learn Perl syntax and BCP.

I was doing web development back then, and Perl in your cgi-bin was pretty hot tech, especially compared to c. But then PHP came around, and I never really looked back. I've moved on, and out of web development, and I keep circling back to C, but never perl. Python does pretty much everything I'd want Perl for.

Ruby is pretty close to Perl for one-liners. Try it.

" Also, Perl5 has a modules approach in that there are several potential OO frameworks like Moose, while Python had it as part of the base language which a lot of people prefer."

Perl's built-in OO, without Moose, works fine, and isn't substantially different from python's.

What is different is that "everything is an object" in python. That's not true for Perl. So Perl OO is a bit saddled with references (pointer like things) and sigils ($this, @that, %theother) and therefore intimidating looking data structures, dereferencing, etc. To me, that's what makes OO Perl painful. To be fair, it's also one reason why Perl is often a lot faster than Python...basic types don't have the same amount of overhead.

Personally, I love Perl and still use it often. But I can see why Python sucked away the user base.

This right here. I had a project in 2003 that I started in Perl and wanted to do right with OO. That lasted two days. I switched to Python and have never turned back

I like Perl, and find the complaints about sigils weak given how many people swear by POSIX scripting, when there are so many better tools out there like Perl.

However I also found Perl’s OO to be painful. I’d call it a cruel joke. I could never comfortably wrap my head around its implementation because it always felt like a horrible kludge on top of the module system. Is it a module? Is it a class? Is it an object? Are they normal functions? Are they class methods? Or are they member methods? The answer to all for these questions is a resounding yes! TIMTOWTDI bites us once again.

Perl is great for its primary use case of being the thinking person’s BASH, and it has the greatest regexp and stdio support for any language I’ve used, but I wouldn’t build anything OO with it.

I didn't mean to say that sigils were a general issue. Just that they made complex data structures (and thus, OO) more complex...and intimidating for newcomers.

As for wrapping your head around Perl OO, really it's just bless(). Bless($thing,'namespace') says "this $thing is an object, in this namespace". You can make an object without adding a namespace beyond the default main namespace...

Like:

  sub test {print "whee\n";}
  my $foo={};
  bless($foo,'main');
  $foo->test();

That will print out "whee". Because I "blessed" $foo into the main namespace, calling $foo->test() is calling the subroutine "test" in the main namespace, with '$foo' as the first argument.

So OO in Perl is just mapping a namespace to a blessed reference via bless($ref,'namespace'). Then $ref->call($arg) runs the "namespace::call" sub, but as if you did namespace::call($ref,$arg).

Yeah, they’re just void pointers.

I think lack of syntactic support for nested data structures comes from its origin as a better bash script.

That's pretty much exactly it. The core of the perl community decided that what they really wanted to do was spend their time bathing lazily in their shared hubris, designing (with... surprising patience) a new perfect language. And I don't really blame them, that's a lot of fun.

But perl had become successful not by being a perfect embodiment of TMTOWTDI or whatever but by being a simply amazing practical language for practical problems. And without the support for the practice of perl, perl 5 rapidly withered as new problems became more practically solved in Python or Ruby.

It's worth noting that Python almost did exactly the same thing to itself, too. But it was saved because Python 3 wasn't nearly as incompatible as Perl 6, and that it actually shipped reasonably promptly. But IMHO it's no accident that the explosion of node.js happened just as Python broke the world with their incompatible upgrade.

> It's worth noting that Python almost did exactly the same thing to itself, too. But it was saved because Python 3 wasn't nearly as incompatible as Perl 6, and that it actually shipped reasonably promptly. But IMHO it's no accident that the explosion of node.js happened just as Python broke the world with their incompatible upgrade.

Not totally sure that I agree here.

I wrote backend Javascript code when Node was beginning to become popular instead of Python because I needed to write a multiplexed socket server that was much better server by the JS asynchronous paradigm over Python. Socket.io was a much better experience than much larger, complex Python equivalents which performed worse, so I kept around most of my Python code and used Node for multiplexing.

At the time Python 3 wasn't even a question. There was no push to upgrade seriously, just patiently waiting for the libraries and frameworks to be ported.

To this day Node.JS and Python server fairly different purposes in most stacks, and although they can do the same job, for each domain generally one is better than the other.

Obviously yes, they entered different niches. But that's true of any technology. The question in my mind is more: if PyPy hadn't been preoccupied with fighting a compatibility battle with all the churn in upstream python, would it have been chosen instead of V8 as the vehicle of the new concurrency revolution? I think there's a reasonable argument that it would have been.

Back in the 2000’s Perl was my bread and butter.

The thing about perl6 was it over promised and... well... never delivered. It was to be a from scratch rewrite. It was gonna have all these space-age feature like a VM to host other languages like what .net or Java does. It was gonna try to fix years of baggage. It was gonna be super hot. But it never shipped in time.

Meanwhile python was an excellent alternative. Ruby on Rails was just coming around. C# was becoming a real contender (c# remains one of my favorite languages...).

All those languages were getting tons of community support. Perl’s community was starting to slow. It’s top devs were busy with v6. V5 was not getting any cool new features. And it was made quite clear that v6 had many breaking changes from v5.

I dunno. I file perl6 in the same bucket I file Netscape and Winamp. Proof that doing ground up “from scratch” rewrites are great ways to kill forward momentum on your product. Rewrites take much longer than any estimate. To pull it off you need to have unlimited budget and the ability to support and improve the current version while also building a brand new version whose scope constantly creeps to maintain parity with your current version. The second you stop maintaining and improving what you have in the market today, your competitors will eat your lunch.

It is what killed Netscape to a large extent.

It killed Winamp to a large extent.

And it put a couple nails in perl’s coffin too.

I think two major things, beyond the sheer audacity of it, really slowed Perl6 down. This is NOT meant to sound negative; I basically owe my entire career to Perl. I got paid to write Perl every day from 1993 until 2015, and I still really like the language, warts and all, and love the amazing features/ideas in Perl6/Raku.

The first is Larry Wall's basic personality. He is a really nice guy, all the way through. Along with that, I think he's fairly passive. Years ago, I read a comment from him where he noted that of all of the things he's posted online, the vast majority were replies. He rarely directly initiated.

Clearly he initiated Perl, as well as https://en.wikipedia.org/wiki/Patch_(Unix) (for those who might not know, this was basically the reverse of 'diff', and is effectively the spiritual ancestor of MANY of the tools and technologies we use today.)

But the genesis of Perl was really small; like Linux and many other projects, it was done to solve very specific problems, and also for the fun of it. Perl utterly exploded, effectively dragging Larry Wall along with it.

All that to say: even as Larry was able to put forward technical direction, as seen in the creation of Perl6 and subsequent design/development processes, I don't think he ever felt very comfortable being a community leader.

The second major factor early in Perl6 was that Larry had some substantial medical problems at really key, important times.

I don't know if these and other factors, if different, might have allowed Perl6(Raku) to become successful. It's possible that the sheer, awesome scope of Perl6 was just too big.

One way or another, what ended up happening was a damn shame. In retrospect, I think it's clear that Larry should have, in 2000, announced the creation of a new language, a language that shared many/most of the broad goals and ideas of Perl.

But 21 years ago, such an announcement would have been almost impossible. The total amount of hurt and divisiveness that ended up coming about due to Perl6 might have been minimized with such an action, but it would have been strongly front-loaded, with an unbearable amount of community pain concentrated into a single point.

I believe Jon Orwant's mug was largely responsible for Perl 6.

This is a very neat and relatively obscure reference, but yeah, Orwant's very considered 'tantrum' was almost certainly the psychological 'kick' Larry needed to get out of a local maxima.

> It's very clear to me, it's because of Perl6.

It doesn't seem right to ignore the increased popularity of better and more user-friendly interpreted languages such as python, which has since became ubiquitous even in spite of the python2-python3 transition.

Also, there was the inception of node, which brought javascript front and center.

In fact, among the interpreted languages that were popular 20 years ago, which ones besides python still hold some relevance?

Perl, whether v5 or v6, can't exactly compete with javascript or python in terms of ubiquity and user-friendlyness.

If Perl's learning experience is harsher, and in the end there's less demand and job prospects, why would anyone pick Perl over any alternative?

PHP was popular 20 years ago and seems to still have wide adoption.

By at least some measures, it’s the most popularly deployed language as well. This is probably at least 50% due to counting WordPress.

That said, I did pick up PHP and Laravel out of curiosity. It truly is nothing like the PHP I learned in 2001.

e: a word

I’ve also seen a lot of job postings in that field. Seems like Laravel has a substantial following in the way that Rails does.

The fact that PHP was, in the era of shared hosting accounts, the default scripting language was like a slingshot maneuver around the sun. It's hard to understate the incredible momentum that surge of casual users brought to it that no other language received, and has sustained it over the long, painful modernization that was needed to make it relevant today. More than PHP, we're still using platforms that were begun in that era: WordPress, Drupal, etc. There's still Zencarts out there.

It's more remarkable that Python is still relevant, which is a testimony to the overall quality of its design and its usefulness in a large number of different areas. Had Python been only a web scripting language, it would have been eclipsed by PHP just like Perl.

I don't know about quality of design. Python's popularity is largely due to how much it dumbs down and being a first mover in the scientific world. Python has no built-in regex support and its crippled lambdas are nothing more than the indulgence of its BDFL who has a bias against functional programming. Compare that with Matz's approach to language design.

> Python has no built-in regex support

Are you basing this claim on something like not having a special literal syntax? Python has had regular expression support for ages and it works quite well: https://docs.python.org/3/library/re.html

Yes, I'm comparing it to languages which have regex operators (Perl, Ruby) and where you don't have to `import re`.

Okay, so that's a somewhat different claim and it really comes down to how much you care about an operator versus a extra couple of characters. Most programmers know how to touch-type and do not hammer out regexps so quickly that the difference between:

    $foo =~ s/foo/bar/

and

    foo = re.sub("foo", "bar", foo)

is a significant factor in deciding which language to use, especially since there are legibility tradeoffs (i.e. escaping) and the Python approach for handling e.g. groups is cleaner for non-trivial code and avoids the chance of accidentally clobbering $1, $2, etc. — a bug pattern I've seen affect people more than once.

Personally, if I were advocating Perl I'd probably go with angles like the extended capabilities or more complete Unicode support which Python users need to get from the regex module (https://pypi.org/project/regex/).

Having been raised into the profession at a time when both Perl and Python were strong, the amount of times I have had to reach for regexes as a frequent solution to a problem is so rare that I can hardly see how it's a problem.

It's about as much of a problem as not having built-in linear algebra operators.

I thought this as well but didn't want to get sidetracked on a specific. Perl was one of my first languages and regexes were one of the big tools I started using, while I was processing text files. Once parsing lines of ASCII stopped being my major task, regexes stopped being a frequent tool.

Arguably, that's good design, at least in terms of actual success. Where is Ruby relative to Python? "Dumbed down" means good pedagogical language--it's always had an advantage there as well in scientific computing. And the strength of its design is seen in the fact that it's still used by very experienced/advanced users.

Also, it wasn't a first mover in scientific computing--Matlab and Maple were around long before numpy. Matlab dates from the early 80s; numpy from 2005. Python has stolen a lot of mindshare from Matlab with numpy and scipy and Jupyter. Even today I help PhDs switch from Matlab to scipy.

Personally, I've always liked the ethic of Python that there's only one way to to do it, normally. It means the boilerplate code looks the same everywhere, and when you break the "rules" of that one way, you do it with a reason, a conscious justification, rather than as a stylistic flourish or an idiosyncratic preference.

> Python's popularity is largely due to how much it dumbs down and being a first mover in the scientific world.

Python is obviously not "a first mover in the scientific world" as Matlab precedes Python for over a decade and is still the de facto tool of the trade pretty much everywhere except ML.

And please don't misrepresent UX as "dumbing down". If anything, Python does right far more things that other languages do blatantly wrong and even in a user-hostile way.

> Python has no built-in regex support

This argument reads like a blatantly desperate attempt to find any thing at all to try to get Perl's leg over Python.

Meanwhile, no one ever complained about Python's re module not doing its job, and Python is extensively used pretty much everywhere, involving regex or not.

Php is banned within many companies as too insecure of a platform to build anything on.

Focusing on the community is a strange take. I dont know much about Perl6 or care...anymore than I knew anout PHP6. Perl is syntactically complete and has great library support.

People dont choose Perl because it's too flexible in how to do things ie what is idiomatic in Perl...well it depends on how well you know Perl. This hurts readability and adoption. It also has warts like any other language but thats hard to detect when reading code is an issue.

The best parts of Perl have already been adopted by other languages. No reason to use Perl that I can see.

> The launch in fanfare of Perl6 in 2000 had a general chilling effect on Perl: many people considered from that point that there was no point learning and using Perl 5, because Perl6 was "just around the corner" and was "the future of perl".

Yup, the Osborne effect: https://en.wikipedia.org/wiki/Osborne_effect

This is exactly it for me. Perl just seemed to be stuck in a stasis with the whole Perl6 mess for over ages while the world moved on. I still maintain some perl scripts and it's great for small tasks, but by the time they got everything sorted out no one under 30 knows perl at all anymore as it seemed like a dead end.

"while the world moved on"

yet the world still does not have half the features Perl 5 already had for 20 years :)

... from scoping to support for every major programming paradigm

Much as I like Perl I'm not sure I'd agree with you. What does Perl have that Ruby doesn't?

Sigils and dereferencing /s

In 2008, I was in charge of standing up a new service at the company that I worked. They were a heavy Perl shop. I considered using Perl 6 for it since it was "just around the corner." After some investigation, we realized that (a) it was not just around the corner and (2) Perl developers were hard to come by. We went with Java/Spring instead.

Reply on news.ycombinator.com