Hacker News Reader

Comment by jebblue | Hacker News Reader

>> Stream.of(1, 2, 3, 4, 5, 6, 7) .map(x -> x * x).filter(x -> x % 2 == 0) .reduce(0, (sum, x) -> sum + x);

If I catch anyone writing Java code that I will have to work on writing Lambda expression crap like the above I will hit the ceiling. How can you debug junk like that?

View on HN

This exact response right here is why a perfectly good language like java is ranked just under php in the hated languages list.

The language is fine but the insistence by the vast majority of the developers using it to do things in a way that can only be described as "Enterprisey" gives it a bad name. And it really is a shame.

I find that perfectly readable. I would be more likely to catch an error in that line than in the equivalent in imperative style. It's a matter of habit. It all depends on what you are used to write, whether you are used to functional style or not.

I write code like that with LINQ and such in .NET all the time and have no problem debugging it.

Is there actually a way to properly debug LINQ expressions? I haven't figured out how to get Visual Studio to step through lambdas or break halfway through the chain (eg break after the filter call has completed and before reduce runs in the above example).

But I'm not sure if I'm missing some blindingly obvious.

I don't know, but it just hasn't been a problem. If something's that wrong with the expression chain I can just break it up temporarily.

Thing is though, now you've changed the recipe from what you intend to run in PROD. You linearized it to gain a debugging advantage that you lose when you re-lambdaize it.

this probably isn't the place to start a chain on how to do this, but if you wrap the statement in the lambda in a {} block and explicitly return the expected value, you can insert line breaks and set breakpoints.

i'm not familiar enough with the vocabulary to explain it perfectly, but i do it all the time.

example: list.Find(o=> { if (o.prop == "foo") { return true;} // visual studio will allow a breakpoint here else { return false;} });

How can you not debug "junk" like that?

I can see my view is already unpopular but you asked a fair question. It's several key pieces of logic jammed together on one line. That's not the part that bugs me though, it's wondering how this is going to play out. I can imagine multiple threads servicing the Lambda stuff and it reminds me of trying to debug Camel code hopping around debug screens trying to stay up with all the async stuff going on just to find a simple bug. Maybe ... maybe I'm wrong ... I could be, I don't think I am but it's going to have to be more deterministic than what I'm afraid it will turn out to be.

I guess I can understand if java doesn't allow for debugging code similar to this. Being fond of lisp/scheme languages such as racket though, I find this very clear and is of course easy to debug in those languages.

That code is exactly equivalent to:

int sum = 0; for (Integer x: Arrays.asList(1, 2, 3, 4, 5, 6, 7)) { int x2 = x * x; if (x2 % 2 == 0) sum += x2; }

No threads, no weirdness. It's just a different syntax for a loop, really.

Reply on news.ycombinator.com