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 why every student gets the same name (because they have one static variable to keep the student or name objects).
The verbosity of Java also introduces another more serious problem for learning, not only do the students have problems compiling, they also start putting their mind on focusing on syntax instead of logic once they're past the first few problems. The issue of de-programming students from this affliction is waaay too common to be ignored.
Anecdata - I'm self taught. Started my learning on Python.
I wanted to delve into Java. And sure enough, my very first thoughts were "wtf is public static void, why does this even matter, and why is print() so weird and long?"
Shit, I ended up finding it easier to get into F# than Java.
Then I got hired for a Java role, which is proof that the universe has a sense of humour.
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++.
"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).
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.
I beg to differ, as soon as they need a second file, import a dependency or use additional helper methods, they get to face all of it anyway.
And then there is the issue with leaky abstractions when the code that gets compiled interfers with the ideal worlds that the compiler injects, and possible confusing error messages get generated.
Like it happens with all guest languages that target the JVM pretending to be Java, and one gets a confusing stack trace only understandable by those with proper Java background.
> as soon as they need a second file, import a dependency or use additional helper methods, they get to face all of it anyway.
The problem isn't the set of things students will need to learn, but the order in which they encounter them. Students write a one-file program before they write a two-file one, but because Java is optimised for large programs, today they encounter things like accessibility rules -- which exist to serve large programs -- before they even get to write a very small one. That's the idea of the "on-ramp" in the title -- you end up int the same place, but with a smoother ride.
Both students and teachers who prefer Python to Java as a first language mentioned this "on-ramp" problem as one of the reasons. There are others, and they will be addressed by other enhancements.
BTW, importing other packages and using helper methods does not require knowing about accessibility rules.
> Like it happens with all guest languages that target the JVM pretending to be Java, and one gets a confusing stack trace only understandable by those with proper Java background.
But this is not a "guest language" and we'll need to ensure that stack traces -- which we also control -- will not be confusing.
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 why every student gets the same name (because they have one static variable to keep the student or name objects).
The verbosity of Java also introduces another more serious problem for learning, not only do the students have problems compiling, they also start putting their mind on focusing on syntax instead of logic once they're past the first few problems. The issue of de-programming students from this affliction is waaay too common to be ignored.