4 ms·

I hate this. I don't know why people insist on forcing this programming style into every language. Loops exist for a reason. They are simple, they work, and nin

I hate this. I don't know why people insist on forcing this programming style into every language. Loops exist for a reason. They are simple, they work, and nine times out of ten, they are faster than this crap. Not every program needs to be golfed down to one line.

ironmagma 5y ago
Then don’t use it? Bad code is written in every language, you don’t need a library to make that possible.
deleted 5y ago
[deleted]
bobbylarrybobby 5y ago
The point of these functions is to give names to common operations that happen in loops so that you can read the code more quickly. Map: we're transforming values. Filter: we're dropping values. Reduce: we're accumulating. Yes you can write these out explicitly in a loop but then you actually have to read all of the associated noise to grok what's happening. In addition, the method-based approach scopes the variables to each individual call so there's no risk of, say, transforming the loop variable but then accidentally filtering based on the original instead of the transformed.
erik_seaberg 5y ago
Goto was simple and fast and did anything. We replaced that with if/then/else/while/foreach/return/throw because each of those clearly expresses what we’re currently doing and especially what we aren’t.
chlorion 5y ago
You could very easily say the same thing about goto vs structured loops, for example: "I hate this. I don't know why people insist on forcing this programming style into every language. Goto and labels exist for a reason. They are simple, they work, and nine times out of ten, they are faster than this crap." It's just a more structured way to express common operations that we use loops for, and it does has objective technological advantages over raw loops when implemented and used correctly. As for performance, that is going to vary language to language, but in general iterator processing pipelines are not slower and can even be faster than raw loops. Whether this is the case in Go, I have no idea. With all of that being said, I am not sure if I would use this style of programming in Go since it doesn't feel idiomatic (yet?).

ironmagma 5y ago

Then don’t use it? Bad code is written in every language, you don’t need a library to make that possible.

deleted 5y ago

[deleted]

bobbylarrybobby 5y ago

The point of these functions is to give names to common operations that happen in loops so that you can read the code more quickly. Map: we're transforming values. Filter: we're dropping values. Reduce: we're accumulating. Yes you can write these out explicitly in a loop but then you actually have to read all of the associated noise to grok what's happening. In addition, the method-based approach scopes the variables to each individual call so there's no risk of, say, transforming the loop variable but then accidentally filtering based on the original instead of the transformed.

erik_seaberg 5y ago

Goto was simple and fast and did anything. We replaced that with if/then/else/while/foreach/return/throw because each of those clearly expresses what we’re currently doing and especially what we aren’t.

chlorion 5y ago

You could very easily say the same thing about goto vs structured loops, for example: "I hate this. I don't know why people insist on forcing this programming style into every language. Goto and labels exist for a reason. They are simple, they work, and nine times out of ten, they are faster than this crap." It's just a more structured way to express common operations that we use loops for, and it does has objective technological advantages over raw loops when implemented and used correctly. As for performance, that is going to vary language to language, but in general iterator processing pipelines are not slower and can even be faster than raw loops. Whether this is the case in Go, I have no idea. With all of that being said, I am not sure if I would use this style of programming in Go since it doesn't feel idiomatic (yet?).