Re: Think for yourself.

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

What is the difference between what these lines should do?
map do_something($_), @some_list;
do_something($_) for @some_list;
[download]
They should do the same thing. But to my eyes the second reads much more clearly, and I believe that the same holds true at virtually any level of Perl expertise.

Well, they don't do the same thing; or rather, you cannot deduce from this code fragment whether they will do the same thing or not. If you want to be sure they are the same, you have to write the latter line as:

() = do_something ($_) for @some_list;
[download]

Context matters. map gives list context to the expression, while the expression with the for-modifier is in void context.

And of course, there's another common way of writing map expressions:

map {BLOCK} @some_list;
[download]

Writing that in for-modifier style gives you:

() = do {BLOCK} for @some_list;
[download]

Although if the context doesn't matter, you can get away with:

 
do {BLOCK} for @some_list;
[download]

Alternatively, you can write it as for statements:

for (@some_list) {
    () = do {BLOCK};
}
[download]

for (@some_list) {
    BLOCK;
}
[download]

depending on whether context matters or not.

If there is a clear way and an unclear way of writing the same thing, with both taking similar effort and length, I call it bad style to deliberately use the unclear one (unless confusion is your goal).

What is unclear and what is clear is very subjective. For a language that comes with opinions on what is good and what is bad style, see http://www.python.org. However, I find it difficult to believe there are people that find map in void context "unclear", "obfuscated" or "bad style". I can certainly understand people having problems with map. 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.

What is your feeling if you see:

 
user_defined_function {BLOCK} LIST;
[download]

Utter confusion? Or is this ok, as long as it's not called 'map'?

This does not, of course, justify deriding someone who has picked up the meme of map in void context. But it does indicate gently pointing out that there are clearer ways to do the same thing.

I disagree. It's ok to say that you have problems understanding the concept of map in void context, and that you prefer another style. But it's not ok to suggest that getting confused over a map in void context is something that all Perl programmers suffer from. Just point out it's your own personal preference.

Abigail

Comment on Re: Think for yourself. Select or Download Code

Replies are listed 'Best First'.
Re: Re: Think for yourself. by demerphq (Chancellor) on Oct 06, 2003 at 15:54 UTC
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` [download] 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}	[reply] [d/l] [select]
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)	[reply]
Re: Re: Think for yourself. by demerphq (Chancellor) on Oct 06, 2003 at 23:30 UTC
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}	[reply] [d/l] [select]
Re: Think for yourself. by Abigail-II (Bishop) on Oct 07, 2003 at 09:29 UTC
Re^?: Think for yourself. by Aristotle (Chancellor) on Oct 07, 2003 at 22:59 UTC
Re: Re: Think for yourself. by Petruchio (Vicar) on Oct 07, 2003 at 15:07 UTC
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.	[reply] [d/l] [select]
Re: Think for yourself. by Abigail-II (Bishop) on Oct 07, 2003 at 15:24 UTC
Re^?: Think for yourself. by Aristotle (Chancellor) on Oct 06, 2003 at 20:08 UTC
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.	[reply]
Re: Re: Think for yourself. by tilly (Archbishop) on Oct 07, 2003 at 05:53 UTC
Let me address various points somewhat out of order. However, I find it difficult to believe there are people that find map in void context "unclear", "obfuscated" or "bad style". I can certainly understand people having problems with map. 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. This argument rests on a basic fallacy that is easiest to explain by example. It is trivial to demonstrate that any competent Perl programmer is unlikely to be seriously confused if a particular line of code is accidentally put at a different amount of indentation than it would normally have been. Certainly any programmer who finds it difficult to cope with this is in the wrong line of business. Should we therefore conclude that indentation is not an important aspect of programming style? Obviously not. And the reason is that stylistic questions are not fundamentally about whether or not a given programmer can figure out a situation, but rather about subtle points that affect the efficiency with which that programmer works. For instance cuing expectations about the structure of code - as indentation does - makes it easier to skim through and narrow down on the section that is likely to be of interest to work with at the moment. Therefore indentation style is definitely relevant to programming style, even though no programmer has trouble understanding it. So it is with map. While I have no trouble understanding a map in void context, using a map for its side-effects violates my expectations of what map is for. Therefore reading code that uses maps for their side-effects is less efficient for me. The flip side is that reading code which tries to avoid interesting side-effects inside of maps can now be more efficient for me than it would be otherwise. Since I read and edit a great deal of my own code, and read and edit rather little that uses map for side-effects, this trade-off is a net win for me. What is the difference between what these lines should do? `map do_something($_), @some_list; do_something($_) for @some_list;` [download] They should do the same thing. But to my eyes the second reads much more clearly, and I believe that the same holds true at virtually any level of Perl expertise. Well, they don't do the same thing; or rather, you cannot deduce from this code fragment whether they will do the same thing or not... Note the placement of the word should. Buried in that is a normative expectation. Yes, you can abuse context in any way that you want. But I consider it poor style to use context for anything other than the formatting (or generation) of return results. Yes, I could hold constant an awareness that context could be so (to my eyes mis-)used. But amortized over the code that I deal with, my current expectations pay for themselves. What is your feeling if you see: `user_defined_function {BLOCK} LIST;` [download] Utter confusion? Or is this ok, as long as it's not called 'map'? My opinion is that the author should try hard to set appropriate expectations in the function name and documentation. Furthermore I consider it the duty of the programmer who chooses whether or not to use that function to decide whether or not it is appropriate to use that given his or her environment. BTW for future reference, a function of that exact form whose API strongly violates some people's expectations is `on_release` in ReleaseAction. This does not, of course, justify deriding someone who has picked up the meme of map in void context. But it does indicate gently pointing out that there are clearer ways to do the same thing. I disagree. It's ok to say that you have problems understanding the concept of map in void context, and that you prefer another style. But it's not ok to suggest that getting confused over a map in void context is something that all Perl programmers suffer from. Just point out it's your own personal preference. While I will continue to point out that it is my personal preference and will continue to say why, after this discussion I certainly won't insinuate that map in void context is an undefensible stylistic choice. And the biggest single reason for that is Re: Re: Think for yourself.. That shows how maps in void context can arise as a natural leftover of a productive coding style.	[reply] [d/l] [select]
Re: Think for yourself. by Abigail-II (Bishop) on Oct 07, 2003 at 09:39 UTC
While I have no trouble understanding a map in void context, using a map for its side-effects violates my expectations of what map is for. I think this is the main point where you and I differ. What makes "map" so holy that it shouldn't be used for side-effects? Who or what started this notion? Not Larry, otherwise he wouldn't have made $_ an alias for the list element being processed. Many functions in Perl have side-effects, both user defined and core functions. Why is it fine to have side-effects in a 'for', but not in a 'map'? It's not that 'map' is called 'apply_a_function_and_return_a_list_of_calculated_values'. 'map' just means 'map a function over a list' - and I've been familiar with both the name and its function longer than Perl exists. Abigail	[reply]
Re: Re: Think for yourself. by tilly (Archbishop) on Oct 08, 2003 at 02:43 UTC
This is a good question. And I don't know the answer. I can try to answer where I picked up the notion though. I first saw map and grep actually used in a bad CGI book (whose title I have forgotten), where the author was trying to tell people to write loops like that. I thought the advice was silly, and it didn't take long before I learned enough to realize that the book was bad. Furthermore I noticed that people who were far more experienced than I sometimes criticized people for using map and grep for side-effects, and I filed that away as another fault of the book. When I later saw map and grep being used more appropriately, it was in the context of side-effect free transformations. Not long after that I ran across them in some material that I was reading about Lisp, and about functional languages, which advocated making functions side-effect free for a variety of reasons (mainly more transparent modularity and easier debugging). I took the notion back to my Perl, and began using map and grep fairly consistently, but always with side-effect free blocks. This stylistic choice became a habit, and the habit became an expectation, and that continued with rather little thought about the matter on my part until this week. So I guess that the answer is that the people who chanted against map and grep in void context set my original notions, and then the notion that it was good to actively avoid having them have side-effects came for me from other languages that I was trying to learn about. I doubt that many other Perl programmers who hold my opinion hold it for the same reason though.	[reply]
Re: Re: Think for yourself. by zby (Vicar) on Oct 08, 2003 at 10:27 UTC
People often call "map" and "grep" functional programming techniques. Since in pure functional programming there are not side effects, this may explain why some people (including me) don't expect side effects in them.	[reply]

In Section Seekers of Perl Wisdom