Hacker News Reader

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

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

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.