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

31–40 of 203 posts

Re: Modern Java – A Guide to Java 8

#31

Post by struppi »

rifung wrote: post #25
struppi wrote: post #15

This is a really nice overview of the new Java 8 features. I like how this tutorial communicates mostly with code snippets and has "read more" links for most topics. If you are using Java and have not tried Lambda Expressions, method references and default methods, do so now! After that, you'll think "How was I able to live without that?". I also think that the way Java integrates lambda expressions (via functional i…

If you are using Java and have not tried Lambda Expressions, method references and default methods, do so now! After that, you'll think "How was I able to live without that?" I think instead of "How was I able to live without that?", people are more likely to exclaim "about time!"

Well... depends on who you ask. I, personally, was more in the "about time!" camp. But I have met several programmers who didn't think they'd need those "newfangled features" at first. Especially in the "early days" of Java 8... And sometimes I still meet people like that. So that scentence was targeting those developers that are still stuck with Java 5 or 6 or 7 and have never tried Java 8.

Also, I was once co-teaching a C# workshop where we showed people how to work with LINQ and extension methods (long, long time ago ;) ). Some participants asked us if there was a way to configure the compiler to forbid those features for their team.

Not everybody likes "modern" features, I guess ;)

Re: Modern Java – A Guide to Java 8

#32

Post by kriro »

I've always had some sort of mistrust of Java (neo-Cobol ohnoes!) but I'm liking it more and more. Mostly I've come around to the fact that static typing isn't as bad as my young self thought (and can in fact be quite cool). The verbosity and "enterprisy" and committee oriented feel are still a bit off putting but I've made a commitment to try some Java on a couple of weekends. Did a bit of research and there's actually nice looking lean web-stuff, too (Spark Framework, Ratpack). Played with the J8 features back when it was released and they are pretty cool.

Cliffnotes: I think I have discriminated against Java mostly on a "religious" basis. I think it's a great time for people like me to give it another shot (especially if you have grown accustomed to functional ideas form other languages in the meantime).

The repo is an excellent resource, bookmarked.

Re: Modern Java – A Guide to Java 8

#33

Post by dschiptsov »

chillydawg wrote: post #23
dschiptsov wrote: post #22

Sorry, I absolutely cannot stand this "modern" meme. (define-syntax stream-cons (syntax-rules () ((_ x xs) (cons x (delay xs))))) (define (stream-cdr xs) (force (cdr xs))) (define (stream-map f xs) (stream-cons (f (car xs)) (stream-map f (stream-cdr xs)))) (define (stream-filter f xs) (if (f (car xs)) (stream-cons (car xs) (stream-filter f (stream-cdr xs))) (stream-filter f (stream-cdr xs)))) (define (stream-take n x…

It may not be modern computer science, but it is modern Java. This post is about modern Java and explains the new (in v8) features very well. What's your problem?

OK, what then is Java The point was that if one has a proper old-school computer science (to realize the crucial importance of first class procedures and the power of uniformity 20 years ago) all these modern features are coming for free, to which the code above is an illustration.

But who cares. There is a whole industry which praised Java for almost two decades even without these "modern features".

Any PL student of a decent school, if he is not a hypocrite, would tell you that Java is the worst thing that happened to CS since MS DOS, but who cares about PL theory or even CS? Availability bias and Cargo Cult is enough.

Re: Modern Java – A Guide to Java 8

#35

Post by ubertaco »

jinst8gmi wrote: post #11
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?

> Is there a non-political reason that someone should choose Java over Clojure (or possibly Scala)? Where does Java shine? If you are stuck with a group of developers who have no interest in learning anything new and wish to use Java until they retire then Java is the only choice. Other than no new learning required I can't think of many reasons to pick Java as a first choice. Java tends to be popular because it's th…

>If you are stuck with a group of developers who have no interest in learning anything new and wish to use Java until they retire then Java is the only choice.

Put another way: if you're on a dev team where nobody knows Clojure/Scala, and everyone knows Java, (and, optionally, the codebase is already in Java), and your team doesn't have time for everyone to learn an entirely new language (including cleaning up the beginner's mistakes that come with that process), then Java's the better choice.

Don't get me wrong, Java grinds my gears sometimes, and I frequently wish I could use Kotlin or F# or some kind of typed Ruby in my Java-shop workplace, and I enjoy picking up the cool ideas from languages like Idris (dependent types are really cool!) in my free time. But I'm sympathetic to my coworkers in the environment where I work: 4 devs in the whole company, startup pressure to get to a break-even point so we don't go under, and a backlog longer than all of us could finish this year even if we froze it now.

Sometimes circumstances require what looks like a short-term decision in order to ensure that there's a long term to worry about later.

Re: Modern Java – A Guide to Java 8

#36

Post by masklinn »

kriro wrote: post #32

I've always had some sort of mistrust of Java (neo-Cobol ohnoes!) but I'm liking it more and more. Mostly I've come around to the fact that static typing isn't as bad as my young self thought (and can in fact be quite cool). The verbosity and "enterprisy" and committee oriented feel are still a bit off putting but I've made a commitment to try some Java on a couple of weekends. Did a bit of research and there's actua…

> Mostly I've come around to the fact that static typing isn't as bad as my young self thought

That's not exactly a point for Java though, considering it doesn't really have a good static type system.

Re: Modern Java – A Guide to Java 8

#37

Post by lmm »

ubertaco wrote: post #30
lmm wrote: post #18

Earlier quoted context omitted.

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…

> IME macros have major maintainability issues in a multi-person codebase. I have heard this a bunch, and I believe it, but I've never personally had an opportunity to use a language that supports macros for a multi-person codebase. I'd be interested to learn what are some of the pitfalls you've seen, if you don't mind sharing.

It's not like I have a lot of experience (macros are much rarer in my primary language, Scala). But it's usually just someone doing a refactor that "makes sense" according to the logic of the regular language but not within the macro. A lot of it is simple, "silly" things like trying to extract a repeated piece of logic into a method call, only it doesn't work because the logic uses something the macro hooks into, or just is transformed in a surprising way by the macro that makes the reasoning incorrect. To take a completely trivial real-world example, renaming a field is usually a safe operation that you can do automatically (with an IDE) without even testing, but if that field's used in a macro then maybe it represents a key in a JSON object and you've just broken your web API. You notice it pretty quickly, and it's a two-minute fix - but these kind of "thousand cuts" scenarios really slow development. Outright production failures are less common but I've seen those when test coverage was poor or other failures interacted.

Re: Modern Java – A Guide to Java 8

#38

Post by cageface »

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…

A while ago I decided to teach myself how the common machine learning algorithms worked and, to make things interesting, decided to implement them in parallel in both Clojure and Scala. I expected Clojure to be a better fit for this since Lisp has historically been strong in AI. But I found as my codebase grew that the Scala code was much easier to maintain, refactor and understand. So these days I am a big fan of static typing provided it's in the form of a sufficiently expressive type system (Scala, Ocaml, Haskell, Swift etc).

Lisp got a lot of things right but I'm not sure dynamic typing and s-expression syntax were among them.

Re: Modern Java – A Guide to Java 8

#39

Post by masklinn »

tokenizerrr wrote: post #19
mhaymo wrote: post #17

> maps don't support streams This is very misleading. There is not a #stream method on Map because Map supports three different streams: map.keySet().stream() map.values().stream() map.entrySet().stream()

But those are streams on sets.

They're streams on map views, a stream on Map itself doesn't really make sense because there are multiple ways to interpret a map as a sequence and it's not clear what should be the default (e.g. Python defaults to the equivalent of keySet().stream(), but Rust defaults to entrySet().stream()).

keySet() and entrySet() return Set-conforming objects because they can, values() can't and only returns a Collection, but these three objects delegate much of their logic to the map itself.

Re: Modern Java – A Guide to Java 8

#40

Post by lmm »

raspasov wrote: post #26
lmm wrote: post #18

Earlier quoted context omitted.

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…

What do you think is not quite right about errors in tranducers? When you use them with core.async channels you can supply an optional exception handler, which is quite nice. In terms IDEs, Cursive for IntelliJ is great, and it gives almost Java-like capabilities (with limitations inherent to more dynamic languages, of course).

I forget the exact behaviour, and maybe it's been improved. But I remember that it didn't map cleanly onto values - sometimes you want to continue after a single error, sometimes you want to bail out immediately, and the ways of doing this felt very ad-hoc.
Post reply on HN