That makes no sense. Maps and closures are tools like any other. Just as with many other tools, they are powerful, and should be used WHEN APPROPRIATE.

With maps, for instance, yes generally declarative programming is preferable to imperative programming (http://stackoverflow.com/questions/1784664/what-is-the-diffe...)

However, I've seen monster Java8 stream and C# LINQ statements that would benefit from additional intermediary variables, helper functions, and even cases where loops make things more clear.

>Just as with many other tools, they are powerful, and should be used WHEN APPROPRIATE.

You can't work in a vacuum on large projects. To be an effective engineer you have to understand the limitations of your team members. Forgoing map in lieu of a more verbose loop is completely appropriate if you're working with a bunch of junior people that need to maintain and fix bugs in the same codebase.

I didn't downvote you, but I'm guessing the reason for your downvotes is that in this day and age, even junior programmers should be expected to understand map. It's such a simple concept that anyone who writes code for a living should be reasonably expected to understand it. If you're on a team with a bunch of programmers and nobody understands map, GTFO. It will not end well.

In fact, map is simpler than a loop.

btuilly probably meant map as in mapreduce not map as in hashmap.

Btilly rather clearly meant it in the sense of the higher order function (from which mapreduce gets its name), a fact deanCommie clearly grasped.

So I agree with pretty much everything you said, but it surprised me that people would consider "map" and "closure" a) at all difficult to learn and b) an all-or-nothing business. Could you elaborate? I've found them to be complementary to traditional iteration, object, and macro oriented patterns—they have their strength and weaknesses, and the idea of seeing them either nowhere or everywhere is weird.

You underestimate the bias caused by our initial language. If you're an imperative programmer who has seen some OO, you can learn what map and closures are, but still have no idea what design patterns fit with them. And will be taken aback the first time you encounter them.

The first time I encountered a program that used them in an interesting way, I spent 20 minutes of utter confusion trying to figure out where anything HAPPENED. When I finally found the magic line, I went to the person who wrote it and said, "Why didn't you at least leave a comment!??" He looked at me, slightly puzzled, and said, "What comment would have helped?"

Today these are much more widely understood than they used to be. Mostly because JavaScript forced people to learn it. Though at one point I did have a role in popularizing the concepts in the Perl community with http://www.perlmonks.org/?node_id=34786.

Maps have a very clear and discrete semantic, no need for a flag or a comment, when someone reads the code if they are not familiar with map(x, things) then they will look it up and quickly become familiar. On the other hand closures say "the rules about variables that you might have thought were the rules are not the rules, these are not the rules you are looking for, move on, move on". People who haven't seen them before will be genuinely puzzled.

Yes, a good programmer will find out what is going on, they will be a better programmer there after. However alot of code is picked up by contractors or off shore, or even just by an intern and what happens then is that they hide their incompetence and introduce lots of bugs, or just fake the tests or lie about the tests.

So maybe I'll start to use python metaclasses all the time ;)

But good point poiting out to think hard about it when having co-workers working with your code, readability counts too !