Java 8 and lambdas: ooooh that's how it works, then | Hacker News Reader

Java 8 and lambdas: ooooh that's how it works, then

juliensimon.blogspot.com

19 pointsjulsimon15 comments

I honestly expected some insight into internals of Java 8 lambdas or, for example, how `retrolambda` works. Unfortunately this is only introduction to lambdas in general (and I'm pretty surprised many haven't even heard of lambdas before)

There's a lot that could be said about this code, but the worst is that it has an incorrectly implemented swap when one exists in the standard collections library. I don't understand why you would show off a feature (which admittedly has an some poor interactions with other aspects of the language) while simultaneously neglecting the standard library and all the language improvements that happened between 1 and 8.

Java doesn't need anymore disservices.

Thanks for your comments, guys. Yes, I did push the verbosity setting to the max to underline my point. Unfortunately, there is lot of naive, bloated Java code out there (often much worse than this!) and some of us have to fix it for a living. I'll try to add an abstract singleton proxy bean factory next time :D

What is your point though?

This same article and same code example could have been written in 1975 -- "I just figured out how to use function pointers in C..."

Even "object orientation" had already been invented back then, but I assume no one could have imagined that it would be perverted into a chronic bulimia of superfluous types as demonstrated by the "LinearSearchModeFactory" example here.

I've never seen patterns like linesrsearchmodefactory in real code and do lots of OO programming. Where does this stuff come from, enterprise java beans?

I think the example here comes from "exaggeration for effect". On the other hand, you certainly have a number of factories in Java-land, mostly because that's what you do when you don't have currying and you want to fix the value of some parameters in a constructor.

That said, I suspect the author is not that familiar with Java, considering that using an enum would not take more space and would be way more idiomatic than hand-rolled integers. Also, the Java folks found out about type inference, which should be pointed out in any article about Java lambdas.

We have lambdas in C# land, and I don't find myself using factories or lambdas in my code. I occasionally take advantage of reified generics and reflections, but that is a different thing.

> We have lambdas in C# land, and I don't find myself using factories or lambdas in my code.

I do some C# too, and I use lambdas regularly with .Select() (but not so much otherwise - though I can imagine it's an effect of the codebase). But you do need factories/providers if you want IoC and you use variables in different scopes...

I'm sorry, I meant, I don't find myself using lambdas to curry constructor arguments. I didn't mean I don't use lambdas at all (of course, I use them a lot within reason, sometimes I have to go back and de-lambdify my code for debugging or perf reasons).

How is this really an improvement over 1 class, with a single method that takes an Enum 'mode', which then switches to one of three internal methods ?

Lambdas may have some benefits, but this article really doesn't demonstrate any.

Why does the "canonical" Java solution involve a factory, anyway?

Be thankful it doesn't involve an abstract singleton proxy bean factory!

(I shouldn't really snark - I don't have much occasion to write any Java these days but I do quite miss it sometimes... and the things that Java has gained since I last used it in anger, like lambdas, make it really quite appealing to me once again.)

Don't use list.get() in a loop; that's quadratic for a linked list implementation.

Too much boilerplate list manipulation here, to be honest.

Reply on news.ycombinator.com