3 ms·
At first, I though "this article just made me realized I didn't use the python itertools.tee to its full potential". But then I tried to think of a code where
by BiteCode_dev 5y ago
At first, I though "this article just made me realized I didn't use the python itertools.tee to its full potential".
But then I tried to think of a code where I would rather use this than a list comprehension or yield and a more manual control flow.
And I couldn't.
Those streams are elegant when the business logic flows perfectly like a river. Unfortunately, reality is messy, and production code will have matching, conditions, casting, extractions and transformations all over the place, leading to:
- very long chains of calls
- hard to change code when feedback pushes for it
- limiting your tooling (specially debuggers) to stuff that have exceptional support of chaining, and it's rare
- PedroBatista 5y agoCompletely agree, streams are good for when you have a ( you guess it ) stream of things where you need to do a limited and well defined amount of things.
- mrw 5y agoThis article made me realise that I don't know how to perform step-through debugging on chained of operations on Streams in Java, so I looked it up. I found out that there's Stream Trace Dialog in IntelliJ IDEA [0]. I guess it proves your point that working with Stream API requires additional tooling in cases when the code doesn't 'just work'. [0]: https://www.jetbrains.com/help/idea/analyze-java-stream-operations.html https://www.jetbrains.com/help/idea/analyze-java-stream-oper...
- chii 5y agothe 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 5y agoIdeal 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 5y agoThe 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 5y agoTired 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.