Live data from Hacker News

Java Streams and State

blog.frankel.ch

21–30 of 33 posts

Re: Java Streams and State

#21

As someone who hasn't written Java since college, I am not familiar with streams. Is this similar in principle to a Python/JS generator function?

It's more comparable to Python iterators in combination with itertools, sequence comprehensions, and a few other things.

It's arguably more powerful in that it's got some more bits and bobs out-of-the-box, and it's easier to do parallel stuff with it. But it's also arguably less powerful in that it's not particularly open for anyone who isn't a JDK developer to adapt for their own purposes. To make your own Python iterator that will interact nicely with anything else that's designed to operate on iterators, you only have one method you have to implement. To make your own implementation of Java's Stream interface, you've got a rather daunting list of 40 you have to implement.

Re: Java Streams and State

#22

As someone who hasn't written Java since college, I am not familiar with streams. Is this similar in principle to a Python/JS generator function?

I wonder how people who stopped suff.. writing java before java 8 feel about lambda expressions and streams.

I've been writing Java for 20 years. Streams are a definite improvement, but half the time I find myself rewriting a streams approach to an old-fashioned loop to make the code more readable.

Re: Java Streams and State

#24
post #23

Earlier quoted context omitted.

That's my opinion too, I don't think I can consider ever touching java prior r8.

Java 5/6 every day of my life and I want to die.

Are you allowed to produce jar libs (possibly written in clojure/kotlin/foo) ?

Re: Java Streams and State

#25
post #23

Earlier quoted context omitted.

Java 5/6 every day of my life and I want to die.

Are you allowed to produce jar libs (possibly written in clojure/kotlin/foo) ?

It would probably be possible, but the business itself is too old and not succeptable to change.

Re: Java Streams and State

#26
Small want item about Java Streams... I wish this was a language feature. Allow type declarations in lambdas:

currently: collection.stream()....bunch of stuff....forEach(item -> something(item))....

this would be nice: collection.stream()....bunch of stuff....forEach(String item -> something(item))....

When you get 50 levels deep on a really long lambda, this would make debugging the things far easier.

Re: Java Streams and State

#27
post #10

This is only marginally better, as the computation logic is still "hidden" in the lambda. This is a very weird statement. It's hidden in exactly the place where it's needed! Where is it hidden from? Where else would you need it? If you're reading the code, it's right there, you don't have to click to definition like you do with Pair::next. What should I get from reading Pair::next? There's no natural "next" for pairs…

I really like your summary of the situation. I'd add that the author seems to have tried to fix a functional readability problem with OO techniques, ending up with the same kingdom of nouns problem - the worst of both worlds.

I think the functional solution would be to separate increment and transform: Stream.iterate(0, i -> i + 1).map(i -> new Pair(i, Math.Pow(i, 2));

Re: Java Streams and State

#28

Small want item about Java Streams... I wish this was a language feature. Allow type declarations in lambdas: currently: collection.stream()....bunch of stuff....forEach(item -> something(item)).... this would be nice: collection.stream()....bunch of stuff....forEach(String item -> something(item)).... When you get 50 levels deep on a really long lambda, this would make debugging the things far easier.

It is definitely possible to specify the type of the parameter(s) in a lambda expression in Java.

Re: Java Streams and State

#29
post #10

This is only marginally better, as the computation logic is still "hidden" in the lambda. This is a very weird statement. It's hidden in exactly the place where it's needed! Where is it hidden from? Where else would you need it? If you're reading the code, it's right there, you don't have to click to definition like you do with Pair::next. What should I get from reading Pair::next? There's no natural "next" for pairs…

I also believe you can apply the "do one thing per line" here. it's a bit weird to do math directly in the constructor argument.

Re: Java Streams and State

#30
post #22

Earlier quoted context omitted.

I wonder how people who stopped suff.. writing java before java 8 feel about lambda expressions and streams.

I've been writing Java for 20 years. Streams are a definite improvement, but half the time I find myself rewriting a streams approach to an old-fashioned loop to make the code more readable.

When you say "readable," do you mean to OO programmers? Functional programmers? All programmers?

For example, as a 5-year Clojure convert who wrote Java for 15 years before that, old-fashioned loops are less readable now, as they hide the essentials of what is really happening. For example, you might be mapping a collection from one type of value to another, or reducing it to some other form, etc. But both use loops. You have to scan all over the place in the loop construct to see what it's really doing. I'd much rather see the function that is happening than the procedure by which the function is accomplished.

Post reply on HN