[0]: https://www.jetbrains.com/help/idea/analyze-java-stream-oper...
[0]: https://www.jetbrains.com/help/idea/analyze-java-stream-oper...
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.
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.
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.
In fact, it's very hard to write a test first when you are exploring.