As Zaxo said, it was never deprecated. However, for years
there was a band of people that never listened to Larry.
Larry said that Perl was there to serve the programmer, and
the programmer should never be a slave to the language. Yet,
this band of people decided programmers should know the
details of the implementation, and should hence know how
inefficient perl handled map in void context (due to the fact
that map, unlike most other functions, didn't inspect in which
context it was running). And this band of people would throw
dirt at any programmer that used map in void context, scolding
them, as if the Perl programmers were guilty of the perl programmers neglect of making map efficiently. (Use of capital and lower case in the previous sentence is very
significant).

There was another round of mud throwing going on on Usenet
last month. It prompted me to followup with the following
(I've responded to the stone throwing similar for years):

Poor style? Why? Return values of print and assignment are usually not
used either, but noone considers that poor style.

The fact that map builds and discards a list when it's used in void
context is a bug in *perl*. It's not poor style of the Perl programmer;
the fault lies with the perl programmers.

But noone has found it seriously enough to provide a patch. For years,
a whole chorus on people in this newsgroup chant "poor style" whenever
someone uses map in void context. But none of those sheep has ever
bothered sending a patch to p5p.

And that triggered Tassilo v. Parseval to write a patch.
It turned out to be a three line patch. Imagine,
all the energy wasted scolding at innocent programmers,
while the fix was relatively easy!

Don't get intimidated to easily when people are chanting
"bad style". Chargo cult chanting is in the Perl world far
more common than cargo cult programming (although many people will easily chant "cargo cult programming"!). Think
for yourself. And people that chant "bad style", think
for yourself too. Don't mindlessly copy the behaviour of
someone who is "famous". That's how religions start. Think
for yourself.

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.

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).

In fact the only reasons that I have seen given for why to use map (and yes, I have seen people try to recommend it) is that it is compact and demonstrates that you really know Perl. I cannot think of a worse reason to (mis)use a feature. Particularly since the goal is not achieved. Inline loops are even more compact, and are more likely to make a positive impression on good Perl programmers.

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.

The main reason I tend to use map is to signal to the reader of the code that this is an operation on a list not just on a set of values that are conveniently represented as an array.

In other words, to me, map and grep carry extra semantic value to future maintainers of the code. (In most cases, Wade-future does not really remember what Wade-past had in mind.<grin/>)

To me, your first example implies that we are transforming a list. The second implies we are transforming the elements of a list. Although the results are the same to the computer, to the programmer the meaning may be very different.

Then we extract different semantic value from the same code. To me both grep and map make me start looking for where the return is going, because the return is likely to be the point of the operation. By contrast a for loop tells me that the action of the loop is what I should focus on. This bias is strong enough that while I am happy to have loops have side-effects, I will go out of my way to rewrite maps or greps with side-effect in their blocks to be regular loops instead.

If you are not the only maintainer of your code, it might be worthwhile to find out what both constructs mean to them. Remember that meaning is highly dependent on the context that the reader brings to the document. If people around you read it the same way, then the map solution may well be more maintainable in your environment. If they read it differently, then it may be better to retrain your intuition to match theirs. This kind of issue is one where having people be on the same page matters more than what page everyone is on.

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:

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.

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.

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.

PURPLEGREENBLACKREDBLUEYELLOW

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.

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

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.

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.

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.

And I will continue chanting bad style for the reasons tilly mentioned (and not because it's tilly; I've thought the same for myself a long time). The only thing map can do that for can't, is that you can chain the former but not nest for modifiers. (Which is going to be allowed come Perl 6, thank Larry.)

Abigail-II: That "three line patch" is one of thousands that bloats Perl. If you want to discourage
people from calling this a bad thing, we can't stop you.

With regards to your argument that nobody considers it bad style that the return value of print and other functions are not checked, I disagree. Many people consider it bad style, but see no practical solution to the problem. People have argued for years (on and off) that print should really raise an exception. The matter
has never been closed off. It has only been put off.

With regards to your argument that it is really a bug that map in void context creates a list, I find your argument to be faulty. It is only the knowledge that the 3 lines patch has been applied (i.e. intimate implementation knowledge of the language) that has since encouraged people to continue to use map in void context. Intuitively, and according to the original documentation, most reasonable people would assume that a list was created, and would only be pleasantly surprised to find that the case was optimized now so that the list is not created.

With regards to your last argument that calls all people who disagree with you "sheep", and points out that no patch was provided, I think you have missed the point. The people who consider it bad style did not *want* to submit a patch. They did not *want* Perl to be officially implemented to encourage such a bad style. And yet, now that a patch was submitted, and included, this very thing has happened. Respected members of the Perl community such as yourself encourage (or silence the discouragers, which is the same thing) the very odd practice of using a list transformation control structure to iterate through a list.

It isn't as if this sort of practice is un-Perl. After all, Perl is the language that encourages people to use operations like "tr/a/a/" to count the number of a's in a string.

I use Perl because it is practical. I don't use it to ensure that non-Perl-familiar members of the community will be unable to understand my code.

i think map in void context is just fine. if i decided to place my data in a hash for later lookup i just might do so at the end of the first map (instead of returning an array of arrays). i'm sure i wouldn't try and re-craft the code to use a for just to appease.

it's much easier to decide to add more files to the cat (try that with <file ). or to replace the cat with another command that generates the data. why on earth would i continuously rewrite my commands when i can up-arrow and add easily to the beginning?

I don't get it. You haven't used map in void context. Also, I'm not convinced that you haven't purposefully
written your code inefficiently just to prove that map
is useful. Why do you have the intermediate grep when
an if in the for loop would do just fine? Sure, copying
lists around is *fairly* cheap, but we come to my
original point: Did you actually take a step back before
designing your code, to ensure that it works best? Or
did you just string map and grep together until it
worked the way you wanted it to?

If an optimization that only takes three lines "bloats" Perl,
then you must have been an unhappy camper ever since Perl 5.000
came out. If you already consider this bloat, how do you feel
about statement modifiers? What about having unless?
What about short cuts like +=? Or having two kinds of
for/foreach, a while, and an until? Shouldn't that be all bloat
because we have goto?

It isn't as if this sort of practice is un-Perl. After all, Perl is
the language that encourages people to use operations like "tr/a/a/"
to count the number of a's in a string.

Funny that you bring this one up. For a long time, "tr/a/a/" modified
the string it was working on (replacing every 'a' with an 'a'). Noone
considered that bad style. And still, after a couple of years, this
operation was also optimized. Do you consider that 'bloat' as well?

I use Perl because it is practical. I don't use it to ensure that
non-Perl-familiar members of the community will be unable to understand
my code.

You must have a limited view of the world of programming languages.
The non-Perl world is bigger than Java. There are languages in which
map like constructs *are* the way to iterate over an array. In fact,
I know more languages that use map like constructs to iterate over
an array (or list) than I know that use 'for (LIST)'. And outside of
Perl, I do not know any that uses 'EXPR for LIST'.

With regard to my bloat argument, you have purposefully exaggerated your defense by mentioning operators that provide unique benefits that are impractical to not use. += is impractical to not use. Statement modifiers are impractical to not use. Map in void context is not nearly as necessary of a construct.

With regard to the tr/a/a/ that I mentioned, it isn't funny that I brought this up, nor is it a coincidence. I am admitting that the language has a precident for providing behaviour in un-obvious or circular implementation, that is at some point optimized for general use. Do I consider it bloat? I sure do. I brought it up, after all.

As for your last attempt to insult me, I suggest you re-think your motivations. I rarely ever use Java. My day-to-day programming at work is almost 100% Perl, and has been for several years.

You may think Perl is perfect. I don't. I am forced to admit that Perl is practical, and so I use it. Note the difference. Not all the world is Abigail, or Perl. Didn't you just say, in this very thread, "Think for yourself"? I am thinking for myself, and you are criticizing me for it. I suppose "there is more than one way to do it" really means "there is Abigail's range of doing it" and anybody who uses less as a means of improving the quality of the code, is guilty of limited thought. Sheesh.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other