Don't kid yourself, nothing is ambiguous in a computer language. For some constructs, the outcome is just impossible to predict without running the code. :-)

Here's my rant.

{ prototype / parsing issues }
I fail to see your point here. There's nothing implicite going on here. sin takes an argument, and hence what follows is parsed as an expression (so the slash is the start of a regex). time doesn't take an argument, hence what follows is parsed as an operator (so the slash is a division).

The problem here, is that while perl is perfectly capable of interpreting these statements unambiguously, humans find it much harder. If you don't know sin() takes a single argument and time() takes none and that they're prototyped as such, you can run in to really weird and hard to find bugs. Now, for the core language, this isn't all that hard, because you can learn the built-ins you regulary use in a reasonable amount of time, and they're all pretty well documented.

If, on the other hand, you're dealing with user-defined functions, you really do not want to have to think about prototyping. IMO if a function has a prototype, it had better have a good reason for it, documented in the provided pod (and commented at the definition itself, if the pod is located somewhere else). The only reason I've ever used a prototype in serious code is to be able to do away with explicit sub { } declarations when passing an anonymous sub as an argument, and even then it's debatable,

Using shift() without arguments - it's used so much for reading subroutine arguments, that any reasonable perl programmer should know what it does. This doesn't mean I like it though; IMO shift() = shift(@_) is too much of a kludge (and inefficient, too) for something that's used so much (positional parameters).

As for "dropping" values off a subroutine - I agree with you there - it's a consistent, simple rule and perl programmers should know that subs return the value of the last expression. They'd get in trouble if they thought otherwise anyway.

"What should it profit a man, if he should win a flame war, yet lose his cool?"

In reply to Re^13: "advanced" Perl functions and maintainability by Joost
in thread "advanced" Perl functions and maintainability by geektron

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.