Live data from Hacker News

Java 8: No more loops

deadcoderising.com

11–20 of 99 posts

Re: Java 8: No more loops

#11

The first example is actually a poor way to do it, IMO. Even if behind the scenes, these are implemented lazily (like C# LINQ), it may not be obvious what's going on to someone else who isn't familiar with the API. I'd opt for the for() loop each time when it's something like halting when you find what you're looking for.

The for loop is actually a poor way to do it, IMO. Even if behind the scenes, these are implemented via conditional gotos (like C), it may not be obvious what s going on to someone else who isn't familiar with the syntax. I'd opt for the if-goto loop each time when it's something like halting when you find what you're looking for.

To wit: You can expect others to be familiar with basic features of the language and ecosystem, or prepared to learn them.

Re: Java 8: No more loops

#12
post #8
post #7

Earlier quoted context omitted.

I guess this is why Microsoft diverged from the "standard" names like 'map', 'collect' and 'filter' in favour of more human-oriented SQL-like LINQ: 'select', 'where', 'toList'. I have to read the underscore.js documentation every time I am using it :(.

MS did the right thing. A huge barrier to FP adoption is the unnecessarily obtuse terminology. In playing around with FP languages I often find myself having to re-look-up basic syntax because the terms are simply so obtuse that they won't "stick" in my head. I think it comes from FP's rooting in mathematics, and math is itself unnecessarily arcane.

I disagree. The benefit of having the standard terms is they are the same in every FP library you use. If you spend the time to learn and internalize them within one, it'll be the same in every language or library that implements them. I don't understand how map, filter, collect, reduce are obtuse or arcane.

Re: Java 8: No more loops

#13
post #12
post #8

Earlier quoted context omitted.

MS did the right thing. A huge barrier to FP adoption is the unnecessarily obtuse terminology. In playing around with FP languages I often find myself having to re-look-up basic syntax because the terms are simply so obtuse that they won't "stick" in my head. I think it comes from FP's rooting in mathematics, and math is itself unnecessarily arcane.

I disagree. The benefit of having the standard terms is they are the same in every FP library you use. If you spend the time to learn and internalize them within one, it'll be the same in every language or library that implements them. I don't understand how map, filter, collect, reduce are obtuse or arcane.

Those aren't the worst offenders. I'm referring to curry, cadr, lambda, monad, etc.

But map is confusing: it's also a data structure. "Wait, does map() create a new key-value dictionary?" Filter and collect are okay. Reduce is pretty arcane but tolerable, but the actual operation feels intuitively closer to "categorize" or "group."

My point about math was cultural. Math seems to revel in having its own peculiar and often even domain specific (even within mathematics!) terms and symbols for things.

Re: Java 8: No more loops

#14
post #2

All I could think: it's still sunk in too much architecture....

Too much architecture for what? For bankings? For medical devices? For the safety-critical avionics software? For high-frequency trading? For manufacturing control? For weapon-systems? For power-plant command and control? For government ERP running on mainframes? Because Java is used for all of these things.

Yes, some bits might be too architected for your MVP web app that you're going to re-write in a year (and even that depends mostly on the libraries you're using; there are plenty of lean libraries for the web-startup crowd).

Re: Java 8: No more loops

#16

I really want to like functional programming, but the functional version of each of these seems less readable and more verbose.

I think the examples shown here don't really show how it can help- the real win for me is if you already have a function to filter over (like "article.isJava()" or something) it becomes much clearer. It also is eye opening to see or higher order functions like pluck or flatmap that build off these blocks.

Edit- there is a good flatmap example there that I glossed over when first reading. It looks like Java even has serviceable syntax for passing around lambadas like that now too, that is cool.

Re: Java 8: No more loops

#18
post #10

I really want to like functional programming, but the functional version of each of these seems less readable and more verbose.

This was exactly what I was thinking when I read the code. The goal should not be to remove loops. As a language construct there is nothing wrong with loops itself. The goal should be to make more readable and maintainable code, preferably without increasing verbosity. The functional alternatives posted here are not actually code quality improvements and should not be presented as such.

I welcome the functional features, but I have to agree that these specific examples are ugly compared to the more familiar alternatives.

Maybe this will look more readable after getting used to it, but I'd much rather be looking at Clojure or Scala for now.

Re: Java 8: No more loops

#19

I really want to like functional programming, but the functional version of each of these seems less readable and more verbose.

I disagree. Perhaps I'm simply more use to seeing this style, but I feel it's more concise, more maintainable, and more easily built on than the loop-based version. Additionally, I find it to be more semantically clear as to what the expected behavior is, as opposed to reasoning about the loop, especially when filters become complex.

Re: Java 8: No more loops

#20
post #6

[deleted]

No its the price you pay, when you improperly implement generics and do not have polymorphic functions. In other words its the price you pay, if you ignore the developments in computer science in the last 10 years and invent a crippled terrible language in 1995 (roughly the same time OCaml came out) and push it onto the world with success, because you are a big corporation. At the point they introduced generics, there really was no way you should have gotten it wrong, but they did... Incidentally I think it's a failure of the Free Software movement, that they did not do much to actually move towards a modern statically typed language (or family of languages) that was not burdened by corporate policy.

In Haskell the type of map is

map :: Functor f => f a -> (a -> b) -> f b

(actually for historical reasons its called fmap, but nevermind). Here f a in Java could be something like Stream, that is something that contains things of type a.

Post reply on HN