It is counterproductive to cripple the programmers on your team who can handle abstraction to avoid confusing the ones who can't. Why turn 10x coders into 9x coders or worse just to retain your 1x coders? Or work with the ones having trouble with a pattern until they get it?

That's the management decision in the article. And I make the same decision. We're not an organization that attracts nor hires rockstars (or, as you say, 10x coders). We have a couple really sharp folks but are predominately staffed by "1x" coders. Therefore, it is important and the responsible thing to do to write all code so that it can be understood and maintained by a 1x coder.

Even if it is being written and currently maintained by one of our sharper folks, people move on or change roles, and projects shift to other staff for long term maintenance. Who's going to be maintaining this project in 2-4 years? This project needs to be written with them in mind.

I have to ask, where do you draw the line? I had a team lead that disliked me writing things like (in C#, been a bit so forgive errors):

  List<AClass> original; // perhaps as a parameter to the function
  List<AClass> filtered = original.Where(x => x.Field > 10);

Arguing that I should instead have just used for loops (showed him foreach and he agreed that that was better, at least) like:

  List<AClass> filtered = new List<AClass>();
  foreach(x in original)
    if(x.Field > 10) filtered.Add(x);

Ok, so it's only two lines longer (three if you split the if and its effect, 5 if you also add in braces, 7 if you put opening braces on their own lines). The `Where` version is not that complicated, and only requires understanding one (potentially) new concept for programmers, namely anonymous functions.

Wouldn't the briefer, but still clear, code be preferable for maintenance?

Yes absolutely. I don't say "no functional constructs" nor does anyone else here that I know of. However, composite LINQ statements, especially involving aggregation can and do become confusing. Obviously it's a judgment call but in many cases, breaking out a complex expression into incremental, imperative steps can and does make it clearer.

The "rule" I apply is "code should be written primarily for people to read and only incidentally for machines to execute" which, although very subjective, provides a good foundation for everyone to start from.

Why would avoiding "map" suddenly decrease the ability of your coders? It's not like writing out the equivalent loop takes that much time.

It's easier for a bug to slip in, like an off-by-one error, when one chooses to write a loop rather than invoke a well-tested abstraction that hides the loop, leading to more time spent later in the development process debugging and fixing the problem.

Yeah, code that anyone can read is so overrated. PS: Sarcasm.

> a for loop can be understood by almost any programmer you will encounter

Because at some point that programmer learned how a for loop works. Programmers are smart people; they should learn how flatMap or any other abstraction works. Abstractions are the tools of the trade. Imagine a mechanic that didn't use power tools because he/she didn't understand them.

I would agree with you if we were talking about more complicated features like monad transformers or monoids or something like that, but list operations like this are very high-leverage, not that complicated under the hood, and becoming part of the standard required knowledge for most programming ideologies. (Eg. Java has recently embraced them in Java 8, Python has them, etc)

Your logic about an abstraction being "legitimately obfuscated" "until you grok" it could apply to nearly every advancement in programming, and needs to be qualified with some notion of why you've decided to apply it to the layer of abstraction that you have.

What order do you expect the output to be in when you run flatmap? In doing research on it, I've seen at least three distinct orders. One, results are interleaved. Two, results are depth first. Three, results are breadth first.

If the final order of the output is important (and it frequently is), you have to understand not only "map, then flatten", but the order in which the flatten occurs. And that appears to be implementation dependent.

Hmm I would expect the results to be based on the data structure holding the values you're flattening. An in-order depth first traversal if the data structure you're applying it to has an inherent order (e.g a List) and in an undefined order if it's something unordered like a Set.

  List(List(1,2), List(3,4), List(5,6)).flatten -> List(1, 2, 3, 4, 5, 6)
  Set(Set(1,2), Set(3,4), Set(5,6)).flatten -> Set(5, 1, 6, 2, 3, 4)

I would agree, but have a look at this:

http://reactivex.io/documentation/operators/flatmap.html

Granted, this refers to a higher level abstraction on a sequence of realtime events, but as we delve more into green threads and lazy evaluation, these kinds of solutions will become more common.

I really don't believe that there is no obvious way to guarantee the ordering of a given flatten command without looking into its implementation. Of course, I'm admittedly partial to Python's solution - use an explicit list comprehension:

    >>> g = lambda i: (i, -i)
    >>> [x for y in [1, 2, 3] for x in g(y)]
    [1, -1, 2, -2, 3, -3]

If I cared what the order was, I'd expect that I'd have to order it myself, e.g.:

  var foo = things.SelectMany(thing=>thing.SubThings).OrderBy(subthing=>subthing.PropertyICareAbout)

Particularly if things is some interface that I don't know the details of, like IEnumerable, ICollection or IDictionary.

"you turn a 4 line for loop with accumulators into a single line of code"

And dear heavens, achieving more with less code is the last thing any respectable developer would want.

If it's at the price of clarity, yes, that is exactly the last thing any respectable developer would want.

The problem is, clarity for who? For the developer? For another, equally skilled developer? Or for the developer's less skilled coworkers? For the least skillful coworker? To whom does the code need to be clear?

I believe "turning a 4 line for loop with accumulators into a single line of code" increases clarity for all of the above. Do you disagree?

If you have a coworker who doesn't understand it, pair them with someone more senior until they get up to speed. If they are simply cognitively incapable of understanding the concept of mapping a function, in my opinion they are not capable of becoming a good developer.

Yes, there are times when reducing lines of code reduces clarity. But in my experience they are rare and exceptional. Far more real world code lacks clarity due to verbosity than from being overly terse.

In the real world, I've got a team that, while all of them could learn to read that one line of code, I don't think any of them can read it now.

Sure, they could be taught. But they're busy being taught other things - Android, say, or the latest JS framework. So there's an opportunity cost to teaching them - it takes away time and attention from teaching them other things, things that may move us closer to our business goals. So in practice, yes we can teach them, and no we won't.

And now that one line of code can decrease clarity for the team.

Get a decent static analysis tool for their IDE, that points out places where they can replace a gommy, ugly loop with a higher-order function.

In my opinion and experience, Resharper is the easiest way to learn LINQ, before you even start looking at all the other dumb, inconsistent and error-prone stuff that people will do because it compiles, blissfully unaware of all the foot-guns it contains.

If they're new enough to not understand that map, et al are using loops internally, then they're probably too new to be working an actual job. They might never have been exposed to it, in which case an explanation is warranted, but if they still don't get it, maybe they're not cut out to be a programmer.