Java Infinite Streams | Hacker News Reader

Java Infinite Streams

blog.informatech.cr

29 pointsRohitS514 comments

The comments in this thread baffle me. I find it amazing that some Java programmers are so rigid in their thinking that they can't deal with the introduction of high order function types that practically every other programming language has.

One of the reasons why it's taken so long for Java to get these features was early arguments by members of the JCP that, quite literally, Java programmers were too scared off by the "complexity" of closures. Which is ironic because I see forum postings from Java programmers looking down on Javascript/Ruby and other scripting languages as for less-rigorous/serious engineers.

Soft bigotry of low expectations? How can Javascript programmers do fine with the complexity of closures (without types!), but Java programmers are a kind of special protected class of wimps that have to be shielded from functional programming of any sort? :)

Lambdas, Streams, and other high order constructs produce vastly more readable code and encourage additional re usability through more abstraction. If you think the introduction of "for-each" in Java5 was a good thing, why be opposed to collection.forEach((x) -> expr), if you can understand for(T x : collection) expr; ? Ditto for listener patterns, filters, comparators, runnables, futures, concurrency primitives, parallel streams, all are easier to use and understand with lambdas.

If takes only a few hours and one or two samples to get used to the new lambda syntax, especially if you are familiar with HOF in JS/Ruby/Python/Perl/C#/every-other-freakin-language.

I think its a different culture. Both approaches are valid.

The issue with closures and lambda syntax for java developers is probably around the fact that it is in most cases 100% unnecessary and doesn't really add anything to the product you're building. Even our core product which is c# is devoid of such things, not because we don't know about them but because we don't need them to drag stuff out of a database and throw it on a web page.

Just because closures and lambda functions are an awesome hammer, it doesn't mean every problem is a nail.

>> This interface Supplier is one of the new functional interfaces in Java 8 and it is really appropriate for our definition here because it only contains a nullary method named get() that can return any parameterized value that we want. So we can use a lambda expression to implement this interface on the fly, this would be a closure to generate the next stream node. This is where the lazy evaluation magic can happen by means of using this parameterless closure to define the next stream cell.

Since when did Java start sounding like, not Java? Is nullary a word? Lambda? Closure, isn't that a language? It's just stream management, why does it have to sound so complicated? Time to go back to C?

nullary i believe is a word(a function that does not take in any arguments) just like how a unary function takes in a single argument, a binary takes in 2 arguments, ternary takes in 3 arguments, variadic etc etc etc... my apologies if you were being sarcastic :P (i am not a native english speaker)

I think he was being not sarcastic, but satirical – he was writing a parody of Java programmers. So he didn’t really mean that nullary wasn’t a word; he was just saying that existing Java programmers might be confused by all the changes and new ideas they will have to learn. But thanks for explaining ‘nullary’ anyway – I couldn’t remember what it meant.

Edit: Looking at jebblue’s comment again, maybe I'm understanding him wrong and he’s serious after all. Poe’s law (http://en.wikipedia.org/wiki/Poe%27s_law) is in effect. In case “Closure, isn't that a language?” is serious, here’s the answer: no, but Clojure (http://clojure.org/) is. The name “Clojure” is a pun on “closure” (source: https://groups.google.com/d/msg/clojure/4uDxeOS8pwY/UHiYp7p1...).

ahh, thanks for clearing that up and explaining the difference between the terminologies!

True, also thanks randomguy for the explanation, If I've come across that word I couldn't recall it. Normally I'd just look it up but then all the other terms hit me and I just had to write something to show the level of frustration I'm already sensing about Java 8.

If you can't beat 'em, join 'em, right?

If you can't get all the Java programmers to switch to a functional programming language, just add enough functional features to Java that you can do FP in it. It's genius, really.

Within another version or two, maybe Scala will be unnecessary.

While the addition of functional features to Java is more than welcome and should continue, here's to hoping that Java never gets as needlessly complex as Scala.

Having gained experience with both, I can happily declare Java 8 to be finally more complex than Scala.

I'm not a Scala guy, but I think Scala allows one to write less complex code than is typically written in Java (1.7 or lower). Let's not confuse the complexity of the language itself, with the typical complexity of idiomatic code written in the language.

Ruby is about as complex of a language as there is, the syntax and formal language spec are nothing short of baroque, but its flexibility and expressiveness allows you to write succinct, drop-dead simple code in it, that could only be expressed with pages of boilerplate in Java.

Adding functional features to Java will make its spec and implementation more complex, but it can make actual Java code less complex.

Finally, a way to combine the elegance of functional programming with the unwieldy, verbose syntax of Java!

Been coding Java since 98 and am baffled at how all of this new co plexity is making my life easier. Closures maybe, but the rest of this article just felt so _theoretically helpful_ and complex, bogged down with cool terms and functional fanciness. I feel old and unhip :(

I'm not all about hip, but closures are mightily useful. The article does a good job of explaining an interesting use of closures.

It's not all that complicated either, since it's basically what Unix pipes do: generate a stream of value, filter them, and consume a stream.

The article sure doesn't show a practical use, but rather enriches the standard library with useful features, and shows a pattern that can be applied to many practical problems.

Reply on news.ycombinator.com