5 ms·

Higher-order functions improve readability, maintainability and correctness. The idiomatic supposed alternative of using e.g. for-loops instead of map/fold/...

Higher-order functions improve readability, maintainability and correctness. The idiomatic supposed alternative of using e.g. for-loops instead of map/fold/... is a disease that needs to be shunned, like goto was for cases where better constructs exist. If performance suffers, it is up to the language to implement proper inlining and fusion.

_a_a_a_ 4y ago
I assume you're either trolling or have neither commercial nor compiler-writing (edit; nor significant functional programming) experience.
- c4mpute 4y ago
  I do have commercial experience and I did a class on compiler-writing at the university. Therefore I am not trolling.
  - _a_a_a_ 4y ago
    Well you answered moderately and you didn't hammer the downvote button so perhaps we can make something constructive of this. > Higher-order functions improve readability, maintainability and correctness Perhaps correctness, but readability and its close relation, maintainability, well that's another question. I think it depends partly on the person (I'm not very good at reading code) and very definitely on the quality of the written code. I have seen some very, very horrible functional code. Simply declaring that it is more readable doesn't fly. Back to correctness: well, functional code tends to be shorter than non-functional code, and it's a known fact that the number of bugs seems to be a constant per the lines of code (or at least that's the accepted wisdom, let's go with it) so is the lower number of bugs in functional code directly proportional to its reduced size, or is there something extra work? If it's directly proportional to the reduced size, then you often can do a heck of a lot with procedural code to reduce its size as well, usually by simply defining extra procedures/functions instead of copy/pasting code (which is a disease that functional code can very definitely suffer from also!) > If performance suffers, it is up to the language to implement proper inlining and fusion And in the meantime you lose sales, your competitors do better and start eating your market share – if you were running a company how would that make you feel? You have to be realistic. Anyway, I do appreciate that you weren't trolling and weren't dismissive of my post, so I've upvoted your response.
    - erik_seaberg 4y ago
      Map explicitly says what it does. A loop forces you to carefully (re)read it to see whether it ever skips an element, appends more than one result, or doesn’t propagate an error, because findFirst, findLast, findAll, filter, map, flatMap, and reduce all look very similar as loops. If you need a loop to work around a poor optimizer, at least use a preprocessor to generate it. Devs are expensive.
deleted 4y ago
[deleted]
SPBS 4y ago
I mean, if you strongly hold this opinion then Go is really not the language for you. And if you don't use Go then it shouldn't really bother you either. Let Go devs be Go devs.

_a_a_a_ 4y ago

I assume you're either trolling or have neither commercial nor compiler-writing (edit; nor significant functional programming) experience.

c4mpute 4y ago
I do have commercial experience and I did a class on compiler-writing at the university. Therefore I am not trolling.
- _a_a_a_ 4y ago
  Well you answered moderately and you didn't hammer the downvote button so perhaps we can make something constructive of this. > Higher-order functions improve readability, maintainability and correctness Perhaps correctness, but readability and its close relation, maintainability, well that's another question. I think it depends partly on the person (I'm not very good at reading code) and very definitely on the quality of the written code. I have seen some very, very horrible functional code. Simply declaring that it is more readable doesn't fly. Back to correctness: well, functional code tends to be shorter than non-functional code, and it's a known fact that the number of bugs seems to be a constant per the lines of code (or at least that's the accepted wisdom, let's go with it) so is the lower number of bugs in functional code directly proportional to its reduced size, or is there something extra work? If it's directly proportional to the reduced size, then you often can do a heck of a lot with procedural code to reduce its size as well, usually by simply defining extra procedures/functions instead of copy/pasting code (which is a disease that functional code can very definitely suffer from also!) > If performance suffers, it is up to the language to implement proper inlining and fusion And in the meantime you lose sales, your competitors do better and start eating your market share – if you were running a company how would that make you feel? You have to be realistic. Anyway, I do appreciate that you weren't trolling and weren't dismissive of my post, so I've upvoted your response.
  - erik_seaberg 4y ago
    Map explicitly says what it does. A loop forces you to carefully (re)read it to see whether it ever skips an element, appends more than one result, or doesn’t propagate an error, because findFirst, findLast, findAll, filter, map, flatMap, and reduce all look very similar as loops. If you need a loop to work around a poor optimizer, at least use a preprocessor to generate it. Devs are expensive.

deleted 4y ago

[deleted]

SPBS 4y ago

I mean, if you strongly hold this opinion then Go is really not the language for you. And if you don't use Go then it shouldn't really bother you either. Let Go devs be Go devs.