I fail to see how this is a good example of prototypes as a bad idea

%99.99 of the time passing to a subroutine a list of arguments ($x,$y,$z) and an array containing the same values @a=($x,$y,$z), are exactly equivelent. When you utilize prototypes this ceases to be true, and as such can end up requiring bizarre workarounds (but only after some head scratching).

Granted, the fact that you get weird results instead of a warning that this is a prototype violation is annoying, but still.

You admit its annoying, yet you piffle it away. No doubt you have quite a bit of experience with perl, and prototyping, and even still I bet when you bump into this annoyance you spend more time figuring out the weird behaviour than you needed. A beginner, or maintenance programmer working on your code probably wont have your skills or experience, and as such may end up wasting a lot of time figuring out what is going on. This I think is a Bad Thing, especially as its avoidable.

I'd solve this problem by using the same prototype for xprintf as for sprintf.

Ah yes, and lose the print to filehandle ability?

While the consequences are probably less in Perl than in C, making it harder to omit the format string and pass something not intended as such as the first argument is something you might be thankful for one day.

No, actually I've never been thankful for this and I suspect I never will, in fact more often than not ive been annoyed by it. Consider the keys() function. I rarely need the keys of a named hash, I very often need the keys of a reference to a hash. The fact that I have to deref my hashrefs only to have the internals transparently convert it back into a reference to work with it, goes against the common case, and is annoying. Not only that but using prototypes doesnt do what you think it does. Consider that a prototype of

perl -e "sub foo($$$){print @_} @x=(1,2,3); @y=(1,2); @z=(1); foo(@x,@
+y,@z);"
321
[download]

doesnt prevent me from providing three arrays there, (or frankly almost any other kind of object), but it does prevent me from passing my values elegantly from an array, and all kinds of other standard stuff. So I dont actually get the type of protection you suggest I do, while at the same time losing all the power and flexibility of perls variadic argument passing.

Basically operating under the misconception that prototypes are the same as function signatures is going to bite you and the users of your code. To paraphrase tilly on this subject if you know all this and still want to code that way then I probably dont want to work with you. Its most likely that our mental model of how perl should behave are so different that we would just end up tripping over each others code. I certainly would go mad with frustration if you prototyped your subs (with a few very specific exceptions).

When to use Prototypes? has a bunch of links to discussion on this subject. But the general consensus of those who understand prototypes in perl well, seems to be that they are generally a bad idea, and should only be used iff you understand exactly why it is that they are a bad idea, and still can justify it. (Such as to provide map style interfaces.)