Why not abstract away the public static void main(String[] args) method with a top-level statement paradigm, similar to C#'s entry point simplification, to reduce boilerplate and enhance code conciseness?
Ugly? Sure. But isn't this the identity of Java? Taken away for almost no gain, there's literally no real issue stemming from requiring a verbose incantation to write a main routine, this is something you learn like day 1 on learning java, and it's something you write once in a blue moon, like 0.001% of the code you are going to write.
It reminds me of the attempt at removing Richard Stallman from the FSF, yeah, you could do that and fix a problem, but then what you are left with isn't really the same thing as it was before, it's now actually the same soulless thing as the rest of the competing things.
Saving grace is that obviously, you can still recite the incantation, it's not like public static void main(String[] args) is gone, just that you can skip it.
Some people have so much time or so few things to do during the day that they can write a blog post about meaningless programming languade aestheticisms that only other frivolous people will understand and enjoy.
One thing I'll miss about this was the way this arcane writing increasingly made sense over time as you became a better programmer.
I learned Java only after Python and I remember being not quite familiar with types so even the 'void' and 'String[]' where a bit mysterious. After learning basic types that part made sense. Then you start learning about Classes and objects, and you understood that main is a static method of this class Main that must be required somehow. As you dive deeper you start learning when this class is called. In a weird way what started as complete, unknowable boiler plate slowly evolved into something sensible as you began to understand the language better. I have no doubt that seasoned Java devs see a lot more in that invocation that I do.
Good riddance indeed. The last 30 years of software teaching basically trained developers to produce complexity for its own sake, while calling it engineering. I'm not sufficiently full of myself to link to my own writing (yet) but I'm full of myself enough to self-paraphrase:
1. Programmer A creates a class because they need to do create an entry point, a callback, an interface... basically anything since everything requires a class. Result: we have an class.
2. Programmer B sees a class and carelessly adds instance variables, turning the whole thing mutable. Result: we have an imperative ball of mud.
3. Another programmer adds implementation inheritance for code reuse (because instance variables made factoring out common code into a function impossible without refactoring to turn instance variables from step 2 into arguments). Result: we have an imperative ball of mud and a nightmare of arbitrary dynamic dispatch.
At some point reference cycles arise and grandchild objects hold references to their grandparents in order to produce... some flat dictionary later sent over the wire.
4. As more work is done over that bit of code, the situation only worsens. Refactoring is costly and tedious, so it doesn’t happen. Misery continues until code is removed, typically because it tends to accumulate inefficiencies around itself, forcing a rewrite.
All of these things you've described are actions taken by someone that has not had a deep think about their code and organization, architecture and patterns. It reeks of inexperience, and/or pressure to get shit done without needing any time/deep thinking on how best to do it.
While the teaching is partially to blame, i say it is more that most people are sloppy and undisciplined thinkers. When they dont have any incentive to produce disciplined code, they wont.
What we seem to have forgotten is just how c like java was compared to other programming languages being advocated at the time. Objects made sense (remember Ada?) but c++ was a mess. Java was a breath of fresh air with lots of c legacy.
What I would like to see deprecated is over using objects and design patterns and SOLID and Uncle Bob principles, so we see less FizzBuzz Enterprise Edition and Java feels less as the Kingdom of Nouns.
I distinctly recall early in my first university programming courses the instructor saying something to the effect of "Just wait until you learn 'public static void main'". I think we had only used BlueJ until that point in the course.
As a java guy and think python is weird, I don't think this sucks.
But, I also agree that can serve as terrible intro to programming if you start programming right away without understanding the basics of abstractions. But, often when we have tools either designed for a purpose in mind or a dominant paridigm or reaction to existing set of tooling, this can result in understandable yet extreme abstractions.
Java is designed with OOP in mind and it kind of makes sense to have the user to think in terms of lego blocks of interfaces. Every method or class needs to have clear understanding of its users.
public - software handle is for all users
protected - software handle for current and extending classes
default - software is exposed to current package
private - software is restricted to be used in current class alone and nowhere else
So, the beginning of java programming starts with interface exposed to the user or other programmers. Is it weird and extreme. Yes. At least, it is consistent.
My experience may be different from the rest of people at HN. But I am used to work in large projects that last decades. How main is written is totally irrelevant for my day to day work or my career.
The unnamed class approach to global variables sounds nice. You can do hot-reload, but still have unencumbered syntax.
OTOH, since Java files are named after their public class, it would have made more sense to just say the `public class X { }` wrapper is optional and only needed for attributes and inheritance. I don't quite understand why they need an anonymous class.
> The Java compiler will compile that file to the launchable class file HelloWorld.class. In this case the compiler chooses HelloWorld for the class name as an implementation detail, but that name still cannot be used directly in Java source code.
45 comments
[ 4.0 ms ] story [ 54.8 ms ] threadReleased in Java 21
https://openjdk.org/jeps/445
It reminds me of the attempt at removing Richard Stallman from the FSF, yeah, you could do that and fix a problem, but then what you are left with isn't really the same thing as it was before, it's now actually the same soulless thing as the rest of the competing things.
Saving grace is that obviously, you can still recite the incantation, it's not like public static void main(String[] args) is gone, just that you can skip it.
I learned Java only after Python and I remember being not quite familiar with types so even the 'void' and 'String[]' where a bit mysterious. After learning basic types that part made sense. Then you start learning about Classes and objects, and you understood that main is a static method of this class Main that must be required somehow. As you dive deeper you start learning when this class is called. In a weird way what started as complete, unknowable boiler plate slowly evolved into something sensible as you began to understand the language better. I have no doubt that seasoned Java devs see a lot more in that invocation that I do.
Good riddance though!
1. Programmer A creates a class because they need to do create an entry point, a callback, an interface... basically anything since everything requires a class. Result: we have an class.
2. Programmer B sees a class and carelessly adds instance variables, turning the whole thing mutable. Result: we have an imperative ball of mud.
3. Another programmer adds implementation inheritance for code reuse (because instance variables made factoring out common code into a function impossible without refactoring to turn instance variables from step 2 into arguments). Result: we have an imperative ball of mud and a nightmare of arbitrary dynamic dispatch.
At some point reference cycles arise and grandchild objects hold references to their grandparents in order to produce... some flat dictionary later sent over the wire.
4. As more work is done over that bit of code, the situation only worsens. Refactoring is costly and tedious, so it doesn’t happen. Misery continues until code is removed, typically because it tends to accumulate inefficiencies around itself, forcing a rewrite.
While the teaching is partially to blame, i say it is more that most people are sloppy and undisciplined thinkers. When they dont have any incentive to produce disciplined code, they wont.
I mean even this part:
``` var name = IO.readln("What is your name? "); IO.println("Hello, " + name); ```
is _worse_. `IO.readln` doesn't tell you whether that's file I/O or stdin/out. The more explicit the better, if you ask me.
If you can't have other top-level functions in Java, then it's a special case, which is ugly.
As a java guy and think python is weird, I don't think this sucks.
But, I also agree that can serve as terrible intro to programming if you start programming right away without understanding the basics of abstractions. But, often when we have tools either designed for a purpose in mind or a dominant paridigm or reaction to existing set of tooling, this can result in understandable yet extreme abstractions.
Java is designed with OOP in mind and it kind of makes sense to have the user to think in terms of lego blocks of interfaces. Every method or class needs to have clear understanding of its users.
public - software handle is for all users
protected - software handle for current and extending classes
default - software is exposed to current package
private - software is restricted to be used in current class alone and nowhere else
So, the beginning of java programming starts with interface exposed to the user or other programmers. Is it weird and extreme. Yes. At least, it is consistent.
public static void main(String... args)
How does it affect you this change day to day?
OTOH, since Java files are named after their public class, it would have made more sense to just say the `public class X { }` wrapper is optional and only needed for attributes and inheritance. I don't quite understand why they need an anonymous class.
> The Java compiler will compile that file to the launchable class file HelloWorld.class. In this case the compiler chooses HelloWorld for the class name as an implementation detail, but that name still cannot be used directly in Java source code.
https://openjdk.org/jeps/445