Live data from Hacker News

Modern Java – A Guide to Java 8

github.com

61–70 of 203 posts

Re: Modern Java – A Guide to Java 8

#61

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?

Java works great on large teams. The stuff that people complain about as "too much boilerplate" and "super boring" when you're writing code is actually really awesome when you have to read a bunch of code and half the people who wrote it are gone. Boring is better than clever when it comes to maintenance.

They're conservative about adding features, so they've managed to keep the language pretty small, and the core concepts of "what is good Java code" have been mostly the same for like 15 years, even through major releases like 1.5.

Re: Modern Java – A Guide to Java 8

#63
post #7

Earlier quoted context omitted.

There's a gravitational pull towards popular languages because popular languages have more books, more (idiomatic) libraries and tools, copy-pasteble examples all over the web and a big pool of developers that can be productive from day 1 on simple problems. In order to adopt a language that isn't in the top 6 or so, you've got to have good reasons for it. And depending on the problems you're trying to solve, sometim…

I don't know how you can find even average Java code unreadable. If anything it's incredibly verbose. Only now with the most recent features is it really likely that you'll run into some one-liners and magic functions. Now, if you were talking about frameworks/app servers and not being able to figure out which levers and knobs to push to get them to behave, I would agree wholeheartedly. I'm not saying Java is good lo…

> 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.

Re: Modern Java – A Guide to Java 8

#64
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…

Good luck with your experiments.

Many of us in the 90's jumped into Java, in spite of its issues, because it made it more pleasing to write cross platform code, than using C or C++ with CORBA/COM across OSes with compilers that were still playing catchup with the standards.

Re: Modern Java – A Guide to Java 8

#65
post #41

Earlier quoted context omitted.

> 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.

Could you define good?

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 them in the rest of the language). More than that, the standard library doesn't really use the type system to its full effect, e.g. errors in JDBC are C-style numeric codes, Comparable returns an int for what should be a 3-value enum.

(To answer your question, a type system should be sound unless and until the user explicitly requests otherwise, easy to use, but above all consistent)

Re: Modern Java – A Guide to Java 8

#66

Earlier quoted context omitted.

>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 be…

With existing Java code and/or a tight timeline with existing skills I can see how that would be the best choice :) I'm thinking more in terms of the surprisingly high proportion of Java developers who have never learned another language since learning Java 10-15 years ago and dismiss any alternatives without ever exploring what else is out there (you clearly don't fall into that category :).

This is quite typical in most companies where devs don't have trainings nor wish to spend time with work in their free time.

I bet you will find thousands of C++ devs that don't even know that there are newer versions of C++98.

C devs that still use K&R as their guide with C89 code style.

And so on.

We are the few select ones that care to improve our skills.

EDIT: Typos.

Re: Modern Java – A Guide to Java 8

#67

Earlier quoted context omitted.

> 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 be…

You can write Java-without-semicolons in Scala and be productive from day 1, possibly even hour 1. Then you work up to fancier features as and when they provide a practical advantage. That's how I started.

Re: Modern Java – A Guide to Java 8

#68
post #58
post #55

Earlier quoted context omitted.

Your JVM runs on all things written in C and the concurrency primitives are far more elegant in Go than in Java.

Agree and disagree. The thing I was going for is that compscience advantages don't seem to matter for language adoption. i.e. popularity does not correlate to compsci purity.

I understand; however, less is more: http://commandcenter.blogspot.com/2012/06/less-is-exponentia...

Re: Modern Java – A Guide to Java 8

#69
I am the only one that has been thinking for months now that "modern" is the most over used, pointless, and almost negatively connotative word in this industry? Thought exercise: Imagine the ugliest flat and incomprehensible UI widget you have seen lately, the most bloated website load that doesn't crash the browser, and some mindless office dialog about "rising cloud costs". Now pick one word. Survey says - you guessed it. So most certainly, if you need to be more "modern", I'm sure java 8 is a vehicle to take you there.

Re: Modern Java – A Guide to Java 8

#70
post #58
post #55

Earlier quoted context omitted.

Your JVM runs on all things written in C and the concurrency primitives are far more elegant in Go than in Java.

Agree and disagree. The thing I was going for is that compscience advantages don't seem to matter for language adoption. i.e. popularity does not correlate to compsci purity.

Yes, there are different forces in a play.

Let's name it as The Law of a Decent Runtime, and The Law of Attention to Details, and The Law of a Bazar of Ignorant.))

The Law Of a Decent Runtime is very simple - evolving a decent runtime is very costly and time-consuming. It is also related to the second law and to the inverse of the third - which is a the Law of Dictature of The Most Competent. A decent runtime cannot be produced without talent, time, financing, competence and attention to details.

The examples are what came out of Xerox Parc, Bell labs, Ericsson and the best parts of academia (MIT Scheme culture, Scala, Standard ML, LLVM and Haskell, monads aside).

There are also many in-house (Tensorflow) and sponsored open source porjects (LLVM, Golang, Julia, Torch, to name a few). Basically, it is about resources spent on a talent.

What is important distinction - a decent runtime cannot be produced by the Bazaar of Ignorant (PHP, amateur Java code, SAP, and other "fractals of a bad design").

The Linux kernel is very special example, because it combines the law of big numbers, and all these three - it is a product of a whole planet of competent volunteers and paid developers - unlike PHP or Java ecosystem there is very high barrier to entry, thanks to The Dictature of The Most Competent .)

The law of Attention To Details - is quite obvious, and related to the first. This is why most of successful projects had a passionate and competent leader who sets the standards, be it Linux kernel, Erlang, Nginx, Gambit Scheme, Python, OpenBSD, Redis, Scala, SBCL, PostgreSQL, you name it.

Popularity has nothing to do with it. It is based on the principle of instant gratification (PHP, MongoDB) or Availability Bias boosted by paid content brainwashing (Java, SAP, MS) without understanding and preferably any thinking. Popularity doesn't mean quality at all, be it junkfood or PHP.

Post reply on HN