Re: Re: Re: On Scalar Context

[flyingmoose]

This is a problem with the Perl mindset. DWIM has no value when "Do What I Mean" means different things to different people. Hence, there should be well defined concepts mandating that methods that normally output an array shouldn't do things that vary behavior based on the LHS. Most languages don't have return-type overloading with the same arguments, and I consider this a good thing. Perl, somehow, thinks it is different. I love Perl, but I don't believe in covering for it's faults -- or saying that the faults are really DWIMerry or features.

[adrianh]

Most languages don't have return-type overloading with the same arguments, and I consider this a good thing.

Why?

I love Perl, but I don't believe in covering for it's faults -- or saying that the faults are really DWIMerry or features.

Well they are features whether you like it or not. Perl was very deliberately designing to work in the way it does. You can certainly disagree about it being a good idea - but it's no accident.

I'm still not seeing what you see is so bad about this behaviour. What would you prefer? Should we have separate reverse_string and a reverse_list functions? Should I have to do my $username = ( getpwuid( $uid ) )[0] instead of $username = getpwuid( $uid )?

There are certainly alternative solutions to the problem that scalar/list context solves in Perl, but to me they don't seem innately superior to the option that Larry chose.

Personally I've not encountered problems with the scalar return values of functions, and appreciate the concise comprehensible code it allows me to write.

[EdwardG]

This is a problem with the Perl mindset. DWIM has no value when "Do What I Mean" means different things to different people.

Well now, this is quite a provocative thing to say to an audience of perl fans, so kudos for the big cajones at least.

I think I hear what you are saying about the benefits of consistent behaviour, and I have sympathy for this view. It's just that I think consistency can be taken too far, and the price paid for such consistency is in sophistication, and thereby expressiveness.

If you accept that perl is a language, the primary goal of which is communication, perhaps you can also accept that the process of learning perl is analogous to the process of learning a spoken language.

The spoken language initiate, will obviously have an easier time if the language has only a small number of words, together with a strict and comprehensive set of rules for their usage. If language rules have a wide application, so much the easier.

But the fluent language speaker has a completely different perspective. Imagine how frustrating it would be to not have contractions such as "aren't", and "I'm". Imagine having only negating modifiers such as with "good" and "ungood" instead of antonyms like "good" and "bad".

Now, you might think I'm stretching the analogy too far (it's true I'm often guilty of this), but reflect on how you use your preferred programming language, let's say perl for the sake of argument. Think of how often you use $_.

Think also about code that you would generally upvote; is it spelled out in baby talk, or is it laden with expressive idioms?. If we elevate the importance of consistency as you would define it, we would necessarily lose one of the defining characteristics of perl.

To borrow from a respected perlmonk's home node, perl is complicated in a good way, and none of us would exchange that, not for all the consistency in China.

[ikegami]

DWIM refers to doing something useful rather than providing something useless (e.g. because of lack of forethought or because of a blind drive for consistency). This is not a problem, and it does have value.

«"Do What I Mean" means different things to different people» is a straw man. It's still better to provide something that's generally useful over something that isn't.