Hacker News Reader

Comment by akvadrako | Hacker News Reader

How is map difficult to understand? It’s the same semantics as a for loop with input and output lists, but less boilerplate.

View on HN

From my personal experience, most developers that discover list comprehension etc. get excited about how much they can achieve with little code that they try to keep everything as small as possible. They end up using short, non-descriptive variable names and you need evaluate the code in your head to find out what a variable/list contains. It's even worse with non-sequential callbacks and closures.

In Python I went back and forth:

I discovered list comprehension and was exited and used them a lot. Then I went to multi level list comp. Then I realise I could never debug those so went back to loops for anything needing more than a single level. Finally I discovered Generator Expression which are basically like list comp, but lazy (not evaluated) and since then I break my code in a series of generator expression which I materialise at the end with a single list comprehension. This way I keep my code readable, it's a lot cleaner then a bunch of loops, and I also benefit of Python's special optimisation for list comprehension.

I like writing generator loops with the yield statement for more complex processing.

That’s my style as well, and I followed the same path of yours!

>It’s the same semantics as a for loop with input and output lists

Arguably it's even easier because you you generally know you won't have inter-item dependencies.

The parent did say they rolled their own map/reduce. It might not have been exactly as one would expect it to work in that case.

But yeah, map/reduce are so common nowadays that I think most people would not have a problem with them anymore. Even Java is doing them now :)

OTOH, if you've never encountered them because you come from languages that did not have them, they might be confusing at first. Some of my colleagues did have trouble getting used to map/reduce when Java8 came around.

If map() is part of the language then it's not difficult to understand because you can always read up on it in official documentation or on the web. But if the language does not support it and you create your own it is unlikely that you document it as well as the vendors of a programming language.

This may be part of the problem with hyper-productive languages in general, you get stuff done fast but it tends not to be documented as well as a publicly available programming language.

map() that is part of the language is also very STABLE whereas if you write your own you are likely to tinker with what it does here and there, what default argument-values it uses and so on.

I've written maps that I've regretted later. "map(+1, list)" isn't too bad. But as you chain things and/or put more in the lambda, it gets less comprehensible. Then, some cross cutting requirement comes in and you either need two map reduces or to just refactor to a loop.

I would say it is the difference between first-order and higher-order. While loops are first-order, thus easier to understand, while map is higher-order, thus more difficult to understand.

"Higher order" functions are about whether a function takes code as a tuneable parameter, rather than "just" (user) data.

A regular function call is first-order:

    foo(bar: Int): Int

While is usually a magical special case, but conceptually it's just a higher-order function that takes two functions:

    while(keepGoing: () => Boolean, action: () => Unit): Unit

Or, if you want to be pedantic:

    while[M: Monad](keepGoing: Monad[Boolean], action: Monad[Unit]): Monad[Unit]

Your higher-order while construct certainly mimics the normal first-order while one. But that's not really the point.

Reply on news.ycombinator.com