6 ms·

subroutine signatures look pretty interesting to me, albeit experimental. https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlsub.pod#Signatures https://

by jbert 12y ago

subroutine signatures look pretty interesting to me, albeit experimental. https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlsub.pod#Signatures https://metacpan.org/pod/release/RJBS/perl-5.20.0/pod/perlsu... edit: and the copy-on-write string concatenating has the potential to speed up a lot of code, I think.

nnq 12y ago
'subroutine signatures' is such a basic and expected feature that it isn't even named in other languages. People just assume "it has to be there"... This is what makes people run way from Perl nowadays. I recently tried to convince someone that Perl is superior to PHP. When he saw the sub and $_ and shift he was like "I'm not touching this with a ten foot pole". And there was nothing I could say. Compared to something like PHP 5.4, Perl looks like "mildly evolved stone age shell scripting with some chinese characters in it". And I say this saddened because I still wish PHP wouldn't have won the "battle for the web" over Perl.
- emmelaich 12y ago
  I have to agree. Perl was an early love of mine. I was excited when subroutine prototypes came to Perl. Sadly they were almost completly unlike prototypes in any other language and no-one used them. Subroutine signatures look like another attempt. Sorry but too late.
  - Mithaldu 12y ago
    You were excited in 1996-Feb-29 when 5.002 was released? Also, prototypes are widely used as syntax hints for the perl compiler and were never meant as signatures.
    - _quasimodo 12y ago
      You were excited in 1996-Feb-29 when 5.002 was released? Not everyone on hn is in their early twenties, i suppose.
      - emmelaich 12y ago
        Exactly. Well hell, I did most of my time doing 'big' perl (as distinct from a better awk) with 4.019 and 4.036. Now _they_ were fine vintages :-)
- Mithaldu 12y ago
  > 'subroutine signatures' is such a basic and expected feature that it isn't even named in other languages. People just assume "it has to be there"... That is an understandable, yet still naive statement. In the implementation of signatures one has to make MANY decisions concerning the trade-offs of syntax, available features and performance impacts of signatures. The discussions about what was needed and wanted for those experimental signatures were massive and in no way trivial. Further, asking a PHP person to evaluate another language is often fruitless, as their lifelihood is usually closely tied to that language; and they are largely unaware of the systemic ailments plagueing PHP, thus unable to draw a useful comparison.
  - valleyer 12y ago
    Wow, what happened between paragraphs 1 and 2? You went from making a good point to insulting a whole class of people. I’m no fan of PHP, but I could hardly bring myself to insult everyone who uses it...
    - Mithaldu 12y ago
      Simply put, i've been in this business since 2001, have done 3 years of PHP myself, and have never met a PHP programmer who liked PHP and wasn't an exact fit of the description i gave. For a time there even was a PHP developer who i thought was very good, but that judgement turned out to be borne of my ignorance when that person turned out to be unwilling and uncapable to consider the advantages of automated testing. Some people might not like to hear this, but over a decade of experience has convinced me that this is sad and simple fact. The post i was responding to tried to use the reactions of a PHP programmer to make a factual statement about Perl without even attempting to consider the possibility that said programmer might be both not experienced enough, and inherently unwilling to accept Perl as even being good. I was not aiming to insult, though some might certainly feel offended, but explain why the poster above failed to make a useful point.
- BugBrother 12y ago
  Check CPAN, there are good signature modules. (No links; they have been posted often, I write on an iPad while eating pizza without fork/knife.) Edit: After pizza, clean hands. :-) Just google "cpan method signatures" or similar. The extensible syntax of Perl is really cool. Here is a Moose specific example with type constraints: http://search.cpan.org/~ether/MooseX-Method-Signatures-0.47/lib/MooseX/Method/Signatures.pm http://search.cpan.org/~ether/MooseX-Method-Signatures-0.47/...
- jbert 12y ago
  Well, it's just that perl for: sub foo($x, $y, $z) ... has up to now been written: sub foo { my ($x, $y, $z) = @_; ... which is annoying boilerplate I agree, but actually pretty regular. [You mean language xxx has two different ways to declare subroutine lexical vars?] The people who want to hate perl will continue to hate it. After the list of reasons they dislike it are resolved, they'll come up with new ones and/or point to "it's not popular enough" (while simultaneously embracing a brand new language which is significantly less popular).
  - logicallee 12y ago
    After the list of reasons people dislike it are resolved, it won't be Perl. It's fine to start calling a modern language Perl, even though the modern language has standard syntax that no current Perl programmer would consider Perl, and standard computer science constructs like OOP and Unicode etc that require coding against a different abstraction than Perl. Nothing wrong with that. But the new Perl would have as little to do with the old Perl as an iPad has with an Apple ][. It would not be the same language in any meaningful sense, beyond branding.
    - BugBrother 12y ago
      >>After the list of reasons people dislike it are resolved, it won't be Perl. So "people" will never like Perl? Good argument! :-) Well, what are the reasons to dislike Perl, then? >>OOP and Unicode etc that require coding against a different abstraction than Perl. 1. Perl, with Moose, has arguably the best OO of the common scripting languages (inspired by the Common Lisp Object System). 2. Perl has probably the best Unicode support of the common scripting languages. Basic advice: To be a language war troll you need to know enough so you can make people angry. If they laugh at you, it is a failure.
      - logicallee 12y ago
        I'm serious in the sense that some of the extreme syntax-sugar and leniency, more than one way to do it, etc, that Perl is loved for are the reasons that people dislike it in a modern context, and these are to simply be removed with no equivalent replacement. If you move toward a readable standard "Perl" that supports (only) modern coding styles, you will have something that old Perl users wouldn't really recognize as Perl. Consider something as simple as: https://news.ycombinator.com/item?id=4774426 https://news.ycombinator.com/item?id=4774426 This is "Perl" and recognized as such... but my suggestion of calling some entirely different language Perl in the future would make this essentially a non-script. The same is true for most syntax, as well as a large amount of fundamental structures, regexes, etc. I'll speak following my analogy: I'll call Perl the Apple ][ and some language that wouldn't be recognized as Perl by today's Perl users, but which should be called Perl in the future I will call the iPad. For example, it's fairly clear that the iPad language should have every single variable be a full object. The Apple ][ does not force this. Likeweise, classes and OOP would not be optional on an iPad, but a fundamental part of writing any program. But on the Apple ][ it is optional. On the iPad it is clear that $_ would be meaningless and not used, ever. It's a syntax error. On the iPad all source code is UTF-8 or Unicode, and all built-in standard operators including the iPad version of a regular expression (which uses almost none of the syntax of the Apple ][ language natively operate on UTF-8 or Unicode. The iPad language is longer and has more explicit, longer keywords. The syntax itself is extremely orthogonal and you could describe the entirety of it to anyone who has programmed in any language in a relatively low number of slides, and they can just start coding. It is fully readable to someone who has never read the iPad language, i.e. if you were to read a numerical algorithm or datamining algorithm that was just talked about in a textbook, you wouldn't be distracted by the textbook having to explain what the iPad is. It speaks for itself. This explicitness is part of the language; there is no way to write one-liners or extremely concise hacks the way the Apple ][ could. The iPad language lives on the web. It has primitives for handling a client connection as well as a standard framework for rich client-side connections. A persistent connection over http is as everyday as standard input and standard output was on the Apple ][. And boy can you Google this. The Apple ][ could have a syntactic structure, special variables [1] that were almost impossible to Google. All sorts of Context. The iPad language has no such context. There is very little you can set to change the fundamental syntax, no way to change the default index on arrays and related things, or any such high-context things or syntactic context. There is just one context, and everything that is done in a program is spelled-out and eminently Google-able. You never have to ask what something actually does, on a syntactic level, or figure it out by running it. You don't have to spend even six days to get to this level at the language: an afternoon tells you all the context that you will ever need. Anything beyond that, you can Google. Sure, you may not understand what a piece of code does on a higher level. What happens if you apply a fourier transform to _____. It may not be obvious. But syntactically, it is extremely easy to read off what you're doing. No more difficult than reading off pseudocode in a textbook. And the language is succinct. The basic syntax is so small, so orthogonal, that you can be handed a 20-page description, having never seen an iPad language, and be able to more or less implement a version in the language of your choice, in a few weeks, without any further information or context. There is not a lot of magic involved. Of course, the only thing that the iPad language will have in common with the Apple ][ is just the brand (Perl)..or the fact that at some level they're both turing-complete. The future of Perl is calling an iPad language that is unrecognizable to any current user of Perl, Perl. Gone are the days of syntactic sugar or short little idioms. [1]http://www.kichwa.com/quik_ref/spec_variables.html http://www.kichwa.com/quik_ref/spec_variables.html

by jbert 12y ago

nnq 12y ago

'subroutine signatures' is such a basic and expected feature that it isn't even named in other languages. People just assume "it has to be there"... This is what makes people run way from Perl nowadays. I recently tried to convince someone that Perl is superior to PHP. When he saw the sub and $_ and shift he was like "I'm not touching this with a ten foot pole". And there was nothing I could say. Compared to something like PHP 5.4, Perl looks like "mildly evolved stone age shell scripting with some chinese characters in it". And I say this saddened because I still wish PHP wouldn't have won the "battle for the web" over Perl.

emmelaich 12y ago
I have to agree. Perl was an early love of mine. I was excited when subroutine prototypes came to Perl. Sadly they were almost completly unlike prototypes in any other language and no-one used them. Subroutine signatures look like another attempt. Sorry but too late.
- Mithaldu 12y ago
  You were excited in 1996-Feb-29 when 5.002 was released? Also, prototypes are widely used as syntax hints for the perl compiler and were never meant as signatures.
  - _quasimodo 12y ago
    You were excited in 1996-Feb-29 when 5.002 was released? Not everyone on hn is in their early twenties, i suppose.
    - emmelaich 12y ago
      Exactly. Well hell, I did most of my time doing 'big' perl (as distinct from a better awk) with 4.019 and 4.036. Now _they_ were fine vintages :-)
Mithaldu 12y ago
> 'subroutine signatures' is such a basic and expected feature that it isn't even named in other languages. People just assume "it has to be there"... That is an understandable, yet still naive statement. In the implementation of signatures one has to make MANY decisions concerning the trade-offs of syntax, available features and performance impacts of signatures. The discussions about what was needed and wanted for those experimental signatures were massive and in no way trivial. Further, asking a PHP person to evaluate another language is often fruitless, as their lifelihood is usually closely tied to that language; and they are largely unaware of the systemic ailments plagueing PHP, thus unable to draw a useful comparison.
- valleyer 12y ago
  Wow, what happened between paragraphs 1 and 2? You went from making a good point to insulting a whole class of people. I’m no fan of PHP, but I could hardly bring myself to insult everyone who uses it...
  - Mithaldu 12y ago
    Simply put, i've been in this business since 2001, have done 3 years of PHP myself, and have never met a PHP programmer who liked PHP and wasn't an exact fit of the description i gave. For a time there even was a PHP developer who i thought was very good, but that judgement turned out to be borne of my ignorance when that person turned out to be unwilling and uncapable to consider the advantages of automated testing. Some people might not like to hear this, but over a decade of experience has convinced me that this is sad and simple fact. The post i was responding to tried to use the reactions of a PHP programmer to make a factual statement about Perl without even attempting to consider the possibility that said programmer might be both not experienced enough, and inherently unwilling to accept Perl as even being good. I was not aiming to insult, though some might certainly feel offended, but explain why the poster above failed to make a useful point.
BugBrother 12y ago
Check CPAN, there are good signature modules. (No links; they have been posted often, I write on an iPad while eating pizza without fork/knife.) Edit: After pizza, clean hands. :-) Just google "cpan method signatures" or similar. The extensible syntax of Perl is really cool. Here is a Moose specific example with type constraints: http://search.cpan.org/~ether/MooseX-Method-Signatures-0.47/lib/MooseX/Method/Signatures.pm http://search.cpan.org/~ether/MooseX-Method-Signatures-0.47/...
jbert 12y ago
Well, it's just that perl for: sub foo($x, $y, $z) ... has up to now been written: sub foo { my ($x, $y, $z) = @_; ... which is annoying boilerplate I agree, but actually pretty regular. [You mean language xxx has two different ways to declare subroutine lexical vars?] The people who want to hate perl will continue to hate it. After the list of reasons they dislike it are resolved, they'll come up with new ones and/or point to "it's not popular enough" (while simultaneously embracing a brand new language which is significantly less popular).
- logicallee 12y ago
  After the list of reasons people dislike it are resolved, it won't be Perl. It's fine to start calling a modern language Perl, even though the modern language has standard syntax that no current Perl programmer would consider Perl, and standard computer science constructs like OOP and Unicode etc that require coding against a different abstraction than Perl. Nothing wrong with that. But the new Perl would have as little to do with the old Perl as an iPad has with an Apple ][. It would not be the same language in any meaningful sense, beyond branding.
  - BugBrother 12y ago
    >>After the list of reasons people dislike it are resolved, it won't be Perl. So "people" will never like Perl? Good argument! :-) Well, what are the reasons to dislike Perl, then? >>OOP and Unicode etc that require coding against a different abstraction than Perl. 1. Perl, with Moose, has arguably the best OO of the common scripting languages (inspired by the Common Lisp Object System). 2. Perl has probably the best Unicode support of the common scripting languages. Basic advice: To be a language war troll you need to know enough so you can make people angry. If they laugh at you, it is a failure.
    - logicallee 12y ago
      I'm serious in the sense that some of the extreme syntax-sugar and leniency, more than one way to do it, etc, that Perl is loved for are the reasons that people dislike it in a modern context, and these are to simply be removed with no equivalent replacement. If you move toward a readable standard "Perl" that supports (only) modern coding styles, you will have something that old Perl users wouldn't really recognize as Perl. Consider something as simple as: https://news.ycombinator.com/item?id=4774426 https://news.ycombinator.com/item?id=4774426 This is "Perl" and recognized as such... but my suggestion of calling some entirely different language Perl in the future would make this essentially a non-script. The same is true for most syntax, as well as a large amount of fundamental structures, regexes, etc. I'll speak following my analogy: I'll call Perl the Apple ][ and some language that wouldn't be recognized as Perl by today's Perl users, but which should be called Perl in the future I will call the iPad. For example, it's fairly clear that the iPad language should have every single variable be a full object. The Apple ][ does not force this. Likeweise, classes and OOP would not be optional on an iPad, but a fundamental part of writing any program. But on the Apple ][ it is optional. On the iPad it is clear that $_ would be meaningless and not used, ever. It's a syntax error. On the iPad all source code is UTF-8 or Unicode, and all built-in standard operators including the iPad version of a regular expression (which uses almost none of the syntax of the Apple ][ language natively operate on UTF-8 or Unicode. The iPad language is longer and has more explicit, longer keywords. The syntax itself is extremely orthogonal and you could describe the entirety of it to anyone who has programmed in any language in a relatively low number of slides, and they can just start coding. It is fully readable to someone who has never read the iPad language, i.e. if you were to read a numerical algorithm or datamining algorithm that was just talked about in a textbook, you wouldn't be distracted by the textbook having to explain what the iPad is. It speaks for itself. This explicitness is part of the language; there is no way to write one-liners or extremely concise hacks the way the Apple ][ could. The iPad language lives on the web. It has primitives for handling a client connection as well as a standard framework for rich client-side connections. A persistent connection over http is as everyday as standard input and standard output was on the Apple ][. And boy can you Google this. The Apple ][ could have a syntactic structure, special variables [1] that were almost impossible to Google. All sorts of Context. The iPad language has no such context. There is very little you can set to change the fundamental syntax, no way to change the default index on arrays and related things, or any such high-context things or syntactic context. There is just one context, and everything that is done in a program is spelled-out and eminently Google-able. You never have to ask what something actually does, on a syntactic level, or figure it out by running it. You don't have to spend even six days to get to this level at the language: an afternoon tells you all the context that you will ever need. Anything beyond that, you can Google. Sure, you may not understand what a piece of code does on a higher level. What happens if you apply a fourier transform to _____. It may not be obvious. But syntactically, it is extremely easy to read off what you're doing. No more difficult than reading off pseudocode in a textbook. And the language is succinct. The basic syntax is so small, so orthogonal, that you can be handed a 20-page description, having never seen an iPad language, and be able to more or less implement a version in the language of your choice, in a few weeks, without any further information or context. There is not a lot of magic involved. Of course, the only thing that the iPad language will have in common with the Apple ][ is just the brand (Perl)..or the fact that at some level they're both turing-complete. The future of Perl is calling an iPad language that is unrecognizable to any current user of Perl, Perl. Gone are the days of syntactic sugar or short little idioms. [1]http://www.kichwa.com/quik_ref/spec_variables.html http://www.kichwa.com/quik_ref/spec_variables.html