

Java Infinite Streams - RohitS5
http://blog.informatech.cr/2013/03/11/java-infinite-streams/

======
cromwellian
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.

~~~
hp50g
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.

------
jebblue
>> 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?

~~~
kyllo
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.

~~~
norswap
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.

~~~
kyllo
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.

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

------
rkalla
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 :(

~~~
norswap
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.

