Perl Subroutine Signatures Opinion Blog
I have great respect for Perl developers.
I am always grateful for the work.
On the other hand, I have a very strong concern in the future of Perl.
I created a site for my opinions on subroutine signatures so that themes would not be missed in the discussion.
Perl Subroutine Signatures Opinion Blog
I have no final authority. I pray Perl developers make a good decision.
I'm Perl Programmer. I LOVE Perl. I want to contribute Perl community and Perl users.
"Why we want subroutine signatures?"
Because I'm lazy.
I don't want to write separate instruction for args unpacking.
I don't want to manually check for mandatory params presence.
I don't want to implement named params validation.
I need multi subs so i won't have to invent artificial names for methods that do the same stuff.
The list goes on...
If I can do short and sweet "sub foo ( Str:D :$name! ) { ... }" then I'm happy. More convenient language won my heart. Simple as that.
I agree with your blog post. Trying to "sell" language without signatures nowadays is like trying to sell a car without electric motor starter. It does not matter how many good tutorials of "How to use hand crank to start the engine" you have. It. Will. Not. Sell.
Hi Yuki, I agree with you. When I started to use Perl, that must be 17 or 18 years ago, I found that using @_ or @ARGV was just fine.
And when subroutine signatures were introduced, I really didn't care that much about them. But having used Perl 6 (now known as Raku) for quite a few years by now, I realized how useful subroutine signatures can be. Sometimes, a subroutine will not even need to have a body, as the signature will do everything that you need. Now, of course, Raku (or P6) is much more type-oriented than P5, so that useful signatures are more difficult to implement in P5. But I agree with you on the bottom line.
Because I'm lazy.
OK!
If I and you are lazy, we don't want to learn a lot of syntax.
It would be nice to add a grammar that is just the right size for convenience and less learning.
And
Perl have a history and Perl users on Unix/Linux and Text Processing have long convention.
I hope well balanced choice instead of all possible features.
Raku have a lot of built-in types and type checking. This is Raku design.
These effect PHP, Python, TypeScript.
On the other hand, there are long time Perl users(which contain me) expect and feel attractive that Perl is pure dynamic language in core features.