<?xml version="1.0" encoding="windows-1252"?>
<node id="296977" title="Re: Re: Think for yourself." created="2003-10-06 11:54:55" updated="2005-06-05 07:40:43">
<type id="11">
note</type>
<author id="108447">
demerphq</author>
<data>
<field name="doctext">
&lt;!--

&lt;code&gt;&lt;/code&gt;
&lt;i&gt;&lt;/i&gt;
&lt;b&gt;&lt;/b&gt;
&amp;#91; &amp;#93; 
--&gt;
&lt;p&gt;&lt;em&gt;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 &lt;b&gt;disappears.&lt;/b&gt;&lt;/em&gt;&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
Theres a great experiment for demonstrating this type of principle. 
&lt;/p&gt;
&lt;p align="center"&gt;
&lt;b&gt;
&lt;font color="Yellow"&gt;PURPLE&lt;/font&gt;
&lt;font color="Red"&gt;GREEN&lt;/font&gt;
&lt;font color="Purple"&gt;BLACK&lt;/font&gt;
&lt;font color="Aqua"&gt;RED&lt;/font&gt;
&lt;font color="Green"&gt;BLUE&lt;/font&gt;
&lt;font color="Black"&gt;YELLOW&lt;/font&gt;
&lt;/b&gt;
&lt;/p&gt;
&lt;p&gt;
Now read off the color of each word in the list quickly.  Make any mistakes? I bet you did.
&lt;/p&gt;
&lt;p&gt;
And this is the core problem with map in void context. &lt;b&gt;It makes people think that something is happening that isn't, and then when they realize it isn't, they wonder why its not.&lt;/b&gt; Its about wasted time. Don't code like that if you work with me, because if I waste &lt;i&gt;any&lt;/i&gt; 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. 
&lt;/p&gt;
&lt;code&gt;
# this should be changed to a for, dont worry about it
&lt;/code&gt;
&lt;p&gt;
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.
&lt;/p&gt;
&lt;p&gt;
For me the core of this is that Larry made the language wonderfully expressive so we con convey the maximum information about &lt;i&gt;what we are doing&lt;/i&gt; by &lt;i&gt;the constructs we use to do it&lt;/i&gt;. 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 &lt;i&gt;are lying to them&lt;/i&gt;. 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.)
&lt;/p&gt;
&lt;div class="pmsig"&gt;&lt;div class="pmsig-108447"&gt;
---
&lt;br /&gt; 
demerphq&lt;br /&gt;
&lt;br /&gt;
&lt;sub&gt;

&lt;ol&gt;
&lt;p&gt;&lt;em&gt;First they ignore you, then they laugh at you, then they fight you, then you win. 
&lt;/em&gt;&lt;br /&gt; -- Gandhi&lt;/p&gt;
&lt;/ol&gt;
&lt;/sub&gt;
&lt;/div&gt;&lt;/div&gt;
&lt;!--
&lt;hr /&gt;
&lt;sub&gt;
&lt;p&gt;
&lt;strong&gt;&amp;bull; Update:&amp;nbsp;&amp;nbsp;&lt;/strong&gt;&lt;br /&gt;

&lt;/p&gt;
&lt;/sub&gt;
--&gt;
&lt;br /&gt;
</field>
<field name="root_node">
296742</field>
<field name="parent_node">
296889</field>
</data>
</node>
