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

61–70 of 156 posts

Re: Paving the on-ramp to Java

#61

Post by KptMarchewa »

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 like and professionally write Java. Unnecessary boilerplate is the worst part of language, and I'm happy that Java authors agree with me and incrementally fight it.

Re: Paving the on-ramp to Java

#62

Post by mcculley »

bheadmaster wrote: post #56
hardware2win wrote: post #45

Earlier quoted context omitted.

>like pure functions Small nitpick :p

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.

Re: Paving the on-ramp to Java

#63

Post by csmeyer »

I like the idea of simplifying the main method, but it's honestly not a huge barrier as a high school teacher. Most IDEs will fill in the declaration of main for you, and I think it's perfectly fine to tell students "we'll worry about that later, write your code in the braces" without diving in to all the details. To me, what would be more helpful is an easier way to read input from stdin during a program. I usually give my intro students a static class that wraps Scanner, but it's a bit of a pain.

Re: Paving the on-ramp to Java

#64

Post by ferd »

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, and thus easier to grasp. In the second case you have to read, parse and "execute" line by line in your head... (Does ordering matter? Does line 3 depend on line 2?, etc).

When things like these compound, you end up with code-bases many times bigger and harder to grasp than in other languages.

Granted: you can write shitty code in any language, nothing will save you from that... But I think Java makes it harder to write simple and concise code, even to experienced coders.

Then there's also the "cultural" thing many already mentioned ("enterprise Java")... which is very real, but no JEP/JSR will fix that ;-).

Brian shows brilliance, even at "trivial" issues. I trust his judgement :-).

Re: Paving the on-ramp to Java

#65

Post by monster_group »

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…

Static methods are a pain for unit testing though. I have started avoiding them for that reason alone. For stateless objects, you can always have a singleton and invoke all the methods on that object giving effectively static behavior without the baggage.

Re: Paving the on-ramp to Java

#66

Post by pron »

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…

> It shows that it does not depend on state of the enclosing object.

Fine, but that's not relevant to the subject of this document, the "first program", as it would make all fields static, too, and so methods would still be dependent on state. It will just make moving to the next step harder; as the article says: this is probably not the direction we want to go when we scale up from a handful of statements and declarations to a simple class — we probably want to start using classes as classes, not just as containers for static members.

Re: Paving the on-ramp to Java

#67

Post by kubota »

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

Re: Paving the on-ramp to Java

#68

Post by hddqsb »

csmeyer wrote: post #63

I like the idea of simplifying the main method, but it's honestly not a huge barrier as a high school teacher. Most IDEs will fill in the declaration of main for you, and I think it's perfectly fine to tell students "we'll worry about that later, write your code in the braces" without diving in to all the details. To me, what would be more helpful is an easier way to read input from stdin during a program. I usually…

The article briefly mentions a hypothetical static method "readln", which would help with reading input.

Re: Paving the on-ramp to Java

#69

Post by kubota »

RayVR wrote: post #53
kaba0 wrote: post #29

I always love seeing Brian Goetz’s articles, they explain the problem succinctly and they do a great job of validating their approach, showing the shortcomings of alternatives. I especially like the language team’s very conservative attitude, valuing backwards compatibility greatly. Here, they again solve most of the problem by simply changing the “program launcher” code, without any modifications/special casing done…

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.

Re: Paving the on-ramp to Java

#70

Post by salil999 »

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…

> Having static fields and state is to be avoided.

This is totally false. It will always depend on the use case.

Post reply on HN