Live data from Hacker News

Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

zeroturnaround.com

111–120 of 149 posts

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#111
post #5

Beefs with this article: 1. Runtime-linking _is_ dynamic linking, and it's a PITA that Java doesn't have an option for static linking, especially given the inherent fragility of the CLASSPATH. 2. clang and gcc have compatible command-line option syntax. 3. The options example he lists for gcc is a pure strawman. Maybe they are necessary to compile that particular source file, but it is not necessary to use all these…

> 1. Runtime-linking _is_ dynamic linking, and it's a PITA that Java doesn't have an option for static linking, especially given the inherent fragility of the CLASSPATH. It is possible to roll a 'fat' JAR with all your dependencies baked-in, which is as close to static linking as it gets in Java-land. I prefer this for stand-alone applications as it makes deployment a cinch at the expense of the size of the build art…

Yeah, I've used jarjar before for this.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#112
post #68
post #64

One of the things I see with Java today, how difficult things have gotten with the language. Its next impossible to deal with any large Java project without an IDE. The verbosity of the code is mind boggling. Often method calls are 4 - 6 layers deep, which in itself makes is very difficult to remember or even implement even if you read the documentation well. The resulting code is massive walls of text. 90% of that i…

> Often method calls are 4 - 6 layers deep, which in itself makes is very difficult to remember or even implement even if you read the documentation well. I think that's a symptom of bad design than a problem with the language. The language doesn't force you to create abstractions on top of abstractions and it is not necessary. Having method calls like that is a bad code-smell. Java does have a verbosity problem and…

> The language doesn't force you to create abstractions on top of abstractions and it is not necessary.

The culture of it does. When all of the code around you is objects-as-design-pattern bad-abstraction slop, you're going to think that's the right way to do it. Which for a certain value of "right" it may be, but it still sucks. You can write "good" Java, but it's still going to be more expansive and harder to read than good C# (which aggressively trims back Java design pattern crap) or good Scala (which goes way, way further).

> that the JVM is turning into a platform

Agreed, and this will save it, but Java's not helping itself at all.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#113
post #64

One of the things I see with Java today, how difficult things have gotten with the language. Its next impossible to deal with any large Java project without an IDE. The verbosity of the code is mind boggling. Often method calls are 4 - 6 layers deep, which in itself makes is very difficult to remember or even implement even if you read the documentation well. The resulting code is massive walls of text. 90% of that i…

It's impossible to deal with ANY LARGE PROJECT without an IDE. If you don't use an IDE, your project is not large yet.

This is an incredible generalization. I've very comfortably navigated codebases in the thousands of files of Python with only find and ack to guide me. I've done a lot of C# in Vim, too.

But I can't do the same in Java; at my last job we had thousands of .java files and I was stuck fumbling around with an IDE to do anything. The verbosity and repeated ceremony of the language makes it difficult to search for anything in an effective manner and the distractingly clumsy syntax (inner classes, as an example) made trying to Vim it failure-prone enough that I'd use an IDE just for the red squiggles. Those being in and of themselves concerning at times--I'd often find myself just trying to make the red squiggles shut up rather than concentrating on writing better code. I don't find myself doing that in Scala or C# or even C++.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#114

Earlier quoted context omitted.

> Its next impossible to deal with any large Java project without an IDE True, but I don't see it as a problem (for me). > The verbosity of the code is mind boggling. I don't find Java that verbose (especially with lambda functions in Java 8). > method calls are 4 - 6 layers deep I don't understand, do you mean nested method calls? > 90% of that is machine generated through eclipse. Definitely not 90% and lot of the…

> I don't find Java that verbose (especially with lambda functions in Java 8). Honestly: use something better for a while and come back and say that. Java is verbose. There is a ton of ceremony around anything in it, from ill-considered defaults that require lots of specification (see Scala's remarkable ability to strip bullshit out of its equivalent to Java code) to the cultural design-pattern mess. It's a lowest-co…

> Honestly: use something better for a while and come back and say that.

I've written code in about 20 different languages.

What language features / lack of features do you think make Java verbose?

I found Scala complex and ugly (and I'm not alone), much slower to compile than Java and Java has better tooling.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#115
post #104
post #75

Earlier quoted context omitted.

Structs + interfaces in Go are a re-interpretation of Java interfaces (albeit a major one). It's a different path, but the same philosophy (dynamic dispatch over receiver type + mutable state). Exceptions vs. multiple return values are two different local decisions made by Go's designers: multiple return values and lack of exceptions. Multiple return values are handy (might find their way to Java one day), but I woul…

Not so! Go explicitly exposes indirection, while every Java object is a pointer. The result is that control of what is in L1 with Java is impossible, while memory locality can be forced in Go.

Struct arrays are sorely missing from Java (hopefully they'll be included in Java 9), but other than that, an object is allocated contiguously in memory. In fact two objects allocated by the same thread one after another will be allocated contiguously, so "inner" objects allocated during objects construction will be adjacent to the original object.

Go's designers have said that they wanted to experiment with a more direct approach to memory in exchange for a less advanced GC.

So, you are right that in terms of memory placement issues, Go is more low-level than Java, but it's higher level when it concerns scheduling. All in all, it places them pretty much at the same level. It certainly doesn't make Go closer to C.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#116
post #102

Earlier quoted context omitted.

I find most of it ugly. But I'm looking forward to Kotlin. I believe Kotlin is what most of us had hoped Scala would be when it first came out, before it turned into the unholy Java-Haskell-Lisp-C++-Javascript hybrid that it is today.

I quite like Kotlin at first sight but I currently use Eclipse... (looks much better on Linux than IDEA) I'm also looking forward to Ceylon.

For Ceylon I believe Java integration is a secondary concern, while for Kotlin it's one of the most important ones.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#117
post #35

Earlier quoted context omitted.

One problem of many is that Java is quite verbose, and while IDEs like Eclipse help with this, there's a significant contingent of open source developers who both refuse to use typical IDEs and who also like to manually manipulate their code rather than let an IDE tweak it about. Languages like Ruby and Python make that easily manageable in a way Java doesn't.

The 20-50x performance tradeoff is a hard pill to swallow though. I'd love to see a better performing dynamic language that isn't as minimal as Lua.

I've come to think of it as a plus that the entire semantics of a language can fit in working memory. What features do you find to be missing from languages like Lua and Scheme?

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#118

Earlier quoted context omitted.

> Its next impossible to deal with any large Java project without an IDE True, but I don't see it as a problem (for me). > The verbosity of the code is mind boggling. I don't find Java that verbose (especially with lambda functions in Java 8). > method calls are 4 - 6 layers deep I don't understand, do you mean nested method calls? > 90% of that is machine generated through eclipse. Definitely not 90% and lot of the…

> I don't find Java that verbose (especially with lambda functions in Java 8). Honestly: use something better for a while and come back and say that. Java is verbose. There is a ton of ceremony around anything in it, from ill-considered defaults that require lots of specification (see Scala's remarkable ability to strip bullshit out of its equivalent to Java code) to the cultural design-pattern mess. It's a lowest-co…

> the cultural design-pattern mess.

While it may have become cultural, the design-pattern mess is directly related to the limitations of Java the language when applied in its typical domains of application. The reason many languages whose features evolved in light of the Java design pattern mess don't share that mess isn't purely cultural, it is because the features of those languages were designed specifically (often drawing from older languages that didn't have the same problems as Java but which weren't popular in Java's role for other reasons) to overcome the limitations that require those patterns in Java; this is perhaps nowhere as obviously the case as it is with Scala.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#119
post #88

Earlier quoted context omitted.

> Its next impossible to deal with any large Java project without an IDE True, but I don't see it as a problem (for me). > The verbosity of the code is mind boggling. I don't find Java that verbose (especially with lambda functions in Java 8). > method calls are 4 - 6 layers deep I don't understand, do you mean nested method calls? > 90% of that is machine generated through eclipse. Definitely not 90% and lot of the…

I like working with Java too. I'm only pointing out the problems, which I see are pretty clear. The only problem is from the perspective of using and developing a new skill, I would rather use a newer language which is better built for problems of our time than something 20 years back. Java has had its day in the sun. Its primary purpose was to become an easy C++ for people who didn't get memory management and people…

Each newer language has one common denominator - lack of proper IDE. Even though they come with some synctactic sugar, your productivity gets nailed by lack of good IDE.

Java syntax has many problems, but they are very easy to overcome thanks to IDE and many JVM tools.

Re: Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler

#120

Earlier quoted context omitted.

> I don't find Java that verbose (especially with lambda functions in Java 8). Honestly: use something better for a while and come back and say that. Java is verbose. There is a ton of ceremony around anything in it, from ill-considered defaults that require lots of specification (see Scala's remarkable ability to strip bullshit out of its equivalent to Java code) to the cultural design-pattern mess. It's a lowest-co…

> Honestly: use something better for a while and come back and say that. I've written code in about 20 different languages. What language features / lack of features do you think make Java verbose? I found Scala complex and ugly (and I'm not alone), much slower to compile than Java and Java has better tooling.

- No pattern matching. This alone basically makes the rest of this list just piling on; once you have 'gotten' pattern matching, Java (and, to be fair, most other popular languages) becomes intolerable.

- Lack of even halfassedly reified generics means you're throwing Class objects around everywhere for no good reason. (Scala adds manifests as implicit parameters and it's not as good as .NET but it's a hell of a lot better than Java.)

- Actually, let's just go with "the type system in general". For being built upon the same shitty tools as Java, they do a lot to provide an environment where thinking about types isn't prohibited.

- Inner classes being used for nontrivial things (see also: all of Android, saved only by AndroidAnnotations; all of Swing, saved only by never having to use it).

- No comprehensions. Nuff said.

- Null by default. Option types are both safer and easier to work with functionally than imperative null boilerplate.

- Nonfunctional control constructs. For example, 'if' being a functional construct makes tons of code simpler and easier to read.

- No default parameters. Dumb. Whenever they get them I'm sure it will be something less expressive than Scala's (something like "must be resolvable at compile-time") because doing otherwise will be hard.

- Braces everywheeeeere. The ability to go "def foo() = someFunc(localVar)" is awesome. Less bullshit, more code.

- Interfaces suck when traits exist. The idea that I need to write wireup code when I have getBar and getBars methods (because any sane person will implement getBar as a hat on top of getBars with a singleton list) is utterly stupid.

- Nonfunctional core APIs (where's my map/filter/fold?) that think mutability is a good thing. Guava tries to help, but it's bolting onto a fairly stupid List/Iterable core pattern.

- Reference-reseating-by-default means doing it right adds foolish 'final' keywords everywhere.

- Private visibility (or, to be specific, not-really-private, WTF?) by default means you will be splattering 'public' everywhere, too. This and the last two combine to make objects full of weird action just for funsies; if everything's immutable by default, the cases where you need 'private' to not blow up the world shrink immensely.

- Keywords and methods where operators make sense. List.add() is derpy. "T extends SomeClass" is a traveshamockery. We're programmers, computer science should not be that foreign, there are mathematical symbols to express this in type theory--so use them, as Scala does (I'd rather they used ".

Scala is complex. Nobody said it's not. But it's complex because it's expressive. It's a predictable language with expressive semantics that doesn't make you do stupid shit to get things done. The tooling has reached a point where I no longer notice it and while it is slower to compile than Java, so is C++ and that doesn't bother me either because what I get is better at what it does.

I don't much care for the look of Python, but it's better and more suited to some tasks and so I get over it and use it. You may find Scala "ugly" and I'm sure you can find plenty of entrenched Java developers to agree with you, but outside of the epistemic Blub-closure of the Java world it is rapidly becoming understood that Java is better at nothing by design.

Post reply on HN