3 ms·

> You can write a 15 line hard to read pipe or method chain, or a 25 line double for loop with the same runtime characteristics. The latter is always better to

> You can write a 15 line hard to read pipe or method chain, or a 25 line double for loop with the same runtime characteristics. The latter is always better to maintain, while the former is always more clever. You’ve just told us which one you’re more familiar with, that’s all, which is exactly what the other commenter was pointing out. This one also belongs on the list in that comment. Beyond familiarity and subjective preference, there are benefits to the pipe approach that come from its functional nature. Determining that a for loop is a pure pipeline can be tricky in general, which contradicts your idea about which one is harder to read. And the ability to get reliable parallelism for free - e.g. Java’s parallelStream - is not a feature of for loops.

908B64B197 3y ago
> And the ability to get reliable parallelism for free - e.g. Java’s parallelStream - is not a feature of for loops. This is the big one. For large datasets or computationally intensive processing the speed difference will be noticeable. One of the issues with "cleverness" is also that code that's trivial for John Carmack to understand might not be for $BODY_SHOP_RESSOURCE_200353. I recall a self taught dev (or maybe from a bootcamp) coming up with a cascade of nested if-else, nested 8 deep. Someone with a background in CS asked him what he was trying to do and basically concluded that what he was trying to do could be expressed as a state machine. To which the initial dev replied that it was "way too fancy" and that he didn't need the code to be fancy, just work.
cookieperson 3y ago
I think if you took a survey about which code is easier to read a pile of expressions acting as closures inside of nested method calls or a loop, you would likely find most programmers have comfort with one over another. That's objective because it's how pseudocode, the most widely used language agnostic abstraction used in computer science beyond plain text, is written. But that's really not the point and it never was, right? You can grill me if you want and say I am the problem! Zing ouch got me so good! Those HN points will get racked up, so much winning... Or you can read between the lines. I drew an unspecific example with microseconds of thought behind it. People who know what I am saying know what I conveyed is fine. People who know me, know I regularly use pipes and chained method calls all day. The point is, the paradigm could go either way, it depends on culture(reading the room), and design decisions. Had I of flipped my example and said "method calls can make code way cleaner than for loops" which in some contexts is equally valid your antiparticle HN contributor would make the same argument you made calling me the problem. Get it? I would say people trying to shit on everyone around them for being casual are more of a problem then anything else. Especially in collaborative development environments. That supercedes any code anyone could contribute. But that's my take and I'm not going to suggest it belongs on some arbitrary list of ad hoc HN rules (of which none hold water)... I won't be writing a five pager with examples where what I said was sound valid and best praxis, I have nothing to prove, and that was never the point. Everyone who knows what I'm talking about gets it. Happy flag planting with imaginary enemies.
- tacitusarc 3y ago
  Hey man, this feels like an overly defensive response to me. I don’t think there was an attempt to attack you personally. Just an outside observer opinion. Have a nice day!
KronisLV 3y ago
> And the ability to get reliable parallelism for free - e.g. Java’s parallelStream - is not a feature of for loops. Why not? As in, it just seems like a language design issue, there's no reason why you technically couldn't use the "simpler" syntax. For example, what prevents us from having: parallel for (Type instance: collection) { // code for each iteration } Of course, there are other reasons to consider using streams and such, though admittedly they can sometimes be cumbersome to work with: especially when you would like to step through all of the transformations that a particular object instance undergoes (or when you map stuff and create new ones, or reduce lists into fewer items), as opposed to needing to tinker with lots of conditional breakpoints in the debugger.
- antonvs 3y ago
  > Why not? If the construct you propose were feasible, why do you think it doesn’t exist? The reason is that it’s not feasible. Compositional pipelines involve constraints and properties that an imperative for loop doesn’t support.
  - KronisLV 3y ago
    > If the construct you propose were feasible, why do you think it doesn’t exist? Because it already exists as a part of the Stream API in a way that doesn't change the language much: since you can mostly use .parallelStream() or .stream().parallel() there's basically no need for the "old" syntax to enable the same functionality. That doesn't mean that it's somehow unfeasible, since the implementation of the example "parallel for" construct would just need to execute the code in the loop body with a ThreadPool. The Ada language has a nice example of parallel loops like that https://ada-lang.io/docs/arm/AA-5/AA-5.5#p26 https://ada-lang.io/docs/arm/AA-5/AA-5.5#p26 Of course, there are other benefits to streams and lazy evaluation, but perhaps that's besides the point.

908B64B197 3y ago

> And the ability to get reliable parallelism for free - e.g. Java’s parallelStream - is not a feature of for loops. This is the big one. For large datasets or computationally intensive processing the speed difference will be noticeable. One of the issues with "cleverness" is also that code that's trivial for John Carmack to understand might not be for $BODY_SHOP_RESSOURCE_200353. I recall a self taught dev (or maybe from a bootcamp) coming up with a cascade of nested if-else, nested 8 deep. Someone with a background in CS asked him what he was trying to do and basically concluded that what he was trying to do could be expressed as a state machine. To which the initial dev replied that it was "way too fancy" and that he didn't need the code to be fancy, just work.

cookieperson 3y ago

I think if you took a survey about which code is easier to read a pile of expressions acting as closures inside of nested method calls or a loop, you would likely find most programmers have comfort with one over another. That's objective because it's how pseudocode, the most widely used language agnostic abstraction used in computer science beyond plain text, is written. But that's really not the point and it never was, right? You can grill me if you want and say I am the problem! Zing ouch got me so good! Those HN points will get racked up, so much winning... Or you can read between the lines. I drew an unspecific example with microseconds of thought behind it. People who know what I am saying know what I conveyed is fine. People who know me, know I regularly use pipes and chained method calls all day. The point is, the paradigm could go either way, it depends on culture(reading the room), and design decisions. Had I of flipped my example and said "method calls can make code way cleaner than for loops" which in some contexts is equally valid your antiparticle HN contributor would make the same argument you made calling me the problem. Get it? I would say people trying to shit on everyone around them for being casual are more of a problem then anything else. Especially in collaborative development environments. That supercedes any code anyone could contribute. But that's my take and I'm not going to suggest it belongs on some arbitrary list of ad hoc HN rules (of which none hold water)... I won't be writing a five pager with examples where what I said was sound valid and best praxis, I have nothing to prove, and that was never the point. Everyone who knows what I'm talking about gets it. Happy flag planting with imaginary enemies.

tacitusarc 3y ago
Hey man, this feels like an overly defensive response to me. I don’t think there was an attempt to attack you personally. Just an outside observer opinion. Have a nice day!

KronisLV 3y ago

> And the ability to get reliable parallelism for free - e.g. Java’s parallelStream - is not a feature of for loops. Why not? As in, it just seems like a language design issue, there's no reason why you technically couldn't use the "simpler" syntax. For example, what prevents us from having: parallel for (Type instance: collection) { // code for each iteration } Of course, there are other reasons to consider using streams and such, though admittedly they can sometimes be cumbersome to work with: especially when you would like to step through all of the transformations that a particular object instance undergoes (or when you map stuff and create new ones, or reduce lists into fewer items), as opposed to needing to tinker with lots of conditional breakpoints in the debugger.

antonvs 3y ago
> Why not? If the construct you propose were feasible, why do you think it doesn’t exist? The reason is that it’s not feasible. Compositional pipelines involve constraints and properties that an imperative for loop doesn’t support.
- KronisLV 3y ago
  > If the construct you propose were feasible, why do you think it doesn’t exist? Because it already exists as a part of the Stream API in a way that doesn't change the language much: since you can mostly use .parallelStream() or .stream().parallel() there's basically no need for the "old" syntax to enable the same functionality. That doesn't mean that it's somehow unfeasible, since the implementation of the example "parallel for" construct would just need to execute the code in the loop body with a ThreadPool. The Ada language has a nice example of parallel loops like that https://ada-lang.io/docs/arm/AA-5/AA-5.5#p26 https://ada-lang.io/docs/arm/AA-5/AA-5.5#p26 Of course, there are other benefits to streams and lazy evaluation, but perhaps that's besides the point.