Hacker News Reader

Comment by fangorn | Hacker News Reader

I liked writing Perl a lot, but when it came to reading, let alone fixing, other people's Perl, it was always a bit of a nightmare. That's one of the main reasons I was reasonably happy to move away from it - nobody seemed to heed "Just because you can, doesn't mean you should" mantra. Sure you can write good Perl, and I always did my best in that area, but it was not the reality for most Perl programs out there. CPAN also turned to a bit of a mess at some point, and in general dependency management was non existent, really. Containers could help alleviate this pain now, to an extent. Still, it would need to seriously improve to lay any claims to being able to write modern stuff in Perl.

View on HN

CPAN is great, but also horrible. There are so many packages that do the same thing, and it was often hard for me to know which to pick. Want OO? Use Moose, or Moo, or Mouse or whatever else. Then hope that the one you picked will continue to be maintained. I resisted moving to Python for a long time, but when I finally did it was a bit refreshing to have more packages built into the language so I didn't have to make so many choices on what 3rd-party libraries to install. Perl will always have a special place in my heart though.

As far as reading code goes, Perl could be particularly messy, but I've seen some very hard to read Python code as well. And Javascript... I still don't get why people want to use it server-side. But all these languages have tooling that helps make sure code is at least formatted correctly, and follows some sort of best practices. I think one of the hardest parts of reading Perl, to me, was that it wasn't always clear what package a particular function or class was imported from.

> CPAN is great, but also horrible. There are so many packages that do the same thing

IMO, that's a good thing. Imagine having only one choice at any layer in society (to make my example extreme): one type of house, one type of car, one type of computer, on type of OS, one type of file system, one type of programming language etc.

> Want OO? Use Moose, or Moo, or Mouse or whatever else.

This is true; no built-in "proper" OO has been a pain for Perl for a long time. However, I've used to love Mouse (like Moose, but a trillion times faster), and I've never had any problems with it.

There are plans to inject proper OO into Perl, though.[1]

> Then hope that the one you picked will continue to be maintained.

This is my biggest problem. I wish there was a "system" of sorts that let _groups of people_ adopt/take over a Perl module and Just Fix It (tm). Having only one person take over a module/package isn't good enough; there must be more people involved in fixing things.

One good example is Crypt::Curve25519[2] which could/should have been fixed years ago, but because the maintainer is inactive, it won't happen.

And now we're back to where we started: because things doesn't get fixed, people create their own versions of CPAN packages just for the F[ix|uck] of it.

[1] https://dev.to/ovid/bringing-modern-oo-to-perl-51ak

[2] https://metacpan.org/pod/Crypt::Curve25519

There is an adoption process for truly inactive maintainers: http://neilb.org/2013/07/24/adopt-a-module.html - you can also often get somewhere by just asking the current maintainer nicely by email. The timeliness of the process in the event of a non-repsonsive maintainer depends on luck and how much depends on the module. In the end it doesn't matter if a group or a person adopts it - someone still has to decide to do the work.

> There is an adoption process [...]

This is good, but to me it's too tedious. I can't wait a month for something to happen. The solution so far has been to fire up a Pinto server and serve "home-made-patched" versions of modules, which only benefits myself, not the community.

> [...] you can also often get somewhere by just asking the current maintainer nicely by email.

What could be more intrusive than creating a pull request or git issue? An email.

Just use Moo or none at all. Moose is to big and slow pulls too many deps for my taste, Mouse involves XS. Perl is messy if your coding is messy. Why server side? Because DBI, Mojolicious and a good glue language for business logic already written in Perl. Would I pick it for something new? Maybe simple scripts or some quick web service or web API access tool or things involving text processing.

I use almost no third-party modules and write largely what I call "PHP style" Perl, so mostly $variable = SomeFunction($someOtherVariable);

I've had no issues with reading my own code, and others are able to follow along as well.

I admit that, because of its poetry-enabling flexibility, in terms of readability and maintainability foot-shooting, Perl is like an AK-47 with a full clip and no safety.

Reply on news.ycombinator.com