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

31–40 of 156 posts

Re: Paving the on-ramp to Java

#31

Post by kaba0 »

v-erne wrote: post #17

I wonder - why he has not take it a step further and propose to get rid of return type (void) also? It would look even more slick (add optional semicolons and we will get javascript out of this :)). main() { println("Hello World"); } I know that this notation is traditionally reserved for constructors but I'm not 100% sure why we cannot differentiate between methods and constructors just by looking at class name?

I see very little gain for quite a high price here. It would break the grammar quite a bit, potentially causing even breaking changes, for something that is usually not absent even in languages that do strong type inference.

The proposed changes don’t have these negatives, while still provide benefits.

Re: Paving the on-ramp to Java

#32

Post by mcculley »

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. Having static fields and state is to be avoided.

Re: Paving the on-ramp to Java

#33

Post by whizzter »

pjmlp wrote: post #13
whizzter wrote: post #12

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.

And none of the listed languages enforce main to be part of a class, hence the described problem didn't exist for your students.

I've taught C to beginners after the Java class and whilst there are some related problems those students encounter, the extra confusion caused by having main in a class doesn't exist (and doesn't cause as much syntax vs logic confusion later on).

Re: Paving the on-ramp to Java

#34

Post by kaba0 »

chrisseaton wrote: post #30
kaba0 wrote: post #27

Earlier quoted context omitted.

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

Well, there is nothing in the spec that says would forbid the JVM loading a ProgramLauncher.class file with a public static void main method, which will look at the program arguments and if it has something ending in .java, it will compile that file, and load the resulting class (current mode of execution).

Also, even if it might become a spec change (a language level one, not a jvm level one), it will be an additive change, at worst some new program won’t run on older JVMs, but all old program will continue to run on new ones.

Re: Paving the on-ramp to Java

#35

Post by kleiba »

kaba0 wrote: post #26
kleiba wrote: 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.

Hence "misses the point": I'm arguing that in order to get up to speed on state-of-the-art Java development, there's a lot more to learn than just the core language.

https://www.boston.com/culture/lifestyle/2011/07/19/literall...

Re: Paving the on-ramp to Java

#36

Post by usrusr »

joshka wrote: post #2

Another option is any classless java file is just a class with the same name as the file implementing Runnable. E.g. Foo.java println("foo") Becomes: class Foo implements Runnable { void run() { System.out.println("foo"); } } Then running java Foo.java instead just stubs a main() that looks like: class Main { void main() { new Foo().run(); } }

Instantly my mind wants to "javaify" it again, that is, generalizing it to some general case by involving qualified names:

Instead of stubbornly implementing Runnable from those flat files, mix in the well-established concept of single-function-interfaces (Runnable is just one of many) and introduce a top-level "extends" that makes the file body an SFI implementation:

  extends java.lang.Runnable;
  java.lang.System.out.println("Hello world");
(and it only gets better if you also add the rule "in absence of any imports statements, an implicit import java.lang.*; is added)

Re: Paving the on-ramp to Java

#37

Post by pjmlp »

neonsunset wrote: post #28
pjmlp wrote: post #10

Earlier quoted context omitted.

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…

It will never go away, before it was COBOL, xBase, C, C++, Smalltalk.

Tomorrow might be Go, Rust, Zig, or whatever they fancy using.

These are projects at scale of dozens of developers with various skill sets distributed around the world, optimizing for Hello World hardly matters.

Re: Paving the on-ramp to Java

#38

Post by pjmlp »

whizzter wrote: post #33
pjmlp wrote: post #13

Earlier quoted context omitted.

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.

And none of the listed languages enforce main to be part of a class, hence the described problem didn't exist for your students. I've taught C to beginners after the Java class and whilst there are some related problems those students encounter, the extra confusion caused by having main in a class doesn't exist (and doesn't cause as much syntax vs logic confusion later on).

I can assure you they were using OOP in C++, creating their own standard library, leaving behind the ways of C, as any proper C++ course during the ARM C++ days.

The lecture notes that eventually became this book were their path into discovering C++.

https://www.bertrand.pt/livro/programacao-com-classes-em-c-p...

Re: Paving the on-ramp to Java

#39

Post by sz4kerto »

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…

You can't really mock static methods though, so it makes testing harder.

Re: Paving the on-ramp to Java

#40

Post by pron »

pjmlp wrote: post #9
Kolja wrote: 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…

C# just went through this for C# 10, which I find a waste of resources, optmizing for "Hello World" is not what matters in large scale engineering.

It's not optimising for Hello World. It's optimising for a new student's learning experience, so that concepts can be introduced in a more reasonable order.
Post reply on HN