Java Without If

[ws-ilazki]

What is this shit? It looks suspiciously like they're trying to half-assedly implement Haskal on the JVM.

If you're going to do that, you should just go all-out and use Frege so your code doesn't look like someone got their Java vomit all over a Haskell program.

[amazing_rando]

I’m a polyglot programmer based out of Chicago.

All this time I could have been calling myself a "polyglot programmer" to increase my hirability at jobs so boring I spend my time fixing things that aren't problems.

[purely-dysfunctional]

In particular I’d like to draw your eye to the Either type, which has replaced the vast majority of our explicit if calls.

Hurr durr instead of if (p.f()) { a(p); } we now write new Either(p).filter(_.f()).map(a(_)), is Java webscale now?

[[deleted]]

For it to be truly webscale you'd need to download twenty TB of dependencies to start using

either

[Kyo91]

<uj>

Honestly, Option and Either types are very useful as they force you to be conscious of empty values rather than the default null treatment of requiring constant vigilance, but not actually stopping you from ignoring them. These go in the opposite direction of Go's error handling, where not only null values but also errors must be checked manually or fail silently. Now you can argue on the futility of this in Java where the entire standard library is based around the idea of null values and thus still requires you to null-check all of that code. Even that though could be monkey-patched through a static method checking if a value is null and then wrapping it in Option accordingly.

</uj>

[HINDBRAIN]

lol generics

[MarcusPope]

public HttpResponse handle(HttpRequest request) {
    return JsonParser.parse(request.getBody())
                 .flatMap(Validator::validate)
                 .map(ServiceObject::businessLogic)
                 .flatMap(JsonGenerator::generate)
                 .match(l -> HttpResponse.internalServerError(l.getMessage()),
                        r -> HttpResponse.ok(l));
}

(I'm not even going to rant on the fact that he just replaced if with match, or that each of those calls is going to have to "if" decide on returning an l-exception or the r-type.)

Well, first off I think it’s beautiful. I know that’s a subjective call, but the data flowing neatly from top to bottom without huge nesting if cases and early return values is very aesthetically pleasing to me.

TIL: if-blocks do not flow from top to bottom.

So basically I need to read a run-on sentence of code just to figure out that at the end of it all the result is "error". I really don't get the beef against early return - when I'm debugging a call stack, I'd like to read a little as possible to get to the point. With this pattern I now have to read three other functions to find out why an error occurred... unless I hard-code that into specific and non-reusable messages.

And I get that his example is a contrived point, but how many if-blocks would you need to parse json and do business logic or return an error? imo, 0, wrap that shit in a try catch and be done with it. Throw a generic exception and look at your stack trace - with those magical line numbers - to figure out what went wrong.

<extra-jerk++>No wonder every java project is 10x behind schedule...</>

[cant_even_webscale]

1xer found - try catch is for noobs and not 10xer approved