8 ms·

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

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.

salamander014 6y ago
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.
- gwbas1c 6y ago
  > 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.
  - petre 6y ago
    > 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.
    - gwbas1c 6y ago
      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?
      - deleted 6y ago
        [deleted]
      - petre 6y ago
        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.
- spookthesunset 6y ago
  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.
dcolkitt 6y ago
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.
- klyrs 6y ago
  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.
- citrin_ru 6y ago
  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.
- cutler 6y ago
  Ruby is pretty close to Perl for one-liners. Try it.
tyingq 6y ago
" 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.
- wombatpm 6y ago
  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
- jonathankoren 6y ago
  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.
  - tyingq 6y ago
    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).

salamander014 6y ago

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.

gwbas1c 6y ago
> 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.
- petre 6y ago
  > 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.
  - gwbas1c 6y ago
    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?
    - deleted 6y ago
      [deleted]
    - petre 6y ago
      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.
spookthesunset 6y ago
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.

dcolkitt 6y ago

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.

klyrs 6y ago
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.
citrin_ru 6y ago
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.
cutler 6y ago
Ruby is pretty close to Perl for one-liners. Try it.

tyingq 6y ago

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

wombatpm 6y ago
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
jonathankoren 6y ago
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.
- tyingq 6y ago
  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).