Why Java Now Rocks More Than Ever: Part 1 – The Java Compiler • Hacker News Board

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

#141

Post by vivin » Mon, Oct 07, 2013, 11:08 PM UTC

eropple wrote: post #112

vivin wrote: post #68

Earlier quoted context omitted.

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

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

There is no "Culture of Java" that forces you to write over-abstracted code, and it's not really that much harder to write good code in Java. Java is a tool. Sure, it has flaws, but they're not so bad that they force you to write really bad code. With Java I've never felt forced to overarchitect anything just to get it to work. Of course, I have often felt constrained by the lack of expressiveness in the language, but a lot of that will be fixed in Java 8.

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

#142

Post by pekk » Tue, Oct 08, 2013, 12:55 AM UTC

this_user wrote: post #59

pekk wrote: post #46

Why Big Band Music Rocks More Than Ever: Part 1 - You Can Dance To It There are still fans of Big Band music! Java fans (or maybe I should say, employers) who want to keep exhuming this dead horse might be well served to emphasize "you can get a job" and "it's enterprise" and "JIT makes Java faster than Assembly" as they have been doing for decades, rather than tarting it up (a Java logo with an electric guitar, seri…

Ruby is 18, Python is 22, what's your point? I'd very much like to hear your valid criticism towards Java. From my point of view that language and ecosystem is alive and well and newer iterations of Java EE have been giant leaps forward in terms of productivity.

My point is that Java isn't the new hotness and it's ridiculous to sell it that way.

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

#143

Post by pekk » Tue, Oct 08, 2013, 12:59 AM UTC

auvrw wrote: post #76

this_user wrote: post #59

Earlier quoted context omitted.

Ruby is 18, Python is 22, what's your point? I'd very much like to hear your valid criticism towards Java. From my point of view that language and ecosystem is alive and well and newer iterations of Java EE have been giant leaps forward in terms of productivity.

this. lisp is 50+ and still the most syntactically awesome thing eva.

OK. Nobody is trying to sell how Lisp "rocks more than ever" and is the great new style.

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

#144

Post by pekk » Tue, Oct 08, 2013, 1:02 AM UTC

apw wrote: post #138

marcioaguiar wrote: post #83

Earlier quoted context omitted.

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.

Would you call the Linux kernel a large project?

It is not enterprise enough. If it used Java EE then it would really scale, like a stadium sound system.

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

#145

Post by deong » Tue, Oct 08, 2013, 2:04 AM UTC

pron wrote: post #75

deong wrote: post #60

Earlier quoted context omitted.

I think calling Go a simplified Java is pretty far off the mark. Aside from both aiming at the niche of being sort of "medium-level" languages, for lack of a better term, Go's approach seems very different from Java's. Objects vs structs and functions, exceptions vs multiple return values, required static vs required dynamic linking, implicit vs explicit subtyping/interfaces, etc. Go is C with added convenience.

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…

I was mostly referring to the style of programming the languages encourage. Things like multiple return values instead of exceptions are extremely significant in what they imply about how you're intended to code in the languages.

Go tends to be written like a low-level language with very good high-level libraries. You don't have huge class hierarchies; instead you have functions. You don't have a million custom exception types; you just return error codes. Go is obviously closer to Java with respect to some of the things you can do with those concepts (things like switch statements being very general are features of much higher level languages than C, etc.), but as a programmer, you're still writing a switch statement, not a series of polymorphic methods dispatched at runtime. That's what I mean -- Go is very, very unlike Java if you're writing idiomatic code in each.

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

#146

Post by Roboprog » Tue, Oct 08, 2013, 5:35 AM UTC

waynecochran wrote: post #44

Note that the debugger (jdb) isn't listed -- for a good reason. I never understood why jdb is so poor being such a critical tool.

Reason number 1 to get an IDE for Java. Having a working [c/e]-tags replacement would probably be reason 2.

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

#147

Post by yaeger » Tue, Oct 08, 2013, 8:23 AM UTC

gresrun wrote: post #5

jonstewart wrote: post #2

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…

I wonder how such a setup would play out in regards to Open Source usage.

Say you create a big jar with all dependencies in there in several layers of "lib" folders.

Licenses like LGPL say you have to keep the LGPL archive accessible to the user and grant permission for them to alter/update them.

Would a nested hierarchy of lib folders inside your jar be viewed as hindrance? Certainly you didn't "hide" the LGPL'd components in order for the user to not alter them but I think it could be viewed as "security through obscurity". If I don't immediately see a component, how do I know its there? I guess this could be solved by a readme that lists in detail what open source components are used and where in the hierarchy they can be found.

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

#148

Post by RivieraKid » Tue, Oct 08, 2013, 11:58 AM UTC

pron wrote: post #116

RivieraKid wrote: post #108

Earlier quoted context omitted.

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.

In their FAQ, they say "Java interoperability is a major priority for the project."

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

#149

Post by RivieraKid » Tue, Oct 08, 2013, 3:26 PM UTC

eropple wrote: post #135

RivieraKid wrote: post #133

Earlier quoted context omitted.

Right now at Yammer we're moving our basic infrastructure stack over to Java, and keeping Scala support around in the form of façades and legacy libraries. The link you provided doesn't contradict that. Language can be too simple or too complex. The tradeoff that gives maximum productivity is somewhere in the middle. And in my opinion, languages like Dart or Ceylon are much closer to the optimum than Scala.

I don't think you've done anything to substantiate the claim that it's "too complex"; forgive my skepticism but I've spent enough time in both the Scala and C++ communities to draw a significant line between "too complex" and "critic hasn't learned it sufficiently" (and I've been on both sides of that line). I have spent a nontrivial amount of time with Kotlin and Ceylon and neither are particularly interesting to me…

Linus Torvalds is in the C++ is too complex camp too AFAIK :)

I believe that Ceylon is the best-designed general purpose language out there. What do you mean by "mutable-everywhere"? Ceylon's variables / attributes are immutable by default.