4 ms·

Around the middle of last decade, a significant chunk of programmers decided the following: - For loops are evil - Lambda overhead doesn't exist - Nor does t

Around the middle of last decade, a significant chunk of programmers decided the following: - For loops are evil - Lambda overhead doesn't exist - Nor does the overhead of looping over the same thing N times Whilst I kind of broadly agree with the article, sometimes you just need a for loop.

hackingthenews 6y ago
Stream overheads exists, but I have never understood why. Take the example of Java: Why are loops faster than using streams (in most cases)? Shouldn't the optimizer/jit be able to see that most streams (even chains of map, filter and reduce etc) are equivalent to simple loops and just optimize away the overhead (in the cases where loops are (obviously) faster; non-parallell, serial computing)?
- Jtsummers 6y ago
  That's exactly what Series does in Common Lisp. [0] https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node347.html https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node347.html
  - hackingthenews 6y ago
    Also Lazy data structures can achieve this. And C++ (and rust probably) compilers have no issue doing these optimizations as well.
dgb23 6y ago
Languages with FP interfaces usually do these kind of operations lazily. Rust and Clojure come to mind.
temac 6y ago
It is worse than that. A significant chunk of programmers decided that for loops are evil, even for loops with a 3 lines body, and that imperative programming languages should in general become functional, because their imperative nature is actually evil. And I also even broadly agree in theory, but in practice there are consequences, especially in languages that were not designed with a strong focus for that to begin with; or even just with a mismatching culture of most programmers using that language, etc. So why don't people just use a functional programming language if they think that is a panacea? In most case this will yield a far better functional programming experience... Also, we are going nowhere if we base all our practice on random soft opinion pieces. We should not blindly believe claims like "An explicit for loop is another common source of bugs" without serious evidences.

hackingthenews 6y ago

Stream overheads exists, but I have never understood why. Take the example of Java: Why are loops faster than using streams (in most cases)? Shouldn't the optimizer/jit be able to see that most streams (even chains of map, filter and reduce etc) are equivalent to simple loops and just optimize away the overhead (in the cases where loops are (obviously) faster; non-parallell, serial computing)?

Jtsummers 6y ago
That's exactly what Series does in Common Lisp. [0] https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node347.html https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node347.html
- hackingthenews 6y ago
  Also Lazy data structures can achieve this. And C++ (and rust probably) compilers have no issue doing these optimizations as well.

dgb23 6y ago

Languages with FP interfaces usually do these kind of operations lazily. Rust and Clojure come to mind.

temac 6y ago

It is worse than that. A significant chunk of programmers decided that for loops are evil, even for loops with a 3 lines body, and that imperative programming languages should in general become functional, because their imperative nature is actually evil. And I also even broadly agree in theory, but in practice there are consequences, especially in languages that were not designed with a strong focus for that to begin with; or even just with a mismatching culture of most programmers using that language, etc. So why don't people just use a functional programming language if they think that is a panacea? In most case this will yield a far better functional programming experience... Also, we are going nowhere if we base all our practice on random soft opinion pieces. We should not blindly believe claims like "An explicit for loop is another common source of bugs" without serious evidences.