5 ms·

> but also that it had some limitations that have only become more glaring over the years. I don't have any real experience with Perl, so could you maybe expan

> but also that it had some limitations that have only become more glaring over the years. I don't have any real experience with Perl, so could you maybe expand a little? I'm curious about what you think the limitations are.

mkozlows 7y ago
I mentioned it in another comment, but a really obvious one is that functions in Perl don't have parameters. Every function just takes in a list, and can do whatever it wants with that list. This page gives a good overview of the situation: https://perl101.org/subroutines.html https://perl101.org/subroutines.html There's a kind of elegant flexibility to that, but it also makes it really hard to program reliably in the large, to build useful tooling, or even to glance at a function and know what you should pass it. Beyond that, classic Perl was full of things that make it quick to write small programs (as CGI scripts were at the time) without a lot of boilerplate, but which don't scale up. (Perl 6 is very different, and has an almost comically flexible/powerful function signature system (https://docs.perl6.org/type/Signature https://docs.perl6.org/type/Signature). Whether or not you like Perl 6's stuff, it's nothing at all like Perl 5's.)
- bmn__ 7y ago
  > functions in Perl don't have parameters Sorry, you are misinformed. That hasn't been true for a long time, see http://p3rl.org/Kavorka::Manual::Signatures http://p3rl.org/Kavorka::Manual::Signatures Other languages would kill for this kind of beyond-complete maximum overkill feature set. > This page gives a good overview of the situation: https://perl101.org/subroutines.html https://perl101.org/subroutines.html No, it doesn't. That page is not wrong, but incomplete and teaches the wrong stuff, wouldn't recommend. Instead see http://perl-tutorial.org/ http://perl-tutorial.org/ for recommended tutorials.
  - rubinelli 7y ago
    From the Perl 5.30 documentation: > WARNING: Subroutine signatures are experimental. The feature may be modified or removed in future versions of Perl. https://metacpan.org/pod/perlsub https://metacpan.org/pod/perlsub
    - mmcclimon 7y ago
      It's true that they're experimental, but it's extremely unlikely they'll be removed. The only reason they weren't stable in the most recent version of perl is because of some interactions with subroutine attributes (specifically, :lvalue) which needed some tweaking. We use them everywhere at Fastmail and they're great. Which is to say: a lot of the reason they're still experimental is because Perl's commitment to backward compatibility. Other languages might have said "oh well," but Perl 5 said "oh, an unintended consequence that might break real uses in the wild; we should wait another year."
  - iosonofuturista 7y ago
    So, the first tutorial on the list that you recommend has this page for functions[0]. It's more or less the same as GP's link. YOU are the one misinforming, it would seem. Granted, I don't work with perl (5, never tried 6) for about 15 years, but most criticism of it seems to align with my experiences back then. [0] http://mvp.kablamo.org/basics/functions/ http://mvp.kablamo.org/basics/functions/ Edit: The second [1] also recomends the @_ method, and the third [2] the shift method. Did you even read your own links? [1] https://perlmaven.com/subroutines-and-functions-in-perl https://perlmaven.com/subroutines-and-functions-in-perl [2] https://learnxinyminutes.com/docs/perl/ https://learnxinyminutes.com/docs/perl/ (search for subroutines)
  - marcosdumay 7y ago
    In my experience, I never got positional parameters to reliably work on Perl5. They were always buggy and would break with completely unrelated changes. On Perl6 those are officially supported, so I imagine they work.
- xorcist 7y ago
  There is a certain elegance to bare lists, as any lisp programmer will probably agree with. It enables the programmer to build their own abstractions as they go. That is also true for the overly simple object model of Perl 5, it is more like an OOP construction kit, which enables things like Moose which has for almost 15 years provided Perl 5 with a very flexible object model. It would be very interesting to know if anybody knows of similar systems for other languages? Large OO codebases can be downright nasty to navigate and while I have never had the opportunity to use something like Moose for large scale projects I imagine that's where it would shine.
empath75 7y ago
My experience is that Perl scripts other people wrote are impossible to understand. It made me never want to touch it again. I was handed several unmaintained ten year old Perl scripts to update and in every case I just rewrote it in python just because Perl gave me a migraine looking at it.
- alabamenhu 7y ago
  That's a problem with the people who wrote the script, though, not the language itself. Consider the difference between a minified JS script or one produced with emscripten and the code pre-minification. One is unintelligible guaranteed, the other … maybe haha. Unfortunately, what tended to happen is people would write one liners, and slowly expand the one liners into more complex one liners, and then integrate them into larger scripts without refactoring. Regex can triple that problem (thankfully Perl 6 allows you to write some of the most intelligible — seriously! — regex out there).
  - kjs3 7y ago
    That's a problem with the people who wrote the script, though, not the language itself. That's like the folks who say "the problem with C (buffer overflow, UB, etc.) isn't C, it's the people who write C". Which leads to at some point contemplative folks deciding either "this is happening so often, maybe it is the language" or "the majority of people writing this language are incompetent". While I've heard plenty of people in the C community espouse the latter view, having written C since K&R days, I think most people acknowledge it's a problematic language. But I don't have empirical evidence of a ratio. I wrote a ton of Perl <=5 back in the day. I'm pretty sure I know why I thought it was a good idea at the time. I know where I fall on the above. I know why I, and virtually everyone I know professionally, don't solve problems in Perl any more. But hey...maybe I'm just incompetent.
    - empath75 7y ago
      About the ten millionth time that someone had a security breach from exposing s3 buckets aws decided to look into if maybe something in their UX was bad instead of blaming the user every time. ‘User error’ is rarely a sufficient explanation for why something negative happens, particular when those users are professionals using a professional product. At some point one needs look at whether there is something in the product that causes those errors to happen or that doesn’t do enough to prevent them.
deleted 7y ago
[deleted]
hnick 7y ago
I use Perl in my day job and enjoy it a lot, but the biggest showstopper for me is that its greatest strength is its greatest weakness. "There's more than one way to do it", it's amazing at getting things working, it excels at writing "glue" programs to shim between bigger and slower moving parts, especially if they're throwaway hacks. However all that flexibility means that it's not possible to run static analysis with full confidence. Yes, tools exist - but it's been proven impossible for them to catch all cases, and this uncertainty carries real risks for critical business processes. When you have a code base encompassing a set of core modules, with hundreds of auxiliary programs using them across the business, then any attempt to update perl or its modules grinds to a halt. It's impossible to even enumerate which programs will be impacted by the change with confidence, let alone the effects of such a change. For details see "Perl Cannot Be Parsed: A Formal Proof" (https://www.perlmonks.org/?node_id=663393 https://www.perlmonks.org/?node_id=663393). You can mitigate the impact with coding style guides and code reviews but once the damage is done it's very difficult to untangle an existing code base that loads modules at run-time and makes full use of Perl's flexible nature in other ways.

mkozlows 7y ago

I mentioned it in another comment, but a really obvious one is that functions in Perl don't have parameters. Every function just takes in a list, and can do whatever it wants with that list. This page gives a good overview of the situation: https://perl101.org/subroutines.html https://perl101.org/subroutines.html There's a kind of elegant flexibility to that, but it also makes it really hard to program reliably in the large, to build useful tooling, or even to glance at a function and know what you should pass it. Beyond that, classic Perl was full of things that make it quick to write small programs (as CGI scripts were at the time) without a lot of boilerplate, but which don't scale up. (Perl 6 is very different, and has an almost comically flexible/powerful function signature system (https://docs.perl6.org/type/Signature https://docs.perl6.org/type/Signature). Whether or not you like Perl 6's stuff, it's nothing at all like Perl 5's.)

bmn__ 7y ago
> functions in Perl don't have parameters Sorry, you are misinformed. That hasn't been true for a long time, see http://p3rl.org/Kavorka::Manual::Signatures http://p3rl.org/Kavorka::Manual::Signatures Other languages would kill for this kind of beyond-complete maximum overkill feature set. > This page gives a good overview of the situation: https://perl101.org/subroutines.html https://perl101.org/subroutines.html No, it doesn't. That page is not wrong, but incomplete and teaches the wrong stuff, wouldn't recommend. Instead see http://perl-tutorial.org/ http://perl-tutorial.org/ for recommended tutorials.
- rubinelli 7y ago
  From the Perl 5.30 documentation: > WARNING: Subroutine signatures are experimental. The feature may be modified or removed in future versions of Perl. https://metacpan.org/pod/perlsub https://metacpan.org/pod/perlsub
  - mmcclimon 7y ago
    It's true that they're experimental, but it's extremely unlikely they'll be removed. The only reason they weren't stable in the most recent version of perl is because of some interactions with subroutine attributes (specifically, :lvalue) which needed some tweaking. We use them everywhere at Fastmail and they're great. Which is to say: a lot of the reason they're still experimental is because Perl's commitment to backward compatibility. Other languages might have said "oh well," but Perl 5 said "oh, an unintended consequence that might break real uses in the wild; we should wait another year."
- iosonofuturista 7y ago
  So, the first tutorial on the list that you recommend has this page for functions[0]. It's more or less the same as GP's link. YOU are the one misinforming, it would seem. Granted, I don't work with perl (5, never tried 6) for about 15 years, but most criticism of it seems to align with my experiences back then. [0] http://mvp.kablamo.org/basics/functions/ http://mvp.kablamo.org/basics/functions/ Edit: The second [1] also recomends the @_ method, and the third [2] the shift method. Did you even read your own links? [1] https://perlmaven.com/subroutines-and-functions-in-perl https://perlmaven.com/subroutines-and-functions-in-perl [2] https://learnxinyminutes.com/docs/perl/ https://learnxinyminutes.com/docs/perl/ (search for subroutines)
- marcosdumay 7y ago
  In my experience, I never got positional parameters to reliably work on Perl5. They were always buggy and would break with completely unrelated changes. On Perl6 those are officially supported, so I imagine they work.
xorcist 7y ago
There is a certain elegance to bare lists, as any lisp programmer will probably agree with. It enables the programmer to build their own abstractions as they go. That is also true for the overly simple object model of Perl 5, it is more like an OOP construction kit, which enables things like Moose which has for almost 15 years provided Perl 5 with a very flexible object model. It would be very interesting to know if anybody knows of similar systems for other languages? Large OO codebases can be downright nasty to navigate and while I have never had the opportunity to use something like Moose for large scale projects I imagine that's where it would shine.

empath75 7y ago

My experience is that Perl scripts other people wrote are impossible to understand. It made me never want to touch it again. I was handed several unmaintained ten year old Perl scripts to update and in every case I just rewrote it in python just because Perl gave me a migraine looking at it.

alabamenhu 7y ago
That's a problem with the people who wrote the script, though, not the language itself. Consider the difference between a minified JS script or one produced with emscripten and the code pre-minification. One is unintelligible guaranteed, the other … maybe haha. Unfortunately, what tended to happen is people would write one liners, and slowly expand the one liners into more complex one liners, and then integrate them into larger scripts without refactoring. Regex can triple that problem (thankfully Perl 6 allows you to write some of the most intelligible — seriously! — regex out there).
- kjs3 7y ago
  That's a problem with the people who wrote the script, though, not the language itself. That's like the folks who say "the problem with C (buffer overflow, UB, etc.) isn't C, it's the people who write C". Which leads to at some point contemplative folks deciding either "this is happening so often, maybe it is the language" or "the majority of people writing this language are incompetent". While I've heard plenty of people in the C community espouse the latter view, having written C since K&R days, I think most people acknowledge it's a problematic language. But I don't have empirical evidence of a ratio. I wrote a ton of Perl <=5 back in the day. I'm pretty sure I know why I thought it was a good idea at the time. I know where I fall on the above. I know why I, and virtually everyone I know professionally, don't solve problems in Perl any more. But hey...maybe I'm just incompetent.
  - empath75 7y ago
    About the ten millionth time that someone had a security breach from exposing s3 buckets aws decided to look into if maybe something in their UX was bad instead of blaming the user every time. ‘User error’ is rarely a sufficient explanation for why something negative happens, particular when those users are professionals using a professional product. At some point one needs look at whether there is something in the product that causes those errors to happen or that doesn’t do enough to prevent them.

deleted 7y ago

[deleted]

hnick 7y ago

I use Perl in my day job and enjoy it a lot, but the biggest showstopper for me is that its greatest strength is its greatest weakness. "There's more than one way to do it", it's amazing at getting things working, it excels at writing "glue" programs to shim between bigger and slower moving parts, especially if they're throwaway hacks. However all that flexibility means that it's not possible to run static analysis with full confidence. Yes, tools exist - but it's been proven impossible for them to catch all cases, and this uncertainty carries real risks for critical business processes. When you have a code base encompassing a set of core modules, with hundreds of auxiliary programs using them across the business, then any attempt to update perl or its modules grinds to a halt. It's impossible to even enumerate which programs will be impacted by the change with confidence, let alone the effects of such a change. For details see "Perl Cannot Be Parsed: A Formal Proof" (https://www.perlmonks.org/?node_id=663393 https://www.perlmonks.org/?node_id=663393). You can mitigate the impact with coding style guides and code reviews but once the damage is done it's very difficult to untangle an existing code base that loads modules at run-time and makes full use of Perl's flexible nature in other ways.