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;
    }

If so, that's not the kind of flexibility I ever want to see in a programming language.

I hardly ever use shift like this, preferring instead the more readable argument copying:

    sub PaintHouse {
        my ($house, $color) = @_;
        ...

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.

I tried Go and Typescript and realized that the extra code is really, really worth the security, refactorability and safety.

I now frown on my beloved Python for being so permissive

    my $house = shift;
    my $color = shift;

    if (!$color) {
        $color = GetDefaultHouseColor();
    }

  my $house = shift;
  my $color = shift // GetDefaultHouseColor();

   sub pretty_print {
    my ($filename, $text, $text_width) = @_;

  #!/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);

Or use CPAN modules: https://metacpan.org/pod/signatures , https://metacpan.org/pod/Function::Parameters

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);

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.

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.

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.

Or you can use shift sequentially (my preferred style)

Or you can use traditional function signatures, which are behind a feature flag because of backwards compatibility.

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.

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.

Perl’s successor language, Raku, has sub arguments (even with lambdas) and optional type constraints.

[1] https://www.effectiveperlprogramming.com/2015/04/use-v5-20-s...