Re^6: Write code diferently

[Laurent_R]

I do not want to argue endlessly, especially in view of the fact that we probably mostly agree and that the whole discussion really stems from a quick comment I made on the possible motivation of the OP, nothing fundamental. I just want to set the record straight on a couple of things.

The Camel Book edition I mentioned was issued in 2012 and the revision probably occurred in 2011. The cover says prominently "Covers version 5.14". So, pretty recent stuff. The relevant section is about programming style, not efficiency or performance.

"The inefficiency of map in a void context" may be cargo cult, but I did not say anything like that or even remotely similar to that, not even hinted anything in that direction. I vaguely remember having read things about that about 10 years ago, but it is absolutely not my belief, I simply have no opinion on that because I do not know. I ran a test a few weeks ago comparing map and foreach, and, in the specific context of my specific test (quite different from the case in point), foreach turned out to be slightly faster (25%). This is the only reason why I said "possibly faster". I was not repeating some sacred mantras read somewhere, and there is really nothing in what I said that could lead anyone to believe that this is what I was doing.

I have some interest in the functional programming paradigm, because I think it created or promoted a lot of very interesting and powerful concepts (list processing, higher order functions, closures, lazy evaluation, etc.), but I never used any functional language anywhere beyond making some toy programs to get a feeling of it. My background before Perl was Fortran, Modula, ADA, assembly, C, C++, TCL, Python, awk, shell, PL-SQL and quite a few other languages, none of them functional. But I love the fact that Perl offers me the possibility to use some of the useful concepts it has borrowed from functional programming, because it gives me extra expressive power. But, of course, I have many other reasons to love Perl, some of which are certainly much more significant.

[BrowserUk]

The relevant section is about programming style, not efficiency or performance.

Oh, its 'style advice'. It's perfectly fine to cargo-cult that(*).

Does the book have any opinion on whether I should be wearing a full beard with my knee-crutched jeans or just 3-day stubble?

(*)My point being, that you are still passing on information you have read, as advice or preference or law, without having examined the reasoning behind it, or having applied your own reasoning to it; or concluded that it is good advice, preference or law on the basis of your own experience.

I occasionally suggest or recommend the use of strict and/or warnings. I do so, not because I've read that they should be used, nor even because someone told me it is a good idea; but because I personally have found them useful to me. And when I do so; I demonstrate what benefit the OP would have accrued from doing so.

But nowhere have you even attempted to reason (beyond "looks a bit clunky"; and you read it in a book) why you think my use of map is suboptimal. That's cargo-cult.

[Laurent_R]

You are misrepresenting what I have said, and it starts to look deliberate.

My point being, that you are still passing on information you have read, as advice or preference or low, without having examined reasoning behind it, or having applied your own reasoning to it; or concluded that it is good advice, preference or law on the basis of your own experience.

This is not so. I only made a two-line post just trying to understand why the OP wanted to change the map in the code presented, and saying that, in my personal opinion, a for or foreach construct would be clearer in that case. Not that I read it somewhere or someone told me, my own experience tells me that this is the case.

In my next post, I said this:

I was just expressing a matter of personal taste that it may not be the best style. Others may have different opinions on that.

Still not repeating something I have read, stating clearly that it is a personal opinion of mine.

I am forced to quote the official Perldoc map documentation and the Camel Book only because you are tweaking the map functionality by saying something like:

map maps a function over a list; optionally returning a new list.

There, you are basically making the claim that the return list is a secondary effect of map. This claim is just preposterous and you know better than that. BTW, another quote from the official Perldoc documentation on map:

Map always returns a list.

But quoting the official documentation is probably just repeating cargo cult, isn't it?

And the only reason I said that the quote from the Camel Book was in a programming Style section was just to set the matter straight that it was not previous section on efficiency and performance.

I am sorry that this discussion turned this way, I certainly did not want to have this type of argument with you. Again, I respect very much your opinions, but that does not mean that I have to agree will all of them. Agreeing with everything you said might indeed be repeating cargo-cult, I have enough experience to have my own opinion. I do not think that I want to continue arguing. You may have the last word.

[BrowserUk]

. BTW, another quote from the official Perldoc documentation on map: Map always returns a list.

Regardless of the provenance, that information is wrong. The difference between reading and knowledge.

I gave you an out; but you continue to hide behind irrelevant meta discussion.