Live data from Hacker News

Paving the on-ramp to Java

openjdk.org

21–30 of 156 posts

Re: Paving the on-ramp to Java

#21
Kotlin's syntax is cleaner in some most places, more explicit in some places (no implicit nulls, and wrt generics) and much terser when using naked functions etc.

Did Java's papa get jealous?

Re: Paving the on-ramp to Java

#22
post #13

Earlier quoted context omitted.

Large scale engineering is totally beside the point for this. This is about optimizing for teaching a first language (since many will stick with that). Read the article, the "static trap" is a real thing for new students (on top of all other ceremony). To solve the issue of main being non-static some students will start to put static everywhere as a 'fix' to their initial issue, a day or two later they'll be asking w…

Back when I was a TA, first year students got along just as well with Pascal, Fortran and C++, many of which lacked a programming background. I wasn't found of minimal APIs, global usings and implicit Program.cs for C# 10, and share a similar opinion in relation to Java. No need to try to make it look like JavaScript and Python, each language has its place.

"Top-level statements" in C# is a double edge sword: In a long run it will help make C# a bit more approachable to an absolute beginner to programming by reducing "noise" and cognitive load but right now it tends to confuse the beginner due to countless tutorials, SO answers, books, courses being written using using, namespace, class, Main structure.

Which makes the feature kind of pointless. Especially since all teaching materials (and those who have used them for teaching) were saying to just ignore the rest for now and concentrate on

  Console.WriteLine("Hello World!");
which is, as it's written, confusing to a beginner anyway ("What is Console?") until he learns about classes, after which both namespace and using get clear(er).

Re: Paving the on-ramp to Java

#23
post #16

Earlier quoted context omitted.

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

You don't think serious people can be awfully opinionated about the tools in their profession? It's not like it's something unique to Java or even programming. A lot of professionals have dogmatic beliefs about what ideas, tools, etc. they subscribe to and a lot of time is wasted in bickering about it, whether unjustified or not.

I can understand them having an opinion.

I wouldn’t think a serious person would continually bring it up as an actual issue preventing them achieving things.

Re: Paving the on-ramp to Java

#24
The declaration of a class and the incantation of public static void main is pure mystery to a beginning programmer.

This article misses the point, however. The problem is not writing your first hello world. The ceremony is not so much in the language itself but in the infrastructure. The verbosity of the language is just the tip of the iceberg.

I think Java back in the 90's started out actually quite decently, although from the get-go it had the verbosity. But at least it didn't have everything else yet that you're expected to know for any non-trivial program.

The first time the word "enterprise" appeared together with Java was the moment it went all downhill.

Re: Paving the on-ramp to Java

#25
post #16

Earlier quoted context omitted.

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

You don't think serious people can be awfully opinionated about the tools in their profession? It's not like it's something unique to Java or even programming. A lot of professionals have dogmatic beliefs about what ideas, tools, etc. they subscribe to and a lot of time is wasted in bickering about it, whether unjustified or not.

Genuinely, I found out that people who tend to be very dogmatic don't tend to be all that great when you look at their actual output - whether measured by quality or speed or ability to orient themselves is someone elses code. They do tend to sound more capable then they are to those who dont work with their code, but that is social thing not capability or seriousness thing.

Opinionated yes, dogmatic not.

Re: Paving the on-ramp to Java

#26
post #24

The declaration of a class and the incantation of public static void main is pure mystery to a beginning programmer. This article misses the point, however. The problem is not writing your first hello world. The ceremony is not so much in the language itself but in the infrastructure. The verbosity of the language is just the tip of the iceberg. I think Java back in the 90's started out actually quite decently, altho…

There is literally nothing related to “enterprise Java” in this post.

Re: Paving the on-ramp to Java

#27
post #3

This seems to be a weird micro-optimisation. While I agree with some of the goals (classless files, parameterless main exist in Kotlin and are nice to have), they should, in my opinion, not be implemented for the sole purpose of making `main` as minimal as possible. I don't think you need to understand every single character of your very first program right from the beginning. A few of the concepts can be hand waved…

Extra language specification rules that you need to be aware of for your whole career... in order to make the first 30 seconds easier when looking at hello-world for the first time.

The genius of this proposal is that besides the implicit unnamed class, the other changes are all purely done to the program launcher program, no changes are proposed for the language at all.

And one could argue that quickly writing up some program happens often regardless of skillset (I do make at least two psvm Main classes per month), so the code reduction there is also a welcome change.

Re: Paving the on-ramp to Java

#28
post #10

Earlier quoted context omitted.

Extra language specification rules that you need to be aware of for your whole career... in order to make the first 30 seconds easier when looking at hello-world for the first time.

As I mention on the sibbling comment, C# 10 already went through this. For me it seems like a reaction to JavaScripts and Pythons of this world, optimizing for Hello World just to win over them on those 30 seconds. They are going to rewrite their applications anyway, when performance comes knocking on the door.

I think there is more value to a terse declaration of 'main()' than people think. In C#, you can declare a quite functional microservice under 90 lines of code with asp.net core's minimal api format. To this day I think the "enterprise style religious OOP+SOLID Java/C#" is something that has to go - so many applications that take 30 files and 4 projects could've been declared in 3-5 files with the most of core logic being in Program.cs that you can grasp within few seconds of looking at it.

Re: Paving the on-ramp to Java

#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 on the language level. For the rest, we will see. I think foregoing public requirements is a no-brainer, the rest may need a bit further thought based on further comments, here is the mailing list: https://mail.openjdk.org/pipermail/amber-spec-observers/2022...

Re: Paving the on-ramp to Java

#30
post #27

Earlier quoted context omitted.

Extra language specification rules that you need to be aware of for your whole career... in order to make the first 30 seconds easier when looking at hello-world for the first time.

The genius of this proposal is that besides the implicit unnamed class, the other changes are all purely done to the program launcher program , no changes are proposed for the language at all. And one could argue that quickly writing up some program happens often regardless of skillset (I do make at least two psvm Main classes per month), so the code reduction there is also a welcome change.

> the other changes are all purely done to the program launcher program, no changes are proposed for the language at all

But the behaviour of the launcher is covered by the language spec isn't it? It's the language that specifies how main is selected.

https://docs.oracle.com/javase/specs/jls/se19/html/jls-12.ht...

Post reply on HN