[chii]

the ideal scenario with functional programming like this is to reason about the code, and may be algebraically model it mentally so that you "know" it works.

But i find a lot of programmers don't do that - but instead write a first version which they don't truly understand (or understand completely), and then use stepped debugging to tweak the program until they get to a verison that works to their desired outcome.

[BiteCode_dev]

Ideal scenarios rarely exist IRL. You may be in a rush. Inexperienced. Tired. On a problem you don't completely understand yet. With incomplete information. Exploring data or the problem space. Experimenting with an API. Trying to debug the code your colleague wrote, or a bug in the underlying lib.

That's why practicality beats purity in the vast majority of situations.

There is a place for purity, but you need a hell of a setup.

[jillesvangurp]

The way out of this is called unit testing. Code like this is just over engineered crap without it. Most of the effort is writing good tests. Show me the test that tells me in a concise way what this is actually supposed to do.

Mostly purity in this context boils down to weird combinations of premature optimization or complete disregard for that. Mostly it doesn't matter of course since code like this runs on trivial amounts of data so giving the garbage collector a little more work with silly stream objects, boxing/unboxing, etc. does not matter. Code like this does not matter, at all. Unless it's wrong. Hence the need for tests. Without tests it's just more likely to end up in tears. With tests, it doesn't really matter what the code looks like as long as the tests pass. If it's convoluted without tests, it's a problem waiting to happen.

[BiteCode_dev]

Tired won't make you write a proper test, not be a beginner, make you explore data more efficiently, etc.

In fact, it's very hard to write a test first when you are exploring.