6 ms·

Not sure why some programmers these days have aversion to simple loops and other boring - but readable - code. Instead we have overused lambdas and other trick

Not sure why some programmers these days have aversion to simple loops and other boring - but readable - code. Instead we have overused lambdas and other tricks that started out clever but become a nightmare when wielded without prudence. In this article, the author even points out why not to use his code: Note that this started out as a challenge to avoid loops and excessive branching. After ironing out all corner cases the code is even less readable than the original version. Personally I would not copy this snippet into production code.

chousuke 5y ago
Very often processes are naturally modelled as a series of transformations. In those cases, writing manual loops is tedious, error-prone, harder to understand, less composable and potentially less efficient (depending on language and available tools) than using some combination of map, filter and reduce.
xelxebar 5y ago
I can't comment on the social phenomenon here, but there is indeed a decent technical argument for avoiding for loops when possible. In a nutshell, it's kind of like "prinicple of least priviledge" applied to loops. Maps are weaker than Folds which are weaker than For loops, meaning that the stronger ones can implement the weaker ones but not vice-versa. So it makes sense to choose the weakest version. More specifically, maps can be trivially parallelized; same for folds, but to a lesser degree, if the reducing operation is associative; and for-loops are hard. In a way, the APL/J/K family takes this idea and explores it in fine detail. IMHO, for loops are "boring and readable" but only in isolation; when you look at the system as a whole lots of for loops make reasoning about the global behaviour of your code a lot harder for the simple reasone that for-loops are too "strong", giving them unweildy algebraic properties.
- qayxc 5y ago
  While these are all valid and well thought out arguments, in this particular example, a whole class of problems and bugs were introduced specifically by avoiding simple loops. Not to mention the performance implications. Parallelisation, composability and system thinking are sometimes overkill and lead to overengineering.
  - caf 5y ago
    The article says the looping versions also had the bug.
    - qayxc 5y ago
      Correction: a bug. This is important to note, because only the non-loop version had precision issues.
- codedokode 5y ago
  Loops are easier to read. With functions like reduce you have to solve a puzzle every time to understand what the code is doing (this is also true for functional style of programming in general). > More specifically, maps can be trivially parallelized; same for folds, but to a lesser degree, if the reducing operation is associative; and for-loops are hard. In a typical Javascript code reduce operation will not be parallelized. It actually can be slower than a loop because of overhead for creating and calling a function on every iteration. > when you look at the system as a whole lots of for loops A code with lot of loops is still more readable than a code with lots of nested reduces.
  - girvo 5y ago
    I disagree quite strongly, in that this is simply a function of familiarity. Reduce is no more or less readable than for (especially the C style for — imagine trying to work out what the three not-really-arguments represent!)
  - bryanrasmussen 5y ago
    >Loops are easier to read. With functions like reduce you have to solve a puzzle every time to understand what the code is doing I think that is a function of familiarity, if you use reduce a lot it will be as easy to read as a loop - perhaps easier because more compact - there is a downside to reading more lines for some people, at some point verbosity becomes its own source of illegibility (although any loop that can easily be turned into a reduce probably won't be excessively verbose anyway) Of course all that is just on the personal level, you , by using and reading more code with reduce in it will stop finding reduce less easy to understand than loops - but the next programmer without lots of reduce experience will be in your same boat.
  - cerved 5y ago
    loops are harder to read. What does it do, map, reduce, send emails to grandma? In JavaScript, the reduce callback is created once and called repeatedly. For loops are pretty much always the fastest possible way because they use mutable state. They are also a really good way of creating unreadable spaghetti that does things you don't want them to. I'm not sure what you mean by nested reduces. Chained reduce functions are easy to follow
- gjulianm 5y ago
  > So it makes sense to choose the weakest version. Only if it's actually more readable. The principle of least privilege does not give you any benefit when talking about loop implementations. > More specifically, maps can be trivially parallelized; This argument is repeated time and time again but I've never actually seen it work. Maps that can be trivially parallelized aren't worthy to parallelize most of the time. In the rare case it's both trivial and worthy, it's because the map function (and therefore the loop body) are side-effect free, and for those rare cases you don't care too much about the slightly extra effort of extracting the loop body into a function. > when you look at the system as a whole lots of for loops make reasoning about the global behaviour of your code a lot harder for the simple reason that for-loops are too "strong" Code is too strong in general. Reasoning about the global behavior of code is difficult if the code itself is complex. Nested maps and reduces will be equally difficult to comprehend. The fact that a map() function tells you that you're converting elements of lists does not save you from understanding what is that conversion doing and why. Sometimes loops will be better for readability, sometimes it will be map/reduce. Saying that for loops always make it harder to reason about the code does not make too much sense in my opinion.
  - hnedeotes 5y ago
    I agree with the no silver bullet thing - and written on another reply I don't even know if I agree with the example in the article. > The fact that a map() function tells you that you're converting elements of lists does not save you from understanding what is that conversion doing and why. It can actually, say you have a query that comes in, this calls a function that fetches records from the database, it's not a basic query, it has joins, perhaps a subquery, etc. Then you have another function that transforms the results into whatever presentational format, decorates, wtv, those results, and it's also more than a few basic couple lines of logic. And now you have a bug report come in, that not all expected results are being shown. If you have func does_query -> loop transforms You have 3 possibilities, the problem is on the storage layer, the problem is on the query, the problem is on the loop. You read the query, because the bug is subtle, it seems ok, so now you move to the loop. It's a bit complex but seems to be correct too. Now you start debugging what's happening. If you have func does_query -> func maps_results You know it's either underlying storage or the query. Since the probability of the storage being broken is less plausible, you know it must be the query. In the end it's a synch problem with something else, and everything is right, but now you only spent time on reproducing the query and being sure that it works as expected.
hnedeotes 5y ago
I'm not against using for loops when what you need is an actual loop. The thing is most of the times, previously, for loops where actually doing something for which there are concepts that express exactly what was being done - though not in all languages. For instance, map - I know that it will return a new collection of exactly the same number of items the iterable being iterated has. When used correctly it shouldn't produce any side-effects outside the mapping of each element. In some languages now you have for x in y which in my opinion is quite ok as well, but still to change the collection it has to mutate it, and it's not immediate what it will do. If I see a reduce I know it will iterate again a definite number of times, and that it will return something else than the original iterable (usually), reducing a given collection into something else. On the other hand forEach should tell me that we're only interested in side-effects. When these things are used with their semantic context in mind, it becomes slightly easier to grasp immediately what is the scope of what they're doing. On the other hand, with a for (especially the common, old school one) loop you really never know. I also don't understand what is complex about the functional counterparts - for (initialise_var, condition, post/pre action) can only be simpler in my mind due to familiarity as it can have a lot of small nuances that impact how the iteration goes - although to be honest, most of the times it isn't complex either - but does seem slightly more complex and with less contextual information about the intent behind the code.
- codedokode 5y ago
  For me, code with reduce is less readable than a loop. With loop everything is obvious, but with reduce you need to know what arguments in a callback mean (I don't remember), and then think how the data are transformed. It's an awful choice in my opinion. Good old loop is so much better.
  - verinus 5y ago
    if you are used to imperative programming, then yes. But in a for loop anything can happen- from a map to a reduce to a mix, to whatever convoluted logic the dev comes up with.
    - 5y ago
nvarsj 5y ago
Yes, this plagues JDK8+ code. Every fashionable Java coder has to use an overly complex, lazy stream vs a simple loop in every case.
BrandoElFollito 5y ago
Disclamer: amateur developer for 25 years, no formal education in that area a loop that iterates over indices when I want elements is not readable, e.g. I prefer for element in elements: rather than for (i = 0 , i < len(elements), i++) { element = elements[i] ... This is maybe where this aversion comes from, people usually [citation needed] want to iterate over elements, rather than indices.
- hawski 5y ago
  I find that many times in more complex loops you need the index as well. Sometimes for as mundane reason as logging.
  - BrandoElFollito 5y ago
    Yes, my code is not that complicated and I use languages that are rather high level (Python, Golang, JS with Vue) so I needed the index I think once when I had to remove an element from an array in JS and for some reason I was not using lodash. But yes, there are of course cases where the index could be needed, I was merely commenting on the aversion part for generic developers.
dragonwriter 5y ago
> Not sure why some programmers these days have aversion to simple loops and other boring - but readable - code. Like goto, basic loops are powerful, simple constructs that tell you nothing at all about what the code is doing. For…in loops in many languages are a little better, but map, reduce, or comprehensions are much more expressive as to what the code is doing, but mostly address common cases of for loops. While loops are weakly expressive (about equal to for…in), but except where they are used as a way (in language without C-style for loops) but there is less often a convenient replacement.

chousuke 5y ago

Very often processes are naturally modelled as a series of transformations. In those cases, writing manual loops is tedious, error-prone, harder to understand, less composable and potentially less efficient (depending on language and available tools) than using some combination of map, filter and reduce.

xelxebar 5y ago

I can't comment on the social phenomenon here, but there is indeed a decent technical argument for avoiding for loops when possible. In a nutshell, it's kind of like "prinicple of least priviledge" applied to loops. Maps are weaker than Folds which are weaker than For loops, meaning that the stronger ones can implement the weaker ones but not vice-versa. So it makes sense to choose the weakest version. More specifically, maps can be trivially parallelized; same for folds, but to a lesser degree, if the reducing operation is associative; and for-loops are hard. In a way, the APL/J/K family takes this idea and explores it in fine detail. IMHO, for loops are "boring and readable" but only in isolation; when you look at the system as a whole lots of for loops make reasoning about the global behaviour of your code a lot harder for the simple reasone that for-loops are too "strong", giving them unweildy algebraic properties.

qayxc 5y ago
While these are all valid and well thought out arguments, in this particular example, a whole class of problems and bugs were introduced specifically by avoiding simple loops. Not to mention the performance implications. Parallelisation, composability and system thinking are sometimes overkill and lead to overengineering.
- caf 5y ago
  The article says the looping versions also had the bug.
  - qayxc 5y ago
    Correction: a bug. This is important to note, because only the non-loop version had precision issues.
codedokode 5y ago
Loops are easier to read. With functions like reduce you have to solve a puzzle every time to understand what the code is doing (this is also true for functional style of programming in general). > More specifically, maps can be trivially parallelized; same for folds, but to a lesser degree, if the reducing operation is associative; and for-loops are hard. In a typical Javascript code reduce operation will not be parallelized. It actually can be slower than a loop because of overhead for creating and calling a function on every iteration. > when you look at the system as a whole lots of for loops A code with lot of loops is still more readable than a code with lots of nested reduces.
- girvo 5y ago
  I disagree quite strongly, in that this is simply a function of familiarity. Reduce is no more or less readable than for (especially the C style for — imagine trying to work out what the three not-really-arguments represent!)
- bryanrasmussen 5y ago
  >Loops are easier to read. With functions like reduce you have to solve a puzzle every time to understand what the code is doing I think that is a function of familiarity, if you use reduce a lot it will be as easy to read as a loop - perhaps easier because more compact - there is a downside to reading more lines for some people, at some point verbosity becomes its own source of illegibility (although any loop that can easily be turned into a reduce probably won't be excessively verbose anyway) Of course all that is just on the personal level, you , by using and reading more code with reduce in it will stop finding reduce less easy to understand than loops - but the next programmer without lots of reduce experience will be in your same boat.
- cerved 5y ago
  loops are harder to read. What does it do, map, reduce, send emails to grandma? In JavaScript, the reduce callback is created once and called repeatedly. For loops are pretty much always the fastest possible way because they use mutable state. They are also a really good way of creating unreadable spaghetti that does things you don't want them to. I'm not sure what you mean by nested reduces. Chained reduce functions are easy to follow
gjulianm 5y ago
> So it makes sense to choose the weakest version. Only if it's actually more readable. The principle of least privilege does not give you any benefit when talking about loop implementations. > More specifically, maps can be trivially parallelized; This argument is repeated time and time again but I've never actually seen it work. Maps that can be trivially parallelized aren't worthy to parallelize most of the time. In the rare case it's both trivial and worthy, it's because the map function (and therefore the loop body) are side-effect free, and for those rare cases you don't care too much about the slightly extra effort of extracting the loop body into a function. > when you look at the system as a whole lots of for loops make reasoning about the global behaviour of your code a lot harder for the simple reason that for-loops are too "strong" Code is too strong in general. Reasoning about the global behavior of code is difficult if the code itself is complex. Nested maps and reduces will be equally difficult to comprehend. The fact that a map() function tells you that you're converting elements of lists does not save you from understanding what is that conversion doing and why. Sometimes loops will be better for readability, sometimes it will be map/reduce. Saying that for loops always make it harder to reason about the code does not make too much sense in my opinion.
- hnedeotes 5y ago
  I agree with the no silver bullet thing - and written on another reply I don't even know if I agree with the example in the article. > The fact that a map() function tells you that you're converting elements of lists does not save you from understanding what is that conversion doing and why. It can actually, say you have a query that comes in, this calls a function that fetches records from the database, it's not a basic query, it has joins, perhaps a subquery, etc. Then you have another function that transforms the results into whatever presentational format, decorates, wtv, those results, and it's also more than a few basic couple lines of logic. And now you have a bug report come in, that not all expected results are being shown. If you have func does_query -> loop transforms You have 3 possibilities, the problem is on the storage layer, the problem is on the query, the problem is on the loop. You read the query, because the bug is subtle, it seems ok, so now you move to the loop. It's a bit complex but seems to be correct too. Now you start debugging what's happening. If you have func does_query -> func maps_results You know it's either underlying storage or the query. Since the probability of the storage being broken is less plausible, you know it must be the query. In the end it's a synch problem with something else, and everything is right, but now you only spent time on reproducing the query and being sure that it works as expected.

hnedeotes 5y ago

I'm not against using for loops when what you need is an actual loop. The thing is most of the times, previously, for loops where actually doing something for which there are concepts that express exactly what was being done - though not in all languages. For instance, map - I know that it will return a new collection of exactly the same number of items the iterable being iterated has. When used correctly it shouldn't produce any side-effects outside the mapping of each element. In some languages now you have for x in y which in my opinion is quite ok as well, but still to change the collection it has to mutate it, and it's not immediate what it will do. If I see a reduce I know it will iterate again a definite number of times, and that it will return something else than the original iterable (usually), reducing a given collection into something else. On the other hand forEach should tell me that we're only interested in side-effects. When these things are used with their semantic context in mind, it becomes slightly easier to grasp immediately what is the scope of what they're doing. On the other hand, with a for (especially the common, old school one) loop you really never know. I also don't understand what is complex about the functional counterparts - for (initialise_var, condition, post/pre action) can only be simpler in my mind due to familiarity as it can have a lot of small nuances that impact how the iteration goes - although to be honest, most of the times it isn't complex either - but does seem slightly more complex and with less contextual information about the intent behind the code.

codedokode 5y ago
For me, code with reduce is less readable than a loop. With loop everything is obvious, but with reduce you need to know what arguments in a callback mean (I don't remember), and then think how the data are transformed. It's an awful choice in my opinion. Good old loop is so much better.
- verinus 5y ago
  if you are used to imperative programming, then yes. But in a for loop anything can happen- from a map to a reduce to a mix, to whatever convoluted logic the dev comes up with.
  - 5y ago

nvarsj 5y ago

Yes, this plagues JDK8+ code. Every fashionable Java coder has to use an overly complex, lazy stream vs a simple loop in every case.

BrandoElFollito 5y ago

Disclamer: amateur developer for 25 years, no formal education in that area a loop that iterates over indices when I want elements is not readable, e.g. I prefer for element in elements: rather than for (i = 0 , i < len(elements), i++) { element = elements[i] ... This is maybe where this aversion comes from, people usually [citation needed] want to iterate over elements, rather than indices.

hawski 5y ago
I find that many times in more complex loops you need the index as well. Sometimes for as mundane reason as logging.
- BrandoElFollito 5y ago
  Yes, my code is not that complicated and I use languages that are rather high level (Python, Golang, JS with Vue) so I needed the index I think once when I had to remove an element from an array in JS and for some reason I was not using lodash. But yes, there are of course cases where the index could be needed, I was merely commenting on the aversion part for generic developers.

dragonwriter 5y ago

> Not sure why some programmers these days have aversion to simple loops and other boring - but readable - code. Like goto, basic loops are powerful, simple constructs that tell you nothing at all about what the code is doing. For…in loops in many languages are a little better, but map, reduce, or comprehensions are much more expressive as to what the code is doing, but mostly address common cases of for loops. While loops are weakly expressive (about equal to for…in), but except where they are used as a way (in language without C-style for loops) but there is less often a convenient replacement.