I don't understand what do they mean at 11:50 ? Why is it hard to preserve laziness with this example? What does he mean 'findFirst' is at the end, so everything need to be evaluated? I run the example code, added extra peek-s, in case if I forgot how streams work. It only run until it the first word, just as I thought it would.
In prev example Pattern.spliAsStream() was used to lazily read line worb-by-word. Here you need `words` array, because you need its length - to be able to IntStream.range().
The stream approach splits the String element by element. So in the end you just split the elements you need. If you first build the array, then process it, you split all the line, which is more costly. That only works if you have a findFirst() or findAny(), something that doesn't (always) need to process all the stream to produce a result. If you have a toList() at the end, you don't save any CPU cycles, but you still save on the memory footprint, as the stream doesn't create the array before starting to process the elements.
@@JosePaumard The stream approach, as shown on the slide, still uses Pattern.split (before using IntStream), which returns an array of strings, so it doesn't split just the elements we need. So I still don't understand what do they mean by "it was hard to preserve lazyness... Everything need to be evaluated before we get to that" (Using findFirst stops the processing at the first element, so everything is not evaluated before that, as you said.) This doesn't make sense to me, unless he misunderstands, how streams work, which I don't think is the case. Maybe he misspoke. Or maybe I'm the dummy...
@@A3A3adamsan They are talking about the difference from the first example which used splitAsStream to get the words one by one lazily. The second example did the split into an array which is not lazily - that's how I understood it.
You could also use a Stream instead of an Optional, this was the pattern before mapMulti() was added (JDK 16). But then you create a bunch of Stream or Optional, just to open them, and to get rid of them. That's an overhead and mapMulti() was added to avoid paying this price.
Streams demo well; The 1st example was pretty. Everything after that is an unreadable, undebuggable mess. Streams are responsible for f*cking up code quality everywhere
Didn't watch, but I agree with the message. Pull streams can be great if builtin and everything is built around them (e.g. Python iterators/generators). Push streams... tend to have negative balance of pros an cons, at least in my experience. Wherever I added them, for seemingly solid reasons... I still removed them later on.
Depends on your use case and familiarity with the streams API. I think they're pretty readable but perhaps regardless if you're doing bulk processing then they may make sense.
I’m in a situation at work where I’ve been working as a Java Developer for about 7 years across various corporations. In each company, I’ve worked in the Scrum methodology with sprints. I’ve noticed a recurring pattern, and in my current job, it’s the same: managers use sprints as a tool for excessive control and apply pressure to deliver everything within the sprint. They often talk about deadlines and due dates. The atmosphere is such that I always feel behind and like I’m not doing enough. I struggle with working under pressure in sprints, and because of this, I’m considering changing to a position where I wouldn’t have to work in sprints. What advice could you give?
> I struggle with working under pressure in sprints, Don't give a fuck about them. You are human, not a machine. Just work as usually, do not overtime, make some green tea and that's it. And do not overreact on such things. The only exception when you can be under the pressure and maybe overtime - deploying to prod or finishing your release.
I loved this session, and I can't wait for the next iteration when the Gatherer API lands.
Great presentation
I miss zipWithIndex from Scala :(
I would expect to see such presentation on my 1st course in my university, not on devoxx
In this case I encourage you to join a coding boot camp, not go to university. At best you should be seeing this in a 2nd year or later course.
@vss963
My argument was about, that this presentation is for newbies and not experienced devs, who paid a check to see these guys in person.
One level of nesting is manageable but perhaps try to show how bad two is.
I don't understand what do they mean at 11:50 ? Why is it hard to preserve laziness with this example?
What does he mean 'findFirst' is at the end, so everything need to be evaluated?
I run the example code, added extra peek-s, in case if I forgot how streams work. It only run until it the first word, just as I thought it would.
In prev example Pattern.spliAsStream() was used to lazily read line worb-by-word. Here you need `words` array, because you need its length - to be able to IntStream.range().
The stream approach splits the String element by element. So in the end you just split the elements you need. If you first build the array, then process it, you split all the line, which is more costly. That only works if you have a findFirst() or findAny(), something that doesn't (always) need to process all the stream to produce a result. If you have a toList() at the end, you don't save any CPU cycles, but you still save on the memory footprint, as the stream doesn't create the array before starting to process the elements.
@@JosePaumard The stream approach, as shown on the slide, still uses Pattern.split (before using IntStream), which returns an array of strings, so it doesn't split just the elements we need.
So I still don't understand what do they mean by "it was hard to preserve lazyness... Everything need to be evaluated before we get to that"
(Using findFirst stops the processing at the first element, so everything is not evaluated before that, as you said.)
This doesn't make sense to me, unless he misunderstands, how streams work, which I don't think is the case. Maybe he misspoke. Or maybe I'm the dummy...
@@A3A3adamsan Sorry what I was saying was referring to the slides 10-11 at 7:46, that Pattern.uses splitAsStream().
@@A3A3adamsan They are talking about the difference from the first example which used splitAsStream to get the words one by one lazily. The second example did the split into an array which is not lazily - that's how I understood it.
41:25 - wouldn't it be more natural to use Optional?
and then .filter(Optional::isPresent).map(Optional::get) or simply .flatMap(Optional::stream)
You could also use a Stream instead of an Optional, this was the pattern before mapMulti() was added (JDK 16). But then you create a bunch of Stream or Optional, just to open them, and to get rid of them. That's an overhead and mapMulti() was added to avoid paying this price.
@@JosePaumard Thank you! I wondered if the extra 0-1 element stream created by Optional::stream causes overhead. Now I know :)
Streams demo well; The 1st example was pretty.
Everything after that is an unreadable, undebuggable mess.
Streams are responsible for f*cking up code quality everywhere
java syntax is messy and verbose, need to adapt kotlin/scala way of streaming - (just syntatic sugar it for us)
No it does not. Java doesn't need to be a trendy language, if you want something less verbose then just use kotlin or scala as you said
Is it only me that sees every of these non-stream examples as more maintanaible in the long run?
Didn't watch, but I agree with the message. Pull streams can be great if builtin and everything is built around them (e.g. Python iterators/generators). Push streams... tend to have negative balance of pros an cons, at least in my experience. Wherever I added them, for seemingly solid reasons... I still removed them later on.
Depends on your use case and familiarity with the streams API. I think they're pretty readable but perhaps regardless if you're doing bulk processing then they may make sense.
I’m in a situation at work where I’ve been working as a Java Developer for about 7 years across various corporations. In each company, I’ve worked in the Scrum methodology with sprints. I’ve noticed a recurring pattern, and in my current job, it’s the same: managers use sprints as a tool for excessive control and apply pressure to deliver everything within the sprint. They often talk about deadlines and due dates. The atmosphere is such that I always feel behind and like I’m not doing enough. I struggle with working under pressure in sprints, and because of this, I’m considering changing to a position where I wouldn’t have to work in sprints. What advice could you give?
> I struggle with working under pressure in sprints,
Don't give a fuck about them. You are human, not a machine. Just work as usually, do not overtime, make some green tea and that's it.
And do not overreact on such things.
The only exception when you can be under the pressure and maybe overtime - deploying to prod or finishing your release.