Primitive streams

[Joe Bowbeer]

I'm appreciating the existence of IntStream and the other primitive
streams. IntStream most of all.

While many Java programmers are unfamiliar with reduce, there are many
FP-aware folks (ruby, groovy, etc) who will want to transfer their favorite
expressions to Java. We shouldn't go out of or way to make this transfer
difficult.

Speaking of favorite expressions, how about char streams? A lot of
functional kata are char based. But are there real  world examples where
lack of CharStream would bite?  In any event don't lose IntStream.

Joe
On Dec 28, 2012 9:55 AM, "Brian Goetz" <brian.goetz at oracle.com> wrote:

> The implementation currently has two versions of streams, reference and
> integer.  Let's checkpoint on the primitive specialization strategy, since
> it does result in a fair amount of code and API bloat (though not as bad as
> it looks, since many of the currently public abstractions will be made
> private.)
>
> So, let's start with the argument for specialized streams at all.
>
> 1.  Boxing costs.  Doing calculations like "sum of squares" in boxed world
> is awful:
>
>   int sumOfWeights = foos.map(Foo::weight).reduce(**0, Integer::sum);
>
> Here, all the weights will be boxed and unboxed just to add them up.
> Figure a 10x performance hit for that in the (many) cases where the VM
> doesn't save us.
>
> It is possible to mitigate this somewhat by having fused mapReduce
> methods, which we tried early on, such as :
>
>   foos.mapReduce(Foo::getWeight, 0, Integer::sum)
>
> Here, at least now all the reduction is happening in the unboxed domain.
>  But the API is now nastier, and while the above is readable, it gets worse
> in less trivial examples where there are more mapper and reducer lambdas
> being passed as arguments and its not obvious which is which. Plus the
> explosion of mapReduce forms: { Obj,int,long,double } x { reduce forms }.
>  Plus the combination of map, reduce, and fused mapReduce leaves users
> wondering when they should do which.  All to work around boxing.
>
> This can be further mitigated by specialized fused operations for the most
> common reductions: sumBy(IntMapper), maxBy(IntMapper), etc. (Price: more
> overloads, more "when do I use what" confusion.)
>
> So, summary so far: we can mitigate boxing costs by cluttering the API
> with lots of extra methods.  (But I don't think that gets us all the way.)
>
>
> 2.  Approachability.  Telling Java developers that the way to add up a
> bunch of numbers is to first recognize that integers form a monoid is
> likely to make them feel like the guy in this cartoon:
>
>   http://howfuckedismydatabase.**com/nosql/<http://howfuckedismydatabase.com/nosql/>
>
> Reduce is wonderful and powerful and going to confuse the crap out of 80+%
> of Java developers.  (This was driven home to me dramatically when I went
> on the road with my "Lambdas for Java" talk and saw blank faces when I got
> to "reduce", even from relatively sophisticated audiences. It took a lot of
> tweaking -- and explaining -- to get it to the point where I didn't get a
> room full of blank stares.)
>
> Simply put: I believe the letters "s-u-m" have to appear prominently in
> the API.  When people are ready, they can learn to see reduce as a
> generalization of sum(), but not until they're ready.  Forcing them to
> learn reduce() prematurely will hurt adoption.  (The sumBy approach above
> helps here too, again at a cost.)
>
>
> 3.  Numerics.  Adding up doubles is not as simple as reducing with
> Double::sum (unless you don't care about accuracy.)  Having methods for
> numeric sums gives us a place to put such intelligence; general reduce does
> not.
>
>
> 4.  "Primitives all the way down".  While fused+specialized methods will
> mitigate many of the above, it only helps at the very end of the chain.  It
> doesn't help things farther up, where we often just want to generate
> streams of integers and operate on them as integers.  Like:
>
>   intRange(0, 100).map(...).filter(...).**sorted().forEach(...)
>
> or
>
>   integers().map(x -> x*x).limit(100).sum()
>
>
>
> We've currently got a (mostly) complete implementation of integer streams.
>  The actual operation implementations are surprisingly thin, and many can
> share significant code across stream types (e.g., there's one
> implementation of MatchOp, with relatively small adapters for
> Of{Reference,Int,..}).  Where most of the code bloat is is in the internal
> supporting classes (such as the internal Node classes we use to build conc
> trees) and the spillover into public interfaces (PrimitiveIterator.Of{Int,
> **Long,Double}).
>
> Historically we've shied away from giving users useful tools for operating
> on primitives because we were afraid of the combinatorial explosion:
> IntList, IntArrayList, DoubleSortedSynchronizedTreeLi**st, etc.  While
> the explosion exists with streams too, we've managed to limit it to
> something that is tolerable, and can finally give users some useful tools
> for working with numeric calculations.
>
>
> We've already limited the explosion to just doing int/long/double instead
> of the full eight.  We could pare further to just long/double, since ints
> can fit easily into longs and most processors are 64-bit at this point
> anyway.
>
>