5 ms·

My reason to not like Perl is that the language does not support function arguments explicitly. What? People wrote web apps in a language with bash-style argume

by jitl 5y ago

My reason to not like Perl is that the language does not support function arguments explicitly. What? People wrote web apps in a language with bash-style argument handling. You have to shift your arguments off the @_ argv array. That, and my student job was maintaining ISP software written in the 90s in Perl by several generations of new programmers. It was very educational. :)

socialist_coder 5y ago
That's one of my complaints too. But, you can use this kind of trick to get around it and make your code more readable: sub pretty_print { my ($filename, $text, $text_width) = @_; Not as good as if it was just built into the language itself but better then the alternative.
- chovybizzass 5y ago
  Its no different than es6+: `const { foo, bar, baz } = someObject;`
civilized 5y ago
This is a unique and staggeringly awful aspect of Perl. What other mainstream language lacks function arguments?
- bloblaw 5y ago
  Perl doesn't lack function arguments. You can pass various arguments to a subroutine like you do in any other programming language and they can be acessed inside the function using the special array @_. Thus the first argument to the function is in $_[0], the second is in $_[1], and so on. #!/usr/bin/perl # Function definition sub Average { # get total number of arguments passed. $n = scalar(@_); $sum = 0; foreach $item (@_) { $sum += $item; } $average = $sum / $n; print "Average for the given numbers : $average\n"; } # Function call Average(10, 20, 30); reference: https://www.tutorialspoint.com/perl/perl_subroutines.htm https://www.tutorialspoint.com/perl/perl_subroutines.htm
  - civilized 5y ago
    A generic, obscurely named array that you can use to pass data into subroutines isn't what anyone ordinarily means by function arguments. The writer of a function should be able to specify multiple named formal arguments within the function signature. Again, this is a basic feature all other mainstream languages have.
    - bloblaw 5y ago
      It sounds like you are unfamiliar with this style, not that it "isn't what anyone ordinarily means". Bash, Ruby, and Perl all support this style of argument passing. Perl does not have named formal parameters, but instead supports passing arguments as lists / arrays. You can pass any number of arguments of any supported type this way. If you've never programmed in a language that supports passing arguments in this manner, it will seem foreign. However, argument passing in this manner has many benefits (eg easy to extend a function def, can easily add optional / req params with basic checking within subroutine) and after 15 min of doing it this way you don't really think about it again.
      - civilized 5y ago
        It sounds like a subset of Python where "def fun(*args)" is your only option for a function signature. And you have to do all the work of pulling apart *args to get the data you want, including manually throwing errors if you didn't get what you expected. Python lets your function signature have required positional arguments, variable positional arguments (*args) AND variable keyword args (**kwargs). And everyone uses these features because it makes programming much more pleasant and manageable. **kwargs is especially important for complex packages like sklearn or pandas, which have many functions with lots of options that often change with version. It would be utterly unimaginable to build these magnificent packages while chained to the underpowered, antiquated Perl style of argument passing.
        bloblaw 5y ago
        > And you have to do all the work of pulling apart *args to get the data you want, including manually throwing errors if you didn't get what you expected. Respectfully, isn't this just the same amount of work to define named function arguments? In Perl you do the work of unpacking the array and then validating data. In Python you have the work of defining the function arguments and then validating the received data. > Python lets your function signature have required positional arguments, variable positional arguments (*args) AND variable keyword args (*kwargs). And everyone uses these features because it makes programming much more pleasant and manageable. Perl supports this as well. Same functionality as *kwargs is found by passing a hash to a subroutine. And of course *args is analogous to how Perl subroutines were designed to work.
- redis_mlc 5y ago
  No, it's not awful. See the above list assignment technique in pretty_print() to get the args. Perl did experiment with function prototypes as a way of typing, but that was past tense.
- colin_mccabe 5y ago
  > What other mainstream language lacks function arguments? Assembly language doesn't have function arguments. You just decide what to put in each register when you begin the function. So you can remember that eax is the count, ebx is the pointer to the buffer, or whatever. Or if you're a nice programmer you write a comment there.
- tdeck 5y ago
  The various shell languages (e.g. Bash) are probably the inspiration, although when Perl was written it was already pretty hard to justify.
- onei 5y ago
  The main one I use regularly with this 'feature' is a shell. I'd imagine it's where Perl got the idea from. In reality, function arguments are an abstraction. You push your arguments onto a stack and read them off that stack. It's just that so many modern languages have that abstraction that we forget how it works underneath.
- labster 5y ago
  Perl doesn’t lack function arguments, it’s just hidden behind a feature flag until the next annual release. A feature change had to be reverted to the more stable prior version but it’s de facto stable now. Perl’s successor language, Raku, has sub arguments (even with lambdas) and optional type constraints.
- akho 5y ago
  Shell. You can approach Perl viewing it as an alternative to Python / Ruby / JavaScript, but that’s not the only way to look at it. Another is to look at it as a sh / sed / awk upgrade, and it absolutely excels in that. It’s easy to ‘shell out’, Perl adds more convenient data structures and keeps affordances to play well with other tools. It’s also very backwards-compatible, so if you want a small script for personal use that will not need you to do maintenance busywork — base Perl is the way to go.
eCa 5y ago
Signatures are experimental, see[1]. Unfortunately, that means that it requires boilerplate. [1] https://www.effectiveperlprogramming.com/2015/04/use-v5-20-subroutine-signatures/ https://www.effectiveperlprogramming.com/2015/04/use-v5-20-s...
forgotmypw17 5y ago
What you're describing is called subroutine signatures in Perl, an "experimental" feature I remember using on production in 2004. At the time, I thought it made a lot of sense, after using other languages where this feature was standard and required. However, I've since abandoned its use in Perl, because the traditional Perl way is much more flexible. I do try to keep my `shift` statements towards the top of a sub, however. sub PaintHouse { my $house = shift; my $color = shift; if (!$house || !$color) { WriteLog('PaintHouse: warning: sanity check failed'); return ''; } print "painting $house with $color paint"; return 1; }
- motogpjimbo 5y ago
  I've never written Perl code, but I'm going to make a wild stab in the dark here and guess that the "flexibility" you're talking about involves putting the `shift` keyword half way down the function body, putting it inside `if` statements, putting it inside loops etc? If so, that's not the kind of flexibility I ever want to see in a programming language.
  - arunix 5y ago
    No, the flexibility on offer is that you get regular arguments, optional arguments, variable numbers of arguments and keyword/named arguments all as a result of this mechanism. I hardly ever use shift like this, preferring instead the more readable argument copying: sub PaintHouse { my ($house, $color) = @_; ...
    - motogpjimbo 5y ago
      I work in a legacy codebase (in PHP, not Perl) where the previous developer often wrote functions to be excessively flexible with regards to their parameters - many of the parameters are optional, some of them behave differently depending on whether they're passed as strings, integers or booleans, arrays can be passed as either flat or associative arrays, etc. I'm sure he thought he was making his functions easier to reuse in different contexts but in practice the actual result is that it's impossible to modify any of those functions without considering _every possible_ combination of parameters that could be passed in. Often what should be a simple fix becomes something much more time consuming. There is a place for flexibility in software design, but the parameter list of a function is not one of those places in my opinion.
drran 5y ago
Use experimental Perl feature: #!/usr/bin/perl use Modern::Perl '2015'; use feature qw(signatures); no warnings qw(experimental::signatures); sub foo($bar, $baz) { $bar+$baz } say foo(40, 2); See `man feature` for details. Or use CPAN modules: https://metacpan.org/pod/signatures https://metacpan.org/pod/signatures , https://metacpan.org/pod/Function::Parameters https://metacpan.org/pod/Function::Parameters

by jitl 5y ago

socialist_coder 5y ago

That's one of my complaints too. But, you can use this kind of trick to get around it and make your code more readable: sub pretty_print { my ($filename, $text, $text_width) = @_; Not as good as if it was just built into the language itself but better then the alternative.

chovybizzass 5y ago
Its no different than es6+: `const { foo, bar, baz } = someObject;`

civilized 5y ago

This is a unique and staggeringly awful aspect of Perl. What other mainstream language lacks function arguments?

bloblaw 5y ago
Perl doesn't lack function arguments. You can pass various arguments to a subroutine like you do in any other programming language and they can be acessed inside the function using the special array @_. Thus the first argument to the function is in $_[0], the second is in $_[1], and so on. #!/usr/bin/perl # Function definition sub Average { # get total number of arguments passed. $n = scalar(@_); $sum = 0; foreach $item (@_) { $sum += $item; } $average = $sum / $n; print "Average for the given numbers : $average\n"; } # Function call Average(10, 20, 30); reference: https://www.tutorialspoint.com/perl/perl_subroutines.htm https://www.tutorialspoint.com/perl/perl_subroutines.htm
- civilized 5y ago
  A generic, obscurely named array that you can use to pass data into subroutines isn't what anyone ordinarily means by function arguments. The writer of a function should be able to specify multiple named formal arguments within the function signature. Again, this is a basic feature all other mainstream languages have.
  - bloblaw 5y ago
    It sounds like you are unfamiliar with this style, not that it "isn't what anyone ordinarily means". Bash, Ruby, and Perl all support this style of argument passing. Perl does not have named formal parameters, but instead supports passing arguments as lists / arrays. You can pass any number of arguments of any supported type this way. If you've never programmed in a language that supports passing arguments in this manner, it will seem foreign. However, argument passing in this manner has many benefits (eg easy to extend a function def, can easily add optional / req params with basic checking within subroutine) and after 15 min of doing it this way you don't really think about it again.
    - civilized 5y ago
      It sounds like a subset of Python where "def fun(*args)" is your only option for a function signature. And you have to do all the work of pulling apart *args to get the data you want, including manually throwing errors if you didn't get what you expected. Python lets your function signature have required positional arguments, variable positional arguments (*args) AND variable keyword args (**kwargs). And everyone uses these features because it makes programming much more pleasant and manageable. **kwargs is especially important for complex packages like sklearn or pandas, which have many functions with lots of options that often change with version. It would be utterly unimaginable to build these magnificent packages while chained to the underpowered, antiquated Perl style of argument passing.
      - bloblaw 5y ago
        > And you have to do all the work of pulling apart *args to get the data you want, including manually throwing errors if you didn't get what you expected. Respectfully, isn't this just the same amount of work to define named function arguments? In Perl you do the work of unpacking the array and then validating data. In Python you have the work of defining the function arguments and then validating the received data. > Python lets your function signature have required positional arguments, variable positional arguments (*args) AND variable keyword args (*kwargs). And everyone uses these features because it makes programming much more pleasant and manageable. Perl supports this as well. Same functionality as *kwargs is found by passing a hash to a subroutine. And of course *args is analogous to how Perl subroutines were designed to work.
redis_mlc 5y ago
No, it's not awful. See the above list assignment technique in pretty_print() to get the args. Perl did experiment with function prototypes as a way of typing, but that was past tense.
colin_mccabe 5y ago
> What other mainstream language lacks function arguments? Assembly language doesn't have function arguments. You just decide what to put in each register when you begin the function. So you can remember that eax is the count, ebx is the pointer to the buffer, or whatever. Or if you're a nice programmer you write a comment there.
tdeck 5y ago
The various shell languages (e.g. Bash) are probably the inspiration, although when Perl was written it was already pretty hard to justify.
onei 5y ago
The main one I use regularly with this 'feature' is a shell. I'd imagine it's where Perl got the idea from. In reality, function arguments are an abstraction. You push your arguments onto a stack and read them off that stack. It's just that so many modern languages have that abstraction that we forget how it works underneath.
labster 5y ago
Perl doesn’t lack function arguments, it’s just hidden behind a feature flag until the next annual release. A feature change had to be reverted to the more stable prior version but it’s de facto stable now. Perl’s successor language, Raku, has sub arguments (even with lambdas) and optional type constraints.
akho 5y ago
Shell. You can approach Perl viewing it as an alternative to Python / Ruby / JavaScript, but that’s not the only way to look at it. Another is to look at it as a sh / sed / awk upgrade, and it absolutely excels in that. It’s easy to ‘shell out’, Perl adds more convenient data structures and keeps affordances to play well with other tools. It’s also very backwards-compatible, so if you want a small script for personal use that will not need you to do maintenance busywork — base Perl is the way to go.

eCa 5y ago

Signatures are experimental, see[1]. Unfortunately, that means that it requires boilerplate. [1] https://www.effectiveperlprogramming.com/2015/04/use-v5-20-subroutine-signatures/ https://www.effectiveperlprogramming.com/2015/04/use-v5-20-s...

forgotmypw17 5y ago

What you're describing is called subroutine signatures in Perl, an "experimental" feature I remember using on production in 2004. At the time, I thought it made a lot of sense, after using other languages where this feature was standard and required. However, I've since abandoned its use in Perl, because the traditional Perl way is much more flexible. I do try to keep my `shift` statements towards the top of a sub, however. sub PaintHouse { my $house = shift; my $color = shift; if (!$house || !$color) { WriteLog('PaintHouse: warning: sanity check failed'); return ''; } print "painting $house with $color paint"; return 1; }

motogpjimbo 5y ago
I've never written Perl code, but I'm going to make a wild stab in the dark here and guess that the "flexibility" you're talking about involves putting the `shift` keyword half way down the function body, putting it inside `if` statements, putting it inside loops etc? If so, that's not the kind of flexibility I ever want to see in a programming language.
- arunix 5y ago
  No, the flexibility on offer is that you get regular arguments, optional arguments, variable numbers of arguments and keyword/named arguments all as a result of this mechanism. I hardly ever use shift like this, preferring instead the more readable argument copying: sub PaintHouse { my ($house, $color) = @_; ...
  - motogpjimbo 5y ago
    I work in a legacy codebase (in PHP, not Perl) where the previous developer often wrote functions to be excessively flexible with regards to their parameters - many of the parameters are optional, some of them behave differently depending on whether they're passed as strings, integers or booleans, arrays can be passed as either flat or associative arrays, etc. I'm sure he thought he was making his functions easier to reuse in different contexts but in practice the actual result is that it's impossible to modify any of those functions without considering _every possible_ combination of parameters that could be passed in. Often what should be a simple fix becomes something much more time consuming. There is a place for flexibility in software design, but the parameter list of a function is not one of those places in my opinion.

drran 5y ago

Use experimental Perl feature: #!/usr/bin/perl use Modern::Perl '2015'; use feature qw(signatures); no warnings qw(experimental::signatures); sub foo($bar, $baz) { $bar+$baz } say foo(40, 2); See `man feature` for details. Or use CPAN modules: https://metacpan.org/pod/signatures https://metacpan.org/pod/signatures , https://metacpan.org/pod/Function::Parameters https://metacpan.org/pod/Function::Parameters