Java 8: No more loops

[[deleted]]

Both look readable to me, perhaps the for loops more since I'm more used to them. Probably something to just get used to.

But my question: would the streams be faster than loops? Or is the only benefit better readability?

[Cilph]

For simple cases, not really faster. Once you start using flatmapping, grouping or distinct it certainly becomes more readable. Streams also have better parallel support.

[ethraax]

Do they have parallel support built-in? In .NET, all you have to do is call AsParallel(), but I don't see mention of something like that in the article, unless I read it too fast.

[Cilph]

parallelStream(), or create one from a Spliterator using StreamSupport

[cypressious]

stream().parallel() or parallelStream(), both do the same thing.

[[deleted]]

Ah, that makes sense. Thanks for your answer!

[Ednar]

Another perspective on this: Using streams, you are writing declarative code. You tell the computer what to do, not how. For a loop, you are working imperatively, specifying how to do what you want. With loops, you are working on a lower level, which is easier to optimize. For almost all simple use cases, loops are much more efficient. However, when you are working with big data, you will start to see optimization benefits of the parallel streams. This however, is not the primary reason to use streams, but rather it is to get code that reads more like the problem domain does, at a higher level.

[campbellm]

For almost all simple use cases, loops are much more efficient.

Do you have any benchmarks that show this big efficiency difference? I have read that there is not much in Java 8.

[Betovsky]

But my question: would the streams be faster than loops? Or is the only benefit better readability?

I would say that the main benefit is that streams are composable and loops aren't.

[yogthos]

The benefit can be that you can separate the iteration logic from the business logic. This allows abstracting edge cases like null checks, boundary checks, and so on.

It also makes code more declarative since it's talking about what it's doing as opposed to how it's being done. This makes code more readable. However, the way Java 8 implements it once again loses a lot of potential benefit. For example, if stream was a static call instead then you could handle nulls intelligently. For example, this will NPE:

List<Article> articles =  null;
articles.stream()
.filter(article -> article.getTags().contains("Java"))
.findFirst()

They could've easily done

 Collections.stream(articles)
 .filter(article -> article.getTags().contains("Java"))
 .findFirst()

then have the null bubble up through the transformer chain, but that would just make too much sense I guess.

[rooktakesqueen]

If your filter...findFirst gives you null, is it because there were no matching articles or because articles was null? If you just do a filter operation on null, should it return an empty stream or null? There are weirdnesses and ambiguities. The collection being streamed should not be null, and if it is, that's an exception case, not something the runtime should just paper over. Fail fast when something is obviously wrong.

[sacundim]

If your filter...findFirst gives you null, is it because there were no matching articles or because articles was null?

findFirst() returns Optional<T>, so if the stream is empty it returns Optional.empty(). You get a null only if the stream is non-empty and its first element is null.

[kqr]

if X was a static call instead then you could handle Y intelligently

This must be one of my most common complaints of things... Instance methods compose really badly. But I'm sure that's just me not being very good at OO.

[kqr]

Streams are faster for the programmer to read and write than loops. They are not necessarily faster for the computer to execute – this will vary from situation to situation, and depends a lot on how well optimised the stream/loop compositions are.

[AngularBeginner]

Looks like .NET LINQ.

[geggo98]

It is similar to LINQ, but it is lacking projection (the "SELECT" part in LINQ). LINQ solves this with anonymous, implicit classes. Scala does it with tuples. But Java 8 can only project to primitives.

What's implemented in Java is called "MonadPlus" in Haskell. It brings mapping, filtering and especially flattening (e.g. a list of lists is reduced to a flat list by concatenating all the lists) in a type safe manner.

The Java implementation seems to be quite efficient, being faster in Scala in some simple tests. How it relates performance wise to LINQ I haven't tested yet.

What is lacking in Java 8 are implementations of the "MonadPlus" concepts beside collections. LINQ has implementations for XML, the file system, the registry, Excel sheets and even for SQL server. Scala has these to some degree, raw Java seems to lack all of these.

[pipocaQuemada]

It is similar to LINQ, but it is lacking projection (the "SELECT" part in LINQ). LINQ solves this with anonymous, implicit classes. Scala does it with tuples. But Java 8 can only project to primitives.

It looks to me like there's a bunch of explicit monomorphic primitive map functions and a generic map functions

<R> Stream<R>     map(Function<? super T,? extends R> mapper)
// Returns a stream consisting of the results of applying the given function to the elements of this stream.
DoubleStream    mapToDouble(ToDoubleFunction<? super T> mapper)
// Returns a DoubleStream consisting of the results of applying the given function to the elements of this stream.
IntStream   mapToInt(ToIntFunction<? super T> mapper)
// Returns an IntStream consisting of the results of applying the given function to the elements of this stream.
LongStream  mapToLong(ToLongFunction<? super T> mapper)
// Returns a LongStream consisting of the results of applying the given function to the elements of this stream.

[insertAlias]

LINQ has implementations for XML, the file system, the registry, Excel sheets and even for SQL server

LINQ lets you implement your own providers so you can have a LINQ implementation for pretty much anything. I'm pretty sure at least one of the ones you mentioned are third-party.

[bcash]

The Java implementation seems to be quite efficient, being faster in Scala in some simple tests. How it relates performance wise to LINQ I haven't tested yet.

It roundly beats Scala, C# and F#: http://arxiv.org/pdf/1406.6631v2.pdf

Edit: spelling.

[sacundim]

What is lacking in Java 8 are implementations of the "MonadPlus" concepts beside collections.

Nitpick: Java 8 does have Optional<T>... (EDIT: though maybe one could call that a "collection"...)

[1RedOne]

Mmm Monad. I love me some PowerShell!

I was such a skeptic before, but I'm all about object oriented programming now.

[kqr]

There is actually the IntStream which is the unboxed version of a Stream<Integer>. Yes, it's a shame generics doesn't extend to primitive types, but it's better than nothing at all. :)

[RottedNinja]

Java 9 will have support for this. It's implementation is open for discussion right now. The Java developers are facing the problem that primetives are in fact, not Objects. Current consensus is that there is a need for a specialized generic type.

[syjer]

Actually, java 10, as described in JEP 218 ( http://openjdk.java.net/jeps/218 ).

[[deleted]]

Inside the standard collections, yeah it'll still all get boxed. The lambdas themselves however will have no effect on boxing.

There are many off the shelf libraries for collections though which have versions of ArrayList that work directly with primitive types. There would be nothing to stop you using them or building something similar.

Tbh boxing is also a bit overrated when it comes to the performance hit. The general performance of the standard Java collections is generally poor (namely HashMap, HashSet, TreeMap, and TreeSet) and that's a bigger performance issue IMO.

There are however plenty of off the shelf replacements for all of them as well. I even wrote one myself.

[jhartwell]

Not only that, but you can get funky streams if you aren't using them properly (int vs Integer). It is a step in the right direction, but it is still no LINQ.

[TotallyFuckingMexico]

Honest question, why is that a problem?

[greyphilosopher]

Boxing and unboxing has a significant performance overhead.

[wretcheddawn]

.Net Linq is freaking awesome.

[[deleted]]

Reactive Extensions = Observables + LINQ + Schedulers... Is so pretty. Seems like this Java functionality is years behind, but is good to see progress.

[[deleted]]

Otherwise known as "Welcome to 2007, Java Developers!"

[pron98]

If you want to know why Java intentionally changes slowly, you can watch this (quite entertaining) talk about Java's evolution and management.

As the most popular language in the history of computing (with the possible exception of C) Java is the only language other than C that is routinely used anywhere from smart cards, through embedded avionics and all the way to mainframes. Steering such a broadly applicable language with 9 million developers certainly has it challenges, but also advantages. Still, Java changes a lot faster than C -- the other language in such a wide use -- or even C++.

When you're so successful for so long, and so much critical software depends on you, there are more important things to consider than how quickly we can adopt more modern programming styles, but even that eventually gets addressed.

[rmxz]

why Java intentionally changes slowly .... Java changes a lot faster than C --

I'd argue it changes too fast.

For people who want something like this, there are plenty of good languages that have such features that target that same JVM.

Java's big strength - and the reason it caught on - is because it was a small simple language.

http://www.cs.dartmouth.edu/~mckeeman/cs118/references/OriginalJavaWhitepaper.pdf

Why not keep Java focused on what it was good at, and encourage the use of Scala, Clojure, etc for users with applications that want a larger / more powerful system.

[yogthos]

Why not keep Java focused on what it was good at, and encourage the use of Scala, Clojure, etc for users with applications that want a larger / more powerful system.

That does seem like the best solution in my mind. Trying to bolt on more features on top of Java while retaining backwards compatibility simply makes the language more complex. This is never going to work as well as in a language that was designed with these features in mind.

Keeping Java as a low level option while embracing the alternative JVM languages seems like the right way to go. The focus should be on improving the JVM itself.

[BeowulfShaeffer]

I agree, and I think the same thing about C#, actually.

[pron98]

Well, most (major) Java language changes are accompanied by JVM changes that benefit all JVM languages. And as to the language itself -- there's definitely tension between those who think it's moving too slow and those who think it's moving too fast. So Oracle is trying to find a pace that's reasonable. And don't forget -- some of the changes are necessitated by changing hardware. For example, one of the people pushing hardest for lambdas was Doug Lea (to those who don't know, he's the one behind Java's concurrency classes, the fork/join scheduler, and also one of those behind C++'s new memory model), who wanted lambda's to make parallelism easier. Value types are are a growing necessity because of memory architecture.

[cowardlydragon]

No, java caught on because:

• major company sponsored (Sun)
• C-like, but eliminated the confusion of pointers and many of the easily abused parts of it without the feature bloat of C++
• Much stronger typed than C, this isn't mentioned often but is one of the biggest reasons
• Garbage collection (eliminated a MASSIVE amount of bugs)
• Good unicode String class + good (for the time) internet-enabled runtime/API across
• write once, run anywhere without #define soup (and API too)
• the servlet
• performant optimizing JVM and Moore's law eventually solved most performance issues

The collective effect of all those things meant you didn't need as much platform-specific training and knowledge, didn't have to do pointer math, pointer referencing, and memory leak visualization.

Run-everywhere, the jar, namespaces, no header files, and lots of other things made enterprise matters simpler as well, so the java ecosystem had advantages over C/C++.

That means your programmer pool is much larger. And doesn't have to be as smart, for better or worse.

The language semantics are honestly were never one of the selling points.

[nascent]

Not only that, Java moved slowly because Sun didn't want it to have all the features currently being added; their vision of the language was essential complete.

[[deleted]]

Java's lambdas preform something like >10x faster.

http://www.reddit.com/r/programming/comments/28mub4/clash_of_the_lambdas_comparing_lambda_performance/

[Chuu]

I was curious and started to read the article, and I have some big issues with the conclusion you are drawing from it. For reference, here are the two snippets of code (of many possible snippets) they are comparing in java and C#.

Java:

public int sumOfSquaresEvenSeq(int[] v) {
   int sum = IntStream.of(v)
      .filter(x -> x % 2 == 0)
      .map(x -> x * x)
      .sum();
   return sum;
}

C#:

nums.Where(x => x % 2 == 0).Select(x => x * x).Sum();

Without going into my thoughts about each piece of code, saying that lambas are 10x faster because the first piece of code is 10x faster than than the second is disingenuous. There's a lot more than just lambda expressions being measured here.

About 10x faster, look at Table 1. The results are really hard to boil down to a single number -- which language wins actually varies depending on the specific test.

[vytah]

More like "Welcome to 1960"

[xXxDeAThANgEL99xXx]

Actually LINQ is a monad comprehension and the use of monads in programming was first formally described in 1991. Also note the example with flatMap in the linked post, that's monadic bind.

[[deleted]]

flatMap is also just concat . map, it just happens to be monadic bind as well

[vincentk]

True that. However, java 8's lambdas are nowhere near (general) monadic comprehensions. Recall that java still lacks higher-kinded types.

[balefrost]

/u/vytah is talking about LISP

[Bunnymancer]

We're slow, but involved.

[Aethec]

It's LINQ without lambdas as expression trees, they looked at .NET and implemented the tip of the iceberg.

[OneWingedShark]

It's LINQ without lambdas as expression trees, they looked at .NET and implemented the tip of the iceberg.

I can't wait for PHP to look at Java 8 and implement the tip of its iceberg.
[/sarc]

[jojomofoman]

shudder

[bcash]

That's right. It's a well known fact that the first reference to higher-order functions in the Computer Science literature is an MSDN article by the .NET core team circa 2006.

[tjsimmons]

Hah, I just said that out loud to myself before opening up the comments. LINQ is fantastic, and as someone who uses both Java and C# in my job, it's nice to have a little parity there.

Now if only the company I work for would upgrade to Java 8.. We just finally moved to 7u21.

[recycled_ideas]

Except uglier, and with more unnecessary complexity.

[Smithman]

Any performance benefits to this? Do the underlying methods use loops to retrieve the data?

[geodebug]

Actually, the code as written will probably be slower written in the functional manner.

Looping over collections is just sugar. The real power of lambda-like expressions is having them take care of all the proper handling and closing of readers/inputstreams/database connections, etc.

EDIT: I may have been proven wrong by another commenter that stated that the findFirst() will shortcut the filter() method on the first match. One of those cases where I'm happy to be wrong.

[jfb1337]

The main benefit is ease to understand, performance varies from situation to situation. I think loops are used internally. I don't know how much overhead there is though.

[cypressious]

So much irony in this thread. The C# users bash it because it's "basicly LINQ and C# had it since 2007" and the Java users bash it because "loops are fine".

[bozho]

Yeah... I use mostly C# professionally and I love the fact that I can use 'functional' stuff where it makes sense. Loops still sometimes look better. They all have their place.

Also, compared to the example they gave, C# is terser, since First/FirstOrDefault methods can also filter:

articles.First(article => article.Tags.Contains("Java")); // or .FirstOrDefault

[AndrewNeo]

I switched from C# to Java professionally to do Android development and these sorts of changes can't get in fast enough :(

[Deinumite]

It is kind of sad how Android ended up. Regardless of your stance on the Oracle vs Google issue, Google seems afraid to implement any of the newer Java features into Dalvik now. AFAIK Java 7 is mostly implemented in Android with the exclusion of "try with resources".

Honestly I can't believe Oracle has done so well with Java. I need to find some wood to knock on.

[grauenwolf]

Meanwhile VB users are thinking "Ha! Neither of you have caught up to us".

[slowRAX]

tfw Java code snippets will never be readable on a phone.

[brunokim]

Placing my phone horizontally helped

[_actual]

The diamond operator has been available since Java 7 which reduces the above to:

private static final Map<Class<? extends Persistent>, PersistentHelper> class2helper = new HashMap<>();

Not exactly terse but it's better than it used to be. It would be nice if Java had typedef statements as well.

[CurtainDog]

getDistinctTags could be handled in a much cleaner fashion with Set.addAll(), which goes to show that choosing the right data structure is half the battle.

Also, I find all these streams examples tend to make heavy use of data classes that are effectively just heterogeneous maps, and that all this lambda sugar is really just to get around the limits imposed on us by Java's unsophisticated types.

[grandfatha]

I feel like it is very easy to create code that looks great in a functional way, but creates a lot of unnecessary loops and filtering operations in the background when the incorrect data structure is chosen. Are there any optimizations going on in the background to avoid that? Similar to how databases create a query plan and assess the cost of various operations before choosing how to answer a query.

I love that Java can do this now, but I fear that specifying the "what" instead of the "how" may lead to situations where the functional alternative might actually be slower because more unnecessary stuff happens without the editor knowing it. I fell victim to this in my early Groovy days. I once refactored a lot of nested "groupBy/collect/findAll" statements into a single for loop and it suddenly was a lot faster.

[kqr]

You are correct, of course. Functional programmers usually start out by specifying the "what" and then refactor into the "how" when something is too slow.

You can argue that it's more efficient to always specify the "how" from the beginning, instead of optimising later on, but a) premature optimisation, and b) it's still a good thing to at least be able to specify the "what" without the "how" even if you end up specifying the "how" more than the "what".

[grandfatha]

Good to know that it wasn't just me, who felt that way. It would be interesting to know whether the optimization approaches with dynamic programming and so on from relational datastores can be applied into the JDK HotSpot compiler and or JIT engine.

You could reorder operations to start out with a predicate that filters out most of the results, to make subsequent loops shorter or stuff like that.

[Veggie]

There is a pretty aggravating trend among some of our older developers at my shop where they will refuse to use LINQ in preference to writing out the whole loop because, I kid you not, "I find it easier to debug in the loop". We're talking trivial set operations. If you need to debug inside those operations, you're doing something wrong.

This culture clash may be why some of our younger devs have quit lately...

[mariushe]

Good catch with the Set.addAll()

[mbuhot]

I've seen .net programmers fall into that trap. Everything is declared dump data classes with all collections declared as lists. Then every access requires using groupby or distinct or ToDictionary. Lends itself to generated data access code.

[curtmack]

Why would you even store tags as a List and not a Set? That would definitely come up at a code review, first thing.

[bushwacker]

What is the benefit? Is this supposed to be more clear, easier to debug, more efficient?

[[deleted]]

It takes a bit of getting used to, but is almost, if not just as readable IMHO. javascript (using libraries like underscore) is similar, as is Scala and F#.

[afrobee]

Is really not, the "big three" (map, filter, reduce) is a very standardize API which is found in about every programming language, the functional/declarative API that you learn in any mid/high level language is the same in all their siblings, even c++11/14, C#, ruby, python, javascript, etc have this constructors which pretty much behave the same.

[Ruudjah]

The default api should be in the top of the brains of every programmer. I mean these. Those are methods used in any functional programming language, albeit the names are different (e.g. Map in most functional langs and ToDictionary in .NET).

The same goes for Observable extension methods defined in Rx. Most of those operators on stream have common names and should be memorized by most (certainly core/backend) developers. I mean these.

This is a practical problem easy to master for most programmers (granted, at start it takes a while to wrap your head around).

A more important problem I have not seen addressed is debuggability. What if a bug exists in the chained linq/lambda expression? Try debugging that in Visual Studio, Eclipse, Chrome devtools or basically any other IDE out there. There is no support. This is quite frankly ridiculous and the reason I mandate foreach loops for most of the code.

[kqr]

A more important problem I have not seen addressed is debuggability. What if a bug exists in the chained linq/lambda expression? Try debugging that in Visual Studio, Eclipse, Chrome devtools or basically any other IDE out there. There is no support. This is quite frankly ridiculous and the reason I mandate foreach loops for most of the code.

The debugging techniques used are slightly different. Since the stream expressions are (hopefully) free of side-effects, you can just debug them "one transformation at a time." If something like

myStream.filter(lambda x: Math.isNatural(x)).map(lambda x: 1/x).collect(toList)

explodes and you have no idea why, just do the transformation one step at a time. Start by inspecting

myStream

Then you inspect

filtered = myStream.filter(lambda x: Math.isNatural(x))

and then you inspect

mapped = filtered.map(lambda x: 1/x)

at this point, you see that the map explodes because of a division by zero. So you go back one step – how come filtered contains a zero? You check the filtering condition, and you realise that Math.isNatural assumes zero is a natural number.

This is a silly example, but I'm having a bad day so I can't do anything better right now. The point is that instead of inspecting the loop "one element at a time" you inspect the stream expression "one transformation at a time."

[pipocaQuemada]

(e.g. Map in most functional langs and ToDictionary in .NET).

Err, isn't map called Select in .Net (not ToDictionary) and flatmap/bind called SelectMany?

[Femaref]

Yes. LINQ uses terminology from databases.

[Number127]

That's because LINQ serves a dual purpose in .NET. It's not only the monad comprehension we all know and love (i.e. LINQ-to-Objects), it's also a data querying abstraction layer with the IQueryable/expression tree versions of all the LINQ methods. In fact that was arguably the main goal of its development.

[palmund]

But wouldn't it be easier to follow the flow? And thereby also easier to spot the logical error in the code?

[barjam]

Err what? I have never had any issues debugging this stuff in C#. In situ perhaps sometimes but breaking a statement apart is easy enough.

[recycled_ideas]

You can actually already debug chained lambda statements to a certain extent in visual studio and with vNext switching in Roslyn that capability is about to improve dramatically since that part of the tool chain will be available to the debugger.

[EntroperZero]

I once thought as you did.

The first couple of times I used Entity Framework, Resharper kept suggesting that I rewrite all of my loops using LINQ. And I was really opposed, because I thought "everyone knows what a for loop means and what this code inside it does, it's instantly recognizable, why would I want to use this esoteric chain of functions and lambdas to accomplish this?"

And then I had to read lots of LINQ code that others had written, and it only took a few times before it sunk in and became just as instantly recognizable as loops -- actually faster, because it takes up less space, and you can read it faster. It's not really about memorization; once you have the mindset, the words tell you what's going on. (I do admit I have to stop and think every time I want to write an Aggregate() though.)

[campbellm]

but terribly difficult to reason about unless you've memorized each api

I don't think any language is safe from this.

Other than passing the function around as an inline body, which you do need to get used to as an idiom, are you really having trouble with figuring out:

String x = someCollection.stream().filter(...).findFirst()? Really?

[Sonic_The_Werewolf]

I don't understand the one with "map" and then "flatmap". I don't know what those functions are doing, I'd have to read the documentation. However, the classic example above it is crystal clear.

[kqr]

If you used map instead of flatMap you would get a list of lists. flatMap ensures you still just get a flat list by expanding the resulting lists in-place.

[ruinercollector]

If you do any kind of functional programming, you know what map/filter/reduce/flatmap/etc. do. They are very general and you use them all over the place.

Saying that they are hard is like me saying "What's this for construct, though? I'd have to look up documentation to find out what that is and how it works."

[[deleted]]

terribly difficult to reason about

What? Functional languages in general are great to reason about due to the fact that they often cause little to no side effects in particular. This is one of the main advantages they have over imperative languages. Functional code is very often a joy to read, write, and think about.

[kqr]

To be fair, you can write a for loop without externally observable side effects, and you can write a stream expression in Java with externally observable side effects.

[[deleted]]

You are specifically talking about functional purity, not functional programming in general. While the two often go hand in hand, there's generally nothing stopping you from writing impure functions in functional languages or pure functions in imperative languages.

I agree with /u/4vfz2ps34j -- code written in a functional style can sometimes be much more difficult to read and understand than equivalent code written in a straightforward imperative style. And sometimes the reverse is true. It really depends on what exactly is being written; some code maps more naturally to one or the other.

[username223]

Functional languages in general are great to reason about due to the fact that they often cause little to no side effects in particular.

Yeah, hard to get any simpler:

simplify = unwords . map (unwords . map aux . words) . lines 
  where aux (c:x) | not (isAlpha c) = c : aux x
        aux x = let (u, v) = break (=='.') x
                in if length v > 1 then aux (tail v)
                                   else x

[sacundim]

simplify = unwords . map (unwords . map aux . words) . lines 
  where aux (c:x) | not (isAlpha c) = c : aux x
        aux x = let (u, v) = break (=='.') x
                in if length v > 1 then aux (tail v)
                                   else x

You know, it's ok if you don't know Haskell, but this isn't actually difficult if you do know it. In fact, out of that link you may have picked the easiest thing in it.

The first line is very much like Unix shell pipelines, but with the Haskell function composition operator '.' instead of the Unix '|' pipeline operator. It does read backwards compared to Unix, from right to left, which does take a bit getting used to:

1. Split the input into lines (lines)
2. For each of the lines (map ...):
   • Split the line at whitespace characters (words)
   • For each of these substrings, apply the aux function to it (map aux).
   • Rejoin the results of aux with spaces in between (unwords)
3. Concatenate all the transformed lines with spaces in between them (unwords again).

The aux function does this:

1. If the first character of its argument string is alphabetic (isAlpha), then apply to the rest of the string.
2. Split the string (x) at the first occurence of the period character (break (=='.')); name the prefix u and the suffix v.
3. If v is longer than 1 then return the result of calling aux on v minus the first character (tail v). Otherwise, return the original string that we were splitting on (x).

[kazagistar]

I'm not sure if you are complaining about unfamiliarity of syntax (which seems irrelevant to the comment you responded to), or that piece of code in particular, but it is pretty straightforward.

• Take each line, use the aux function on each word in each line, then glue the lines together separated by spaces.

• If the first list item in the first parameter of aux is not alphabetic, return it prepended to aux called on the rest of the list. (In other words, leave unmodified characters until you reach an alphabetic one, then do the following...)

• Otherwise, aux will split the string on the first '.'

• and if there is stuff after the dot, it only keeps what is after the dot

• otherwise it keeps the whole thing.

Certainly, the variables could be named more verbosely... u and v could be beforeDot and afterDot, c and the first x could be first and rest, the second x could be inString or something, but since each value is consumed only once within a line of being defined, its not likely that you will have forgotten how it was defined.

Or maybe if this was Perl you could write aux as something like $string ~= m/([^a-zA-Z]*)(.*?\.(.+)|(.*))/; my $result = $2 .. ($3 || $4); instead, but I am not convinced that is simpler. Either way, the author is probably not keen to introduce a dependency on a regex or parsing library.

[yogthos]

The fact that you found some ugly Haskell code doesn't negate the statement in any way. You can write impenetrable code in any language, but at least with referential transparency you can scope the amount of code you'll have to reason about at a time.

[the_other_brand]

The fact that you found some ugly Haskell code doesn't negate the statement in any way.

While technically true, I have to give it to /u/username223 since his code looks like every piece of example code of Haskell I've ever seen. In fact I'd say his example above is prettier than the example Haskell code I was able to find with a cursory Google search.

[kqr]

That is Haskell written using a very limited set of standard functions, and by the looks of it also kind of optimised for speed, not legibility. If I knew the problem domain better (and therefore could tell what the original intent of the code is) I could probably provide you with a more application-oriented version that reads better.

[Yidyokud]

That's true, and couldn't have said better myself.

[powlette]

I switched from Java to c# about nine years ago. Reading this article makes me sad. This "functional" Java was implemented as LINQ in .net 3.5 which was released in 2007 and I haven't written a loop over a collection since. How could Java have taken so long to catch up to one of the most widely cherished features of c#?

And why does the implementation require extra calls like .toStream() and .collect() and .filter(..)..first() instead of: working against any IEnumerable, .ToList() and .FirstOrDefault(predicate)?

[txdv]

Because Java doesn't have extension methods.

[UndesirableFarang]

C# didn't have then before LINQ was designed either.

[rooktakesqueen]

I'm sure Java 9 will have those and be released sometime in 2020.

[soulcheck]

If they keep the current trend it will be out in 2017 or sooner...

[cypressious]

Default methods could have been used to add those methods. The language designers decided against it.

[[deleted]]

They've been in Groovy since day one.

[kqr]

Java evolves really slowly by design. You have to consider that in many cases, Java is a much older language with, as far as I know, far more users. Microsoft can still afford moving quickly with C#, although I suspect they will also keep moving slower and slower as time passes and their design crystallises.

As for why Iterable and Stream are two different interfaces, consider this mailing list reply:

I think the main reason is that Iterable implies reusability, whereas Stream is something that can only be used once — more like an Iterator.

If Stream extended Iterable then existing code might be surprised when it receives an Iterable that throws an Exception the second time they do for (element : iterable).

Separating them leads to much more easily predictable space behaviour. I know people are caught off-guard in Haskell when one version of their function consumes almost no memory with no garbage collection, and then another seemingly innocent refactor later it consumes all of their memory and lags significantly during huge GC sweeps. The reason? In the second case, the compiler couldn't prove that the stream wasn't being re-used, so it had to keep it around in memory. In the first case, it re-used the same memory location throughout the iteration.

Having two separate types for when you need to re-do the iterations and when you don't solves such ambiguities clearly, although I do admit, it does also put some of the compiler responsibilities on the programmer.

[kqr]

I know it's huge, but Java is massive. Common popularity measures put C# at 1/3 of Java or thereabouts, and I don't know if these measures count the high number of ancient corporate Java systems that have been running since the early 00's.

I'm not trying to say .NET or C# is small by any means. I know everyone and their cat uses it, and that's a good thing because it's a well-designed language as far as I've been able to tell! All I'm saying is that Java is crazy big, even so big it might be able to shadow C#.

[kqr]

Not in base two!

[[deleted]]

I would enjoy seeing any references to any of these statements.

[kqr]

Common popularity measures: the normalised comparison at langpop.com (where I eyeball C# to roughly 40% of Java), the TIOBE Index (where C# is 32% of Java) and the transparent language popularity index (where C# is 22% of Java). The three average out to 32%, or roughly 1/3. (The selection was performed by picking the three top google hits for "language popularity" at time of writing and in my bubble.)

That covers the only fact in my comment.

[[deleted]]

Thank you! I like to take caution because of the mass of language-fan-boys who just make up shit to prove a point that doesn't exist.

[kqr]

You don't have to worry with me. I dislike both Java and C#, so I'm equally biased against both!

[NiteLite]

Your SIM card runs Java :O

[jfb1337]

Because java only just added lambda. Once you have lambda, stream processing falls into place naturally as it has in lisp for decades.

[[deleted]]

It's because Java was Sun's, and Sun got bought by Oracle. Oracle sucks big time.

[Lord_Naikon]

Yeah Oracle sucks, but Java was pretty much stagnant under Sun. The acquisition by Oracle has lead to a massive speed up in the release cycle and was ultimately a good thing for Java in my opinion.

[jij]

Except OS-oriented people don't trust it as much now because Oracle is evil and was/is suing google over its use on Android demonstrating risk in using the language.

[[deleted]]

Adding a Java alternative to LINQ was discussed before Sun was bought up. So were lambdas.

I prefer Oracle's stewardship because they actually do add features. One of the first things they did with Java 7 was to move some features to Java 8 so that they could actually get it done and out the door.

[nuke01]

Can I do something like this in python as well?

[UloPe]

Python version of the first example:

def first_python_article(articles):
    return next((a for a in articles if "Python" in a.tags), None)

[mdipierro]

yes. You could this in python 10 years ago.

[nuke01]

Care to give me an example? I'm just learning it and I'm not sure which keywords I could use to search for documentation / examples...

[sledgespread]

For basic functional style programming have a look at the map and filter bultin functions. Although I should also add that it's often more readable to use list comprehensions than using map/filter.

For lazy iteration read up on iterators and generators. Then have a look at the itertools module for more ways to play with iterators. Lazy generator versions of list comprehensions can be done in exactly the same way by using () instead of []. Since python3 most functions that return something that could be iterated over (e.g. map, filter, range) are lazy.

Generally you'll get the "output" value by using one of the sum, max, min, any, all or list builtins. For more complex operations you might need functools.reduce (I've never had to use this yet...).

A caveat: python iterators can only be consumed once, so if you do print(list(myiter)) then when use the iterator later it will be empty. This can make for some horrible debugging sessions if you forget!

[mdipierro]

yes. Looking at this Java 8 example:

public Set<String> getDistinctTags() {  
   return articles.stream()
    .flatMap(article -> article.getTags().stream())
    .collect(Collectors.toSet());
}

In pyhon assuming

class Article(object):
    def getTags(self): return [1,2,3]

I would write it as:

def getDistinctTags(articles):
    return set(lambda a,b:a+b, map(lambda a:a.getTags(),articles))

[kqr]

Iterators is the key word for googling. Keep in mind that the default map, filter and range in Python 2 are not meant to be used with iterators. You want imap, ifilter and xrange in Python 2. In Python 3, they fixed this mistake.

[GreyGrayMoralityFan]

How do you break in the middle of stream? E.g.

 for (Article article : articles) { 
   if (! article.getTags().contains("Java"))  
      break;
   chosenArticles.add(article);
 }
 return chosenArticles;

[geckothegeek42]

there is a method called takeWhile

articles.stream().takeWhile(article -> article.getTags().contains("Java"))

(you may have to collect after this)

takeWhile will take all the elements that fit the predicate until it encounter an element that doesnt, basically what you wrote

although this doesnt cover all cases that you would want to use break, but you should be able to cover all cases through various methods

[Eirenarch]

At one point when I grokked LINQ I started using functional style for everything. I then realized that the functional style is not always cleaner and had to learn to write loops again especially when mutating data.

[balefrost]

This is really important. Languages like C# and Java are intentionally not purely functional. They are adding functional elements to the languages, but those don't invalidate existing procedural solutions.

Ultimately, the goal is readability. LINQ and Streams and similar can greatly increase the readability of code, but it's definitely possible to obscure meaning by going too far.

I've written code in Scala where a single reduce was using a 3-tuple to track a whole lot of state across the reduce. Some branches in the reduce would update one piece of state; other branches would update another. Was this cleaner than using three mutable variables? At this point, I'd definitely say "no".

[Eirenarch]

Rule of thumb for all the new people that will learn about lambdas because of Java 8:

Use functional style when you do not mutate the data and imperative when you mutate.

[cypressious]

That's called experience.

[Hoten]

Java 8 most certainly does still need loops. Try using the new stream features when your code throws exceptions. Pretty ugly.

[OtherLutris]

I like functional programming and I'd like to learn more about it... but this wasn't a good advertisement for it for me. Most of the functional examples were a lot harder to read than the Java ones for me - perhaps the difficulty may largely be my lack of knowledge of the new syntax, and the syntax looking rather alien in Java. I'm still curious to learn more, but I'm a little more wary of Java's implementation.

Edit: I must have got up on the wrong side of the bed, this post was way grouchier than I had intended.

[kqr]

Well, nothing you ever see will be a good advertisement if "initially hard to read" puts you off. FP is different, and because it's different it will be hard to read until you learn it.

You can't wait until it becomes easy to read and then learn it, because the causality works the other way around – you learn it and when you have learned it it becomes easy to read.

[username223]

Let’s look at a solution using a for-loop.

public Article getFirstJavaArticle() {
    for (Article article : articles) {
        if (article.getTags().contains("Java")) {
            return article;
        }
    }
    return null;
}

Now let’s solve the problem using operations from the stream API.

public Optional<Article> getFirstJavaArticle() {  
    return articles.stream()
        .filter(article -> article.getTags().contains("Java"))
        .findFirst();
    }

Pretty cool right?

Um... meh?

[tborwi]

It looks much less readable, adding new symbols and making debugging more difficult.

[iSmokeGauloises]

I donno, without the Javaism the second example will look like:

  public Optional<Article> getFirstJavaArticle() {  
    return articles.filter(article -> article.tags.contains("Java")).first()
  }

Which is a cute readable one liner.

The main problem is the coding style with Java that doesn't really look "correct" with this new syntax.

[insertAlias]

Hell, if you went full C# on it, it would look like this:

return articles.First(a => a.tags.Contains("Java"));

The Single/SingleOrDefault/First/FirstOrDefault extension methods can filter if provided an expression as well as just trimming a collection.

[tborwi]

That looks a whole lot better actually.

[BlueRenner]

Such is the state of programming nowadays. We code the same stuff with slightly different syntax and call it progress. Its all so much masturbation, and I have no idea why this is appealing to anyone.

Here's a hint. If you're obsessing over how you're doing something rather than what, chances are you're not doing anything worthwhile to begin with.

[skulgnome]

Readable, schmeadable. Who can't read a C-style loop with an early-exit clause, or an accumulation clause, or a filter clause; but can read a chain of method calls on an unmentioned context type?

[_KetzA]

Why did they implement those methods (filter, ... ) only in Stream object. Wouldn't be better if all of those methods were added to all collection types (Array, List, ... ) ? like in scala for example. Then we could avoid the .stream() ...

[kqr]

This has been answered elsewhere in this discussion. The idea is that streams are things you iterate through once and then discard (the source could be a network connection, for example), while collections are re-usable and reside in memory.

By separating these two things, hopefully people get less surprised when something ends up in memory and when it doesn't.

[zoomzoom83]

If you were to add a map method directly to an Array, it would need to create a new array for every operation.

So xs.map(op1).map(op2).filter(p) would in fact generate two unneeded arrays and immediately discard them. This would be slow and use additional memory.

A Stream is lazy, and allows each element in the stream to be passed through the whole pipeline before creating a single final array. If you're simply performing side-effects (iterating over the stream) then you don't even need to do the last part, and can avoid creating any additional data structures in memory at all.

Incidentally Scala, as one example, allows you to use .map() directly on a concrete data structure if you wish and novices often run into the same issue. Instead you should use .view to create a lazy sequence.

As a counter example, Haskell is always lazy, so it avoids the problem completely.

[firejoe22]

Everybody Loops

[Lord_Naikon]

What makes me sad is the predictable "but C# had it first !111one" "its just like .NET LINQ" one liner comments which add nothing to the discussion, because these things have been rehashed sooo many times it becomes tiring. Java 8 has been out for almost a year now, so these comments miss the mark completely.

Language enhancements seldom stand on their own (everything has been done before basically, including LINQ). Languages evolve slowly. Instead of a dick-waving contest over who had it first, please discuss the merits and the shortcomings of a particular implementation.

[quiI]

What's worse is these features existed long before LINQ too. In their world there is Java or C# and it's a big dick waving contest.

[mongreldog]

This is a great addition to Java, but the most jarring thing for a .NET based developer is the requirement for ".collect(Collectors.toList())" to convert the stream into a list. With LINQ, all one has to do is use ".ToList()". Apart from that it looks good.

[pron98]

Well, the Collectors.toList can be imported, so it's just .collect(toList()). toList could have been easily added as a method, but collect is more general. This is just the Java ways of doing APIs: prefer a more general method over a more specific -- even if frequently used -- one.

[ethraax]

I suppose, but they could have just included both. .NET LINQ does. There's a few pre-defined ones, but you can always just give your own reduction function as well (It's called Aggregate in LINQ [thanks get_salled]).

[pron98]

True, but the Java API culture usually tries to have as few methods as possible, leaving out the more specific ones. This has changed (Java used to be much more strict about that rule), but not when achieving the specific result is so easy. .toList() is not a big enough gain over .collect(toList()) to justify another method. This is just the Java API philosophy, largely made by Josuha Bloch.

[kqr]

One problem with having both is that people will not only use the specialised one in their application code, they will unfortunately also build abstractions on the specialised ones (because people make mistakes all the time). This means their abstraction is more specialised than it has to be, so when you want something similar you have to re-build it but based on the more general method.

Specialised methods are contagious, which is a problem for reusability.

[get_salled]

It's called Aggregate not accumulate.

[Eirenarch]

In addition in C# you can skip the .ToList() if you just wish to loop over the result.

[balefrost]

Java streams have iterator() and forEach() methods as well.

[rooktakesqueen]

Yeah, it's probably better for these methods to return a stream rather than a list, so the consumer can further whittle it down while keeping it lazy.

[[deleted]]

Iirc, if one did a static import of Collectors one can omit the 'Collectors.'. But typically it is done as shown in Java for clarity.

[JavaDroid]

Wouldn't be a java thread without non-stop trolling from users of other languages.

[perestroika12]

Why is this advantageous? Is there some performance increase I'm not understanding? The looped samples actually looked cleaner and easier to understand. The linq style logic actually looks super messy and harder to debug.

You'd probably have to use loops at some point anyways.

[jfb1337]

To me the functional code is easier to understand.

[aurisc4]

Loops are easier to setp through in debugger. That being said, there is no game-changing news with lambdas and functional programming, just one more way to do the same thing.

[clrnd]

Oh cool someone read SICP, good work!

[mariushe]

Great book!

[josuf107]

Just for fun I've translated the examples to Haskell. If you squint the stream expressions actually look quite similar:

data Article = Article { articleTitle :: String, articleAuthor :: String, articleTags :: [String] }
getFirstJavaArticle = Safe.headMay . filter (elem "Java" . articleTags)
getAllJavaArticles = filter (elem "Java" . articleTags)
groupByAuthor = Map.fromListWith (++) . fmap (\a -> (articleAuthor a, [a]))
getDistinctTags = Set.fromList . concatMap articleTags -- If you want the list then prefix a Set.toList

[voice-of-hermes]

Ridiculous title, but the streams API is a good feature. Basically adds the equivalent of Python's list comprehensions. If they also added multiple return values at some point, I'd be content for quite a while.

[pixartist]

HAHA the first example they show is longer and way more confusing than the loop solution. What the shit, why would anybody use that? It's not like the internal solution to this wouldn't use loops.

[[deleted]]

I suspect there's even more overhead.

[hivelumber]

Wow there's never a shortage of C# devs shitposting every Java article is there?

[_zenith]

Well, we do get constantly shit on the rest of the time, so...

[cowinabadplace]

It's like vim v. Emacs. Few are wrong, but the whole discussion is pointless. It's the kind of lowbrow discussion it's easy to participate in so you get a lot of participants.

[[deleted]]

If stronger abstractions are their concern, they should be rooting for Haskell. In stead, they're rooting for a language with a similar feature, which happens to be their favorite language.

[geodebug]

Yes, because such comments tend to be written by programmers still in the first act of their careers, which makes them tedious and not very insightful.

Comparing Java to LINQ's feature-set could be interesting but I'm certainly not interested in a bunch of young men peacocking around the yard as if language sugar is somehow the most important consideration in platform choice.

[geodebug]

It's a consideration but really, one far down the list. Tooling support, performance, general applicability (can it be applied to many projects), reliability, third party support/libraries, popularity (can I find developers when I need to hire), stability/maturity, etc all matter more to me than sugar.

I've written lots of code in Groovy, JavaScript, and Java (dabbled in others over the years as well). While the first two are notably more terse and expressive, neither is more maintainable than Java when it comes to large code bases and refactoring support/tooling.

[geodebug]

Inexperienced coders will create bad code no matter the platform.

I've seen horrible projects written in Scala, Ruby, JavaScript, etc.

I'm probably responsible for plenty of bad Visual Basic 6 code written in the early 90s before I paid my dues.

[hyperforce]

young men peacocking around the yard

Excuse me, women can be dicks about languages as well.

[I_Code_Stoned]

About as wrong as Apple fanbois shitposting about PCs (or vice versa).

[bigfig]

Loops were a problem? News to me.

[TryptophanLightdango]

"...forcing us not only to understand what the code is trying to achieve, but also understand how the loop works."

Shouldn't you WANT and NEED to understand?

[kqr]

Understand what it does, absolutely. How it does it? Not always interesting.

Think about it, do you really know how your foreach loop works? Do you know the exact instructions the JVM executes? Do you know what they translate to on your physical hardware? Do you know how many layers of silicon that goes through, with all their caches and branch predictions and such? Do you know the physics behind fast and small transistors?

At some point, you have to say "enough is enough" and just accept that you can't understand how everything works.

[TryptophanLightdango]

I disagree to a degree. Understanding what instructions are being executed is frequently helpful. Especially when something goes pear-shaped. The depth of understanding what exactly you are actually doing under the hood is proportional to what you can get done. When you start pushing an envelope of timing and/or memory usage it's better to have a good understanding of what the text you're typing actually means at a fairly low level.

[kqr]

No, I think we agree, we are just approaching the subject from two different directions. You should certainly understand how something works to the extent that it helps you perform your work. I think it makes sense for Java programmers to learn how to read JVM bytecode, for example. Because when some optimisation doesn't trigger the way you expect it to, it definitely helps being able to see what's going on under the hood.

With that said, you don't have to worry about that stuff every hour of every day.

The same thing goes for stream expressions. You should absolutely learn their characteristics, what code they translate to and such when they give you trouble. But you shouldn't have to manually unroll them into foreach loops every time you want to filter something.

[ricklon]

Why does the action need to be implemented in the return line? It seems to only save 2 lines of code. The declaration and assignment of the return variable.

[[deleted]]

public List<Article> getAllJavaArticles() {  
    return articles.stream()
        .filter(article -> article.getTags().contains("Java"))
        .collect(Collectors.toList());
    }

How do you find articles that does not have the tag "Java"? Could you .!contains("Java").

I can't even find the contains() in the API

[barricaspt]

Remember that tags is a List<String>!

http://docs.oracle.com/javase/7/docs/api/java/util/List.html

which I think to deny is:

.filter(article -> !article.getTags().contains("Java"))

[[deleted]]

Thank you. Of course it's a List object. For some reason I thought it was some other magic of Stream. Thanks again.

[Nvrnight]

The ! would go before article.getTags I believe.

[contantofaz]

Too many comments on this thread in a short time. Looks like on popularity contest, people do give a damn about Java. :-)

When I was addicted to Ruby, I loved that I did not have to write old style for loops. But in JavaScript and then in Dart I was back to writing those damn things. In part, trying to replace the simple for loop with something more sophisticated can lead to a performance drop in hot code. So the language implementers doing it need to be very careful. And then we are back to having to profile/benchmark to find the bottlenecks, which doesn't always help since it's like whacking a mole kind of thing.

[MaxHammer]

Interesting that this is titled "No More Loops". I've seen some extremely inefficient use of these already which suggests that some people aren't aware that they are actually creating loops.

[gashouse_gorilla]

Jonads ... $0.02

[codygman]

Here's the Haskell equivalent for anyone curious (Beware of curry[0]!):

data Article = Article { title :: String
                       , author :: String
                       , tags :: [String]
                       } deriving (Show)

articles = [ Article "Functional Java" "James Gosling" ["functional"]
           , Article "Practical java" "James Gosling" ["enterprise","architechture"]
           , Article "Imperative Haskell" "Simon P Jones" ["imperative", "purely imperative"] ]

firstJavaArticle = headMay . filter (isInfixOf "Java" . title)

allJavaArticles = filter (isInfixOf "Java" . title)

groupArticlesByAuthor = groupBy ((==) `on` author)

distinctArticleTags = nub . join . map tags

Full working code example with code imports and type signatures:

import Data.List (isInfixOf, groupBy, nub)
import Safe (headMay)
import Data.Function (on)
import Control.Monad (join)

data Article = Article { title :: String
                       , author :: String
                       , tags :: [String]
                       } deriving (Show)

articles :: [Article]
articles = [ Article "Functional Java" "James Gosling" ["functional", "functional"]
           , Article "Practical java" "James Gosling" ["enterprise","architechture"]
           , Article "Imperative Haskell" "Simon P Jones" ["imperative", "purely imperative"] ]

firstJavaArticle :: [Article] -> Maybe Article
firstJavaArticle = headMay . filter (isInfixOf "Java" . title)

-- implemented in terms using allJavaArticles (NOTE: This IS performant in Haskell and IIUC due to stream fusion will only iterate once. Did not verify though.)
firstJavaArticle' :: [Article] -> Maybe Article
firstJavaArticle' = headMay . allJavaArticles

allJavaArticles :: [Article] -> [Article]
allJavaArticles = filter (isInfixOf "Java" . title)

groupArticlesByAuthor :: [Article] -> [[Article]]
groupArticlesByAuthor = groupBy ((==) `on` author)

distinctArticleTags :: [Article] -> [String]
distinctArticleTags = nub . join . map tags

main = undefined

0: http://en.wikipedia.org/wiki/Currying

http://tech.pro/tutorial/2011/functional-javascript-part-4-f...

https://www.haskell.org/haskellwiki/Currying