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

Paving the on-ramp to Java

openjdk.org

Post reply on HN
Print view View original

71–80 of 156 posts

Re: Paving the on-ramp to Java

#71

Post by kaba0 »

kubota wrote: post #69
RayVR wrote: post #53

Earlier quoted context omitted.

Succinctly? You must be a Java programmer. This essay is at least 3-4x longer than I’d like. As a (mostly) python and C++ programmer, Java feels like someone is afraid they’re speaking to an imbecile, so they constantly repeat themselves and over-explain every point.

As a java developer I would challenge you to a code golf session. You supply two problems which demonstrate the conciseness of your preferred language and I'll supply two problems which demonstrate the conciseness of Java. Then we'll see which language can implement solutions in the least amount of lines or semicolons.

I prefer to use number of words, because I used to believe haskell and alia were shorter than a corresponding imperative program, but it turned out it just took up more horizontal space, and was roughly comparable in this metric.

Re: Paving the on-ramp to Java

#72

Post by kaashif »

mcculley wrote: post #62
bheadmaster wrote: post #56

Earlier quoted context omitted.

I think they meant "functions" in the mathematical sense. Although due to the ambiguity of the word "function", your nitpick still has its place.

Yes, I definitely meant in the mathematical sense. I would really like a way to express pure functions in Java. There would need to some way to mark objects as immutable at the language level.

I switched from being a C++ developer to Java a while back and the lack of const (i.e. immutability) annoys me.

It annoys me even more than no-one seems to care about it much, and most think final is good enough - you can still mutate final objects. In C++ all references are final (in a Java sense) since they can't be reseated, but const actually gets you immutability (modulo const_cast).

I just want everything to be immutable unless mutability is really truly needed!

Re: Paving the on-ramp to Java

#73

Post by jmartrican »

kubota wrote: post #67
ferd wrote: post #64

Applause! However, it's not always about "saving keystrokes"... it's about lowering accidental complexity and making code easier to reason about by requiring less cognitive load on the reader. Another example: the lack of literals for collections in Java. Imagine this: Map x = {"a": "A", "b": "B"}; // not Java vs: Map x = new java.util.HashMap(); x.put("a", "A"); x.put("b", "B"); The first case is more declarative, a…

var ages = Map.of("sarah",19, "dan",35); //valid java

Map.of came out in JDK 9. I think there are still a lot of companies using JDK 8.... uhg. Maybe OP is one of the poor souls stuck in JDK 8.

Re: Paving the on-ramp to Java

#74

Post by jmartrican »

kubota wrote: post #67
ferd wrote: post #64

Applause! However, it's not always about "saving keystrokes"... it's about lowering accidental complexity and making code easier to reason about by requiring less cognitive load on the reader. Another example: the lack of literals for collections in Java. Imagine this: Map x = {"a": "A", "b": "B"}; // not Java vs: Map x = new java.util.HashMap(); x.put("a", "A"); x.put("b", "B"); The first case is more declarative, a…

var ages = Map.of("sarah",19, "dan",35); //valid java

Nice touch using "var" to show that off too.

Re: Paving the on-ramp to Java

#75

Post by exabrial »

mcculley wrote: post #32

I am amused by this: > Worse, the early exposure to static methods will turn out to be a bad habit that must be later unlearned. I have been using Java since 1.0 and it is my default language. I am writing Java code today. I write functions using ‘static’ all the time. I prefer that a function be static. It shows that it does not depend on state of the enclosing object. Using ‘static’ on methods is not a bad habit. H…

They’re fine if they are self contained, which is your point, and which is the author’s point (and generally everyone else). He didn’t go into detail of the why, but that is east is usually meant.

A good clean programming have it is to wrap all of your stream()/lambdas chains in a static method that describes what they do. This make sure they don’t have access to the local scope and can mutate data.

Re: Paving the on-ramp to Java

#76

Post by pron »

Sakos wrote: post #11

Confused about the criticisms now. Otherwise everybody complains about Java boilerplate. Remove some of it and make it optional, to avoid bogging down newbies in irrelevant details in the first instance, and further lead to less boilerplate to make simpler applications in the second instance (or further down the line). I'm not seeing a massive amount of effort being expended here, and I don't see how it's being waste…

When you have such a large ecosystem (Java's user base is larger than the population of quite a few European countries or the population of the San Francisco Bay Area), no matter what you do or don't do, there will be plenty of complaints because there are few things programmers are in consensus over. Satisfying everyone is impossible. If 99% are content with some Java feature (or lack thereof) and 1% of the remaining 1% complain online, you're looking at a thousand complainers.

Re: Paving the on-ramp to Java

#77

Post by jmartrican »

doctor_eval wrote: post #54
qsort wrote: post #15

Earlier quoted context omitted.

I agree. Ironically, Java the language doesn't have any more boilerplate than, say, C++ or Go, which people are apparently okay with? It does however have some stuff that's plain dumb (can't have functions outside classes, public static void main(String[]), ...) some of it isn't even fixable (default visibility should be private, final should be like const in C++, or even better like const in D). This is a change tha…

Java the language is fine, but Java has - or used to have? - so much idiomatic boilerplate - worst of all IMO was the ridiculous imperative to write getters and setters for every field, but there was also a plethora of very broad interfaces - all of which required all kinds of boilerplate and/or delegation to be able to use. Don’t even get me started on the frameworks. Maybe Java has changed in the last 5 years, but…

To your point, I started writing my POJOs without getters/setters. It felt like I was doing something wrong and the ghosts of senior devs I have worked with were looking down at me with shame.... "how could you".

The worst part is that some libraries use getters as convention. e.g. Jackson (by default) uses getter methods to decide what to serialize.

Re: Paving the on-ramp to Java

#78

Post by nailer »

This is still too long. I think C# already supports top-level execution (eg, your program is assumed to be main() as do almost all other languages). `println` is also a bad name for something that could just be `log` or `print`.

Re: Paving the on-ramp to Java

#79

Post by ferd »

kubota wrote: post #67
ferd wrote: post #64

Applause! However, it's not always about "saving keystrokes"... it's about lowering accidental complexity and making code easier to reason about by requiring less cognitive load on the reader. Another example: the lack of literals for collections in Java. Imagine this: Map x = {"a": "A", "b": "B"}; // not Java vs: Map x = new java.util.HashMap(); x.put("a", "A"); x.put("b", "B"); The first case is more declarative, a…

var ages = Map.of("sarah",19, "dan",35); //valid java

Nice, glad to see that added to the standard API (even if a bit too late).

Stressing the point: this welcomed improvement on the API is a lot more than "saving keystrokes".

Re: Paving the on-ramp to Java

#80

Post by jmartrican »

chrisseaton wrote: post #14
Sakos wrote: post #11

Confused about the criticisms now. Otherwise everybody complains about Java boilerplate. Remove some of it and make it optional, to avoid bogging down newbies in irrelevant details in the first instance, and further lead to less boilerplate to make simpler applications in the second instance (or further down the line). I'm not seeing a massive amount of effort being expended here, and I don't see how it's being waste…

> Otherwise everybody complains about Java boilerplate. Do serious people actually complain about this often? I think it's more of a drive-by comment from people who don't like Java for whatever other reasons.

I agree. One dev I was working with was complaining about how much code they had to write (wrt a design pattern, and not Java specifically). But the problem was not the design patter (which I agree is hella verbose, ports-and-adapters), it was the fact that they did not know how to use their IDE. I had to explain that until you increase the proficiency of your IDE skills, every pattern is going to be slow for you. What took them several minutes to do, could be done in a few seconds by an IntelliJ expert. I know counter arguments can be made. But still. If you gonna ride a horse through tough terrain, you should really get good at using your horse, and not complain about the terrain.
Post reply on HN