Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern Java – A Guide to Java 8

github.com

Post reply on HN
Print view View original

171–180 of 203 posts

Re: Modern Java – A Guide to Java 8

#171

Post by RandomBK »

guard-of-terra wrote: post #169
mabbo wrote: post #92

My Java code has improve dramatically since I started (ab)using Optionals. String foo = Optional.ofNullable(paramater) .filter(...) .map(a -> ...) .map(b -> ...) .orElseGet(() -> ...) .orElse(defaultValue) Between this kind of thing, and similar playing with Streams, some of the ugliest code I work with is suddenly quite clear, coherent, understandable.

Two .map-s one after another is code smell (and also a bit slow). Why not combine them into one? Do standard collections have groupBy? You can go a long way with groupBy and zipWith operations, which are a pair like map-reduce but for in-memory handling.

It might be simplified this this example, but if the mapping function is a method reference or some other reusable lambda, then it can be clearer to use consecutive .map-s

Re: Modern Java – A Guide to Java 8

#172

Post by stickfigure »

meddlepal wrote: post #73
lmm wrote: post #65

Earlier quoted context omitted.

Java's way of expressing variance is really awkward (even quite popular libraries get their types wrong as a result), arrays are special-cased into unsoundness, Serializable is a total mess where it could be a perfect example of how to use a type system, there are no higher kinds, the exception system is like a second parallel type system (it even has union types, which would be incredibly useful if you could use the…

Besides null being a potential type for any reference and causing a ton of issues I do not think most Java programmers regularly care about the lack of abstractions like higher-kinded or union types. Would be nice to have, but never have I felt like I needed them. Enum types didn't exist in Java when the Comparable interface was implemented. That's why some API's look old-school by comparison because newer language f…

For an eye-opening experience, walk through the tour of Ceylon sometime. It has the most sophisticated implementation union & intersection types I've yet seen:

http://ceylon-lang.org/documentation/1.1/tour/types/

Compared to union/intersection types, I find myself craving higher kinded types less frequently. I do feel the absence strongly, however, when I'm writing tools. I think the lack of higher kinded types manifests in the Java community as inferior libraries (eg ORMs) that require more manual-feeding of information via annotations or extra parameters to methods.

Re: Modern Java – A Guide to Java 8

#173

Post by wtetzner »

guard-of-terra wrote: post #169
mabbo wrote: post #92

My Java code has improve dramatically since I started (ab)using Optionals. String foo = Optional.ofNullable(paramater) .filter(...) .map(a -> ...) .map(b -> ...) .orElseGet(() -> ...) .orElse(defaultValue) Between this kind of thing, and similar playing with Streams, some of the ugliest code I work with is suddenly quite clear, coherent, understandable.

Two .map-s one after another is code smell (and also a bit slow). Why not combine them into one? Do standard collections have groupBy? You can go a long way with groupBy and zipWith operations, which are a pair like map-reduce but for in-memory handling.

>Two .map-s one after another is code smell (and also a bit slow). Why not combine them into one?

I believe they are automatically combined before the results of the stream are forced.

Re: Modern Java – A Guide to Java 8

#174

Post by stickfigure »

mark_l_watson wrote: post #80

This is a really nice write up! Java 8 is such a huge improvement over previous versions. One thing it still lacks is a better literal format for defining maps, etc. I just self published a book that uses Java 8 ( https://leanpub.com/powerjava if you will pardon a plug) and to be honest I got some pushback from a few people who like my books as to why I didn't use Clojure, Haskell, etc. To be honest I do prefer Cloju…

Guava has some tools that make map literals a little prettier:

  Map map = ImmutableMap.of(foo1, bar1, foo2, bar2, foo3, bar3, foo4, bar4);
There are overloads for up to 5 entries, and they're even key/value typesafe.

Re: Modern Java – A Guide to Java 8

#175

Post by stickfigure »

Too wrote: post #154
lomnakkus wrote: post #63

Earlier quoted context omitted.

> I don't know how you can find even average Java code unreadable. If anything it's incredibly verbose. Not bad_user, obviously, but excessive verbosity can be antithetical to readability. (As can excessive conciseness.) It can make the overall structure and meaning of the code hard to discern, even though can clearly tell where what gets assigned to what variables, etc.

The verbosity not just directly affects readability by simply being longer and more to read. It also affects writeability which in combination with lazy developers (as we all are) leads to bad, unreadable, code. This is true for any language and can most often be seen on sloppy error handling, if you have to write 2x the amount of code to handle errors will you do it? 10x?

Odd that this is showing up as a jab against Java and not, say, Go.

Re: Modern Java – A Guide to Java 8

#176

Post by jvz »

lmm wrote: post #18
escherize wrote: post #2

I personally jumped right into Clojure on the jvm without much Java experience. I've found it to be awesome. Is there a non-political reason that someone should choose Java over Clojure (or possibly Scala)? Where does Java shine?

All IME, and as a Scala fan: Clojure has a weakly integrated type system (an inherent disadvantage of optional type systems). At the simplest level this makes silly errors much easier and means you have to write more tests to maintain the same defect rate. The lack of types mean you require extensive use of macros for advanced functionality. IME macros have major maintainability issues in a multi-person codebase. Bot…

> The lack of types mean you require extensive use of macros for advanced functionality.

Could you elaborate?

Re: Modern Java – A Guide to Java 8

#177

Post by bad_user »

pjmlp wrote: post #167
mercurial wrote: post #163

Earlier quoted context omitted.

That's not the point. Due to its verbosity, it's impractical to use Java without an IDE. That's not necessarily the case for more compact languages.

Programs are written once, read multiple times.

Would be curious to find out what that means, since I see it repeated many times in favor of mainstream and verbose languages, such as Java. I get it to mean somehow that Java is more readable, however in my experience that doesn't make sense, as the IDE can deal with generating the boilerplate, but the IDE cannot help with readability. Not even if you include quick navigation by click, since that has been the purpose of ctags in plain editors.

Re: Modern Java – A Guide to Java 8

#178

Post by bad_user »

stickfigure wrote: post #175
Too wrote: post #154

Earlier quoted context omitted.

The verbosity not just directly affects readability by simply being longer and more to read. It also affects writeability which in combination with lazy developers (as we all are) leads to bad, unreadable, code. This is true for any language and can most often be seen on sloppy error handling, if you have to write 2x the amount of code to handle errors will you do it? 10x?

Odd that this is showing up as a jab against Java and not, say, Go.

Oh, it is very much relevant for Go, except that those of us interested in expressivity simply gave up on Go a long time ago.

You see, Go is not popular enough to have users that don't like it. The people that end up trying out Go simply move to something else if they don't like it. Go's community is also strongly opinionated and has rejected any dialog for meaningful improvements. In other words the Go community is filtering out people that want something different. Whether this is good or bad, you be the judge, but if there's one thing that's definitely bad is the echo chamber. Case in point you're under the impression that Go is tolerable, even though many of us consider it to be worse than Java.

Re: Modern Java – A Guide to Java 8

#179

Post by rbanffy »

meddlepal wrote: post #73
lmm wrote: post #65

Earlier quoted context omitted.

Java's way of expressing variance is really awkward (even quite popular libraries get their types wrong as a result), arrays are special-cased into unsoundness, Serializable is a total mess where it could be a perfect example of how to use a type system, there are no higher kinds, the exception system is like a second parallel type system (it even has union types, which would be incredibly useful if you could use the…

Besides null being a potential type for any reference and causing a ton of issues I do not think most Java programmers regularly care about the lack of abstractions like higher-kinded or union types. Would be nice to have, but never have I felt like I needed them. Enum types didn't exist in Java when the Comparable interface was implemented. That's why some API's look old-school by comparison because newer language f…

> I do not think most Java programmers regularly care about the lack of abstractions like higher-kinded or union types.

When you become used to a given language, you start to reason in its terms. A programmer who is used to Java is used to its shortcomings and will not miss Lisp macros or dynamic types.

Re: Modern Java – A Guide to Java 8

#180

Post by norswap »

mabbo wrote: post #92

My Java code has improve dramatically since I started (ab)using Optionals. String foo = Optional.ofNullable(paramater) .filter(...) .map(a -> ...) .map(b -> ...) .orElseGet(() -> ...) .orElse(defaultValue) Between this kind of thing, and similar playing with Streams, some of the ugliest code I work with is suddenly quite clear, coherent, understandable.

Two things. First, why is it better than:

    String foo;
    
    if (parameter != null) {
        foo = ... ;
    }
    else {
        foo = defaultValue;
    }
or even this, if you express all your transformations as a single expression:

    String foo = parameter != null
        ? ...
        : defaultValue
I don't get it. Your way of doing seem awfully more verbose. Please note that I'm not against Optional in general (although they are overplayed in my opinion).

Second thing, I can't shake off the feeling of inefficiency: building these closures up, calling them. Lots of indirection for something that's probably very simple. I wouldn't want to call this code in a hot loop. But then maybe it's not in a hot loop. Before you bring that up, the sufficiently smart (JIT) compiler doesn't exist. "Sometimes suprisingly dumb" is a better qualifier for many compilers.

Note that I work with Java, and use the Java 8 features a lot. I just think this isn't a really good example.

Post reply on HN