Come on, cheer up, it's not as bad as it seems :-)

Most functions start with:

sub mysub {
    my($first_param, $second_param, $and_so_on) = @_;

    # rest of the function
}
[download]

There's no need to specially highlight this way of passing parameters (as opposed to other languages) because... it's the only way that Perl supports, as perldoc perlsub will confirm you.

I think that, from a Practical Extraction and Report Language perspective, this made a lot of sense when he invented the language. From a KISS (Keep It Simple, Stupid) point of view, if you decide to implement only one way of passing parameters, it's better to implement the most useful one...

This does not mean that you should expect your variables to change all the time, or to contain unreliable data. If you check perldoc perlfunc, you'll see that only functions that need to change their parameters' values do so. As usual, Perl gives you enough flexibility to exercise common sense without draconian restrictions (or to hang yourself with your own rope). You can find similar ideas (it's up to the programmer to be clear and polite, not up to the language to force you to behave properly) in the Object Oriented design of Perl.

References should be considered as a way to flexibly handle data structures rather that a way to show that you're going to change the value held in the variable. One of the most compelling reason to use references is that, if you pass two lists to a function, they will be collapsed and flattened into @_. I think this is JAUPF (Just Another Useful Perl Feature) when you deal with a variable number of arguments, even though it was kind of annoying under some circumnstances in Perl 4. Well, today, if you want to keep the array separated, just pass a reference to them :-)

-- TMTOWTDI

Well, you picked a trivial example (scalars, specifically strings). In much of the Perl code you'll see, references are being passed around anyway, since plain old scalars have limited usefulness.

What you may want to do is to adopt a naming convention to signify subroutines that take scalar arguments and modify them.

You note that this was a disadvantage of Ruby; but note that Ruby has a convention of using a trailing '!' sign to denote methods that modify value types (especially) in place (i.e. chomp!() vs. chomp()). Maybe your Perl code could do something similar (i.e. truncate() vs. truncated(), perhaps).

Thank you both for cheering me up. Actually it wasn't that bad anyway. :-)

As for the ruby part: They constantly claim to be so very clean in design and everything (which perl doesn't :) and then such things annoy me. If a language was very good designed it should not allow the changing of a passed parameter without the caller explicitly allowing it IMHO, but that's probably just a matter of taste. Using just a convention is not good design because it can be avoided.
In my early C-days I "invented" a convention for myself which pretty much was OO design (without knowing anything about OO) and one would hardly find a compiler whichs tells me when I'm wrong with my own conventions *grin*

Since I (almost) always use the my ($val1,$val2) = @_;-way of passing args I'm not feeling endangered here.

Anyway, I like coding in perl most of the time (until it gets to complex datastructures), I kinda enjoy coding in ruby, too (which I do for just two weeks now) and so I'll switch desktops soon...

Regards...

Stefan