9 ms·

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 st

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.
- lacker 6y ago
  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.
  - goatlover 6y ago
    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.
  - Florin_Andrei 6y ago
    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.
    - cutler 6y ago
      Long live Perl golf. Can't we have a bit of fun with our language in this anodine, Python-dominated world?
twic 6y ago
> 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.
- jandrese 6y ago
  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');
  - twic 6y ago
    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.
    - cutler 6y ago
      "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?
acdha 6y ago
> 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.
Florin_Andrei 6y ago
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.

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.

lacker 6y ago
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.
- goatlover 6y ago
  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.
- Florin_Andrei 6y ago
  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.
  - cutler 6y ago
    Long live Perl golf. Can't we have a bit of fun with our language in this anodine, Python-dominated world?

twic 6y ago

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

jandrese 6y ago
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');
- twic 6y ago
  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.
  - cutler 6y ago
    "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?

acdha 6y ago

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

Florin_Andrei 6y ago

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.