Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re: Re: Think for yourself.

by demerphq (Chancellor)
on Oct 06, 2003 at 15:54 UTC ( #296977=note: print w/ replies, xml ) Need Help??


in reply to Re: Think for yourself.
in thread is the use of map in a void context deprecated ?

But I find it hard to believe there are seasoned Perl programmers that have no problem with map if the map is on the right hand side of an assignment, but are suddenly getting confused if they assignment disappears.

Im with the bad style chanters on this one, although a borderline case, I dont froth at the mouth over it, and think the optimisation patch is a worthwhile addition to perl.

I emphasised one point of your comment however. When i see a map in void context that isnt part of an obfu or some CB whip-it-together, my first thought is "Hmm, what happend to the target of the map?" And then I go looking to see what I dont understand. And then I get annoyed and change it to a for loop so that nobody else wastes time trying to figure out the misleading code.

Theres a great experiment for demonstrating this type of principle.

PURPLE GREEN BLACK RED BLUE YELLOW

Now read off the color of each word in the list quickly. Make any mistakes? I bet you did.

And this is the core problem with map in void context. It makes people think that something is happening that isn't, and then when they realize it isn't, they wonder why its not. Its about wasted time. Don't code like that if you work with me, because if I waste any time wondering why that map is there and there isnt a damn good excuse for it then you and I are going to be having an unpleasant conversation. Now if you decide to rework what was formerly a map without changing it to a for, and leave me a note in a comment I wont be so bothered. I probably wont even change the code for you, accepting it under the Shit Happens rule.

# this should be changed to a for, dont worry about it

But if I waste time trying to figure out if the missing part of the map is the cause of some trouble then i'm really not going to be happy.

For me the core of this is that Larry made the language wonderfully expressive so we con convey the maximum information about what we are doing by the constructs we use to do it. Just as languages have nuances and subtleties so too does perl. And when you mean one thing, and then say it in a way that is usually reserved for saying other things then you are potentially and unnecessarily confusing your audience. The cues they are trained to look for are lying to them. Frankly programming is a complex enough job without wondering if the code is lying to me. (It might be fun in obfus and japhs, but it ends there.)

---
demerphq

    First they ignore you, then they laugh at you, then they fight you, then you win.
    -- Gandhi



Comment on Re: Re: Think for yourself.
Select or Download Code
Re: Think for yourself.
by Abigail-II (Bishop) on Oct 06, 2003 at 19:50 UTC
    I emphasised one point of your comment however. When i see a map in void context that isnt part of an obfu or some CB whip-it-together, my first thought is "Hmm, what happend to the target of the map?" And then I go looking to see what I dont understand. And then I get annoyed and change it to a for loop so that nobody else wastes time trying to figure out the misleading code.

    And that is something I don't understand. What makes map so special? Any function in Perl will return something, be it a buildin or a user defined sub, and even operators return values. Why is it that people get all confused if they see a map in void context, and start looking where the return value goes, but they don't have problems with other functions?

    What makes map so special?

    Abigail (really, I'd like to know)

      Vaguely, because map has control structure characteristics rather than reading purely like a function. Unlike any of the "real" loops it does have a return value, however.

      Not so coincidentally, I've sometimes thought it would be nice if for could build a list as well - in which case any distinction between the two would really go out the window for good. Ruby works this way.

      Makeshifts last the longest.

      What makes map so special?

      Because its name and general usage strongly suggests that it should return something. Take a sub like get_value if you saw that in void context wouldn't you wonder what is going on? Wouldn't it annoy you to discover that in fact the routine has nothing to do with getting a value? Well likewise for me and map. If you want to do some action for each member of a list, then use foreach. If you want to transform each member of a list into something else and get the resulting list back, then use map. The cues in the name help you understand the intent of the author more quickly and with less effort. If someone plays silly bugger and uses map as for then they have just thrown away a useful cue to a future developer as to what was on their mind when they wrote the code.

      Think about it for a minute. We do our best to not confuse ourselves and theose that come after us. We don't use $var1 and $var2 for our variable names so that the programmer that follows us (more often than not itll be ourselves a few days or weeks later :-) has a hope in hell of figuring out what it going on. We don't name our subroutines A, B, C etc, for similar reason. We dont use goto's as our primary flow control mechanism etc. All of these things are to provide as much of a cognitive model of what is happening as possible. The same goes for map.

      I mean why make life hard? Perl has a hugely expansive vocabulary as far as programming goes. Why waste the expressiveness that it provides? Say what you mean and mean what you say. If you want to map a list then do so, if you want to iterate over the list then do so, but don't pretend to one when you are really doing the other.


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi


        Because its name and general usage strongly suggests that it should return something.

        But where is this notion coming from? "map" as an operation that maps a function over all the elements of a list doesn't come from Perl (I've been familiar with the operation and the name even before Larry released Perl 1.000), and its name doesn't suggest anything about return values shall be used.

        Someone, or something, has seeded this notion that the first argument of map should be side-effect free, and it wasn't Larry - otherwise $_ wouldn't be an alias.

        Take a sub like get_value if you saw that in void context wouldn't you wonder what is going on?

        Sure, I'd figure that either the caller hadn't understand the working of get_value, or that the name of the function was misleading. But "map" isn't called "get_value". It's just "map". Short for "mapping a function over a list". And that's just what it's doing. It isn't called "construct a list by collecting return values". In fact, if I want to add one to all elements of an array, I find:

        map {$_ += 1} @array;
        to be far more natural than:
        for (@array) {$_ += 1}

        I find it more surprising that $_ is an alias for the list element in a 'for' loop than in a 'map' operation.

        Let's look at the first sentence of 'perldoc -f map':

        Evaluates the BLOCK or EXPR for each element of LIST (locally setting $_ to each element) and returns the list value composed of the results of each such evaluation.
        Before it talks about return values, it describes what map does: evaluating a piece of code for each element of the list.

        Anyway, you haven't convinced me. I refuse to deal with "map" differently than other functions. And if I can use other functions in void context, I can use "map" in void context.

        Abigail

      And that is something I don't understand. What makes map so special? Any function in Perl will return something, be it a buildin or a user defined sub, and even operators return values. Why is it that people get all confused if they see a map in void context, and start looking where the return value goes, but they don't have problems with other functions?

      What makes map so special?

      Map is special, in my opinion, because there is a nearly analogous construct which does not return values.

      Good style involves choosing appropriate tools. Given a situation where no return value will be used, I tend to expect someone to pick the tool which returns no value... unless there is a good reason to do otherwise. Forcing list context, for example.

      If I see someone make a different choice, I will wonder why, and I will investigate. If, at the end of my investigation, I conclude that the author could have used a foreach loop just as effectively, I will be annoyed. By passing up the more appropriate (and more obvious) tool, he has obliged me to go looking for something subtle which was not there. Likewise, I wouldn't expect a person to choose

      () = do_something ($_) for @some_list;

      over

      do_something ($_) for @some_list;

      unless there was actually a need to force list context; if the author consistenly chose the former as his idiom without good reason, I'd find it very irritating (though not half so irritating as an author who inconsistently chose this, or map in void context, without good reason).

      On the other hand, perhaps the author intends to alert me to the significance of context here. Saying

      () = do_something ($_) for @some_list;

      would then be a louder hint, and I'd generally prefer it; but if the author was consistent in using map for this purpose, I wouldn't call it bad style. I might appreciate a note somewhere, as this is not common practice.

      An author might choose map for this, I think, on the grounds that he was choosing the most appropriate tool. In a very fastidious author, whose code was so clean and consistent that it gave the reader a sense of confidence that each thing was as it was for a reason, this might be a bit of minimalism which I would admire. However I would be surprised to see such a person call his own functions in such a fashion, because I wouldn't expect him to write a function which altered its arguments differently depending on the context in which it was called. I cannot think of a good reason to do this.

        Good style involves choosing appropriate tools. Given a situation where no return value will be used, I tend to expect someone to pick the tool which returns no value...

        But map in void context does not return a value. No function in void context returns a value - it can't, because there's nothing to put the value in. That return values of functions are context driven is a very essential thing that makes Perl what it is. It's not map that decides whether nothing, a scalar or a list will be returned - it's the context. And map doesn't behave any different than any other function.

        By passing up the more appropriate (and more obvious) tool, he has obliged me to go looking for something subtle which was not there.
        That sounds like "for is the more obvious tool, because it's more obvious".

        Abigail

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://296977]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (9)
As of 2014-08-22 09:05 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (152 votes), past polls