4 ms·

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 reaso

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.

forgotmypw17 6y ago
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.
philote 6y ago
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.
- thatwasunusual 6y ago
  > 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 https://dev.to/ovid/bringing-modern-oo-to-perl-51ak [2] https://metacpan.org/pod/Crypt::Curve25519 https://metacpan.org/pod/Crypt::Curve25519
  - Grinnz 6y ago
    There is an adoption process for truly inactive maintainers: http://neilb.org/2013/07/24/adopt-a-module.html 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.
    - thatwasunusual 6y ago
      > 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.

forgotmypw17 6y ago

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.

philote 6y ago

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.

thatwasunusual 6y ago
> 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 https://dev.to/ovid/bringing-modern-oo-to-perl-51ak [2] https://metacpan.org/pod/Crypt::Curve25519 https://metacpan.org/pod/Crypt::Curve25519
- Grinnz 6y ago
  There is an adoption process for truly inactive maintainers: http://neilb.org/2013/07/24/adopt-a-module.html 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.
  - thatwasunusual 6y ago
    > 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.