I'd argue most of the "benefits of FP" listed here apply to non-FP code too, subject to principles being followed properly.
I'd also argue that if you're using Streams specifically for performance benefits, without going into the details of stream() versus parallelStream() then you're writing FP simply because it is the "new cool toy." I've seen many developers using Streams, then having to re-write to a traditional for-loop because their data wasn't actually immutable - the stated reason is always "I wanted to use it because it's new."
Nothing about Streams helps concurrency more than a well designed OO code either, and a developer trying Streams for the first time is certainly less productive than just using Collections that they are already familiar with.
There are times when Streams is positively harmful. There are times (such as Reactive applications) where it's a great benefit.
Other than the debate about why we should be writing FP code, a good article though.
I'm Abhinava Ghosh, a Computer Science and Engineering Student who is passionate about simplifying things through technology. I work with all kinds of modern Java,Android and JavaScript Applications.
Glad you liked the article.
But just one thing to point out that writing code via streams is not necessarily for "being cool" but streams actually make your code more presentable and understandable. Compared to " spaghetti code" , and traditional for loops and etc , streams make the code quite compact and readable, even if they do not always give better performance compared to traditional style.
And yes coming to the point of parallelStream vs normal streams , yes i agree that one should use parallelStream very cautiously , as it may lead up to higher resource consumption. But i dont think junior devs face many situations where they are to take a decision between what to choose, but anyway i provided links for anyone wanting to dive deep.
I would say that Streams offers no more clarity of code than well designed OO classes. Nothing about well thought out OO gives us "spaghetti."
Indeed, use of map() is probably a code smell that's tells us the method is doing more than one thing (and is a violation of SRP). Unless, of course, immediately after map() you call collect(), and you're inside a Transformer or Adaptor pattern.
Some comments have been hidden by the post's author - find out more
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'd argue most of the "benefits of FP" listed here apply to non-FP code too, subject to principles being followed properly.
I'd also argue that if you're using Streams specifically for performance benefits, without going into the details of
stream()versusparallelStream()then you're writing FP simply because it is the "new cool toy." I've seen many developers using Streams, then having to re-write to a traditional for-loop because their data wasn't actually immutable - the stated reason is always "I wanted to use it because it's new."Nothing about Streams helps concurrency more than a well designed OO code either, and a developer trying Streams for the first time is certainly less productive than just using Collections that they are already familiar with.
There are times when Streams is positively harmful. There are times (such as Reactive applications) where it's a great benefit.
Other than the debate about why we should be writing FP code, a good article though.
Glad you liked the article.
But just one thing to point out that writing code via streams is not necessarily for "being cool" but streams actually make your code more presentable and understandable. Compared to " spaghetti code" , and traditional for loops and etc , streams make the code quite compact and readable, even if they do not always give better performance compared to traditional style.
And yes coming to the point of parallelStream vs normal streams , yes i agree that one should use parallelStream very cautiously , as it may lead up to higher resource consumption. But i dont think junior devs face many situations where they are to take a decision between what to choose, but anyway i provided links for anyone wanting to dive deep.
I would say that Streams offers no more clarity of code than well designed OO classes. Nothing about well thought out OO gives us "spaghetti."
Indeed, use of
map()is probably a code smell that's tells us the method is doing more than one thing (and is a violation of SRP). Unless, of course, immediately aftermap()you callcollect(), and you're inside a Transformer or Adaptor pattern.