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.
How does it affect you this change day to day?
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.
How does it affect you this change day to day?
Or if you're an Android developer then main doesn't exist at all and never has
But yeah I don't understand why the author is so excited about this. How "ugly" a trivial "Hello, World!" does not really matter much and isn't a good indication of anything about the language's ability to handle more than "Hello, World!"
I think it does say something about what a language thinks is important.
Java (historically) is famous for going a bit too hard core into overly abstract & verboseobject oriented design patterns - create a factory to get another factory to get a different factory and whatnot. The hello world is where java shows that style of code is what historical java felt was the ideal.
That is just a coding style. I don't use factories in Java, they are just confusing when there are simpler ways to get the job done.
Factories are a pattern that is not unique to Java. They're used prolifically in C++ at least, and I'm sure in other languages.
The factory pattern is tightly coupled with polymorphism. If you're not using polymorphism, then you may not typically need factories. But if you are, then at some point you're going to have some conditional logic about what concrete type of class you're going to create of a particular interface.
Modern Java is lending itself more towards data oriented programming, and coders are trending in that direction. This may or may not last, like every trend. But even then, at the moment this tends to still involve using sealed interfaces and records, so you still have some form of instance creation and polymorphism.
How do you avoid factories? Doesn't you code end up littered with worse code?
Thanks for the explanation, very detailed.
> How do you avoid factories? Doesn't you code end up littered with worse code?
Easier for me to use "public abstract class" and then leave open methods inside like "protected abstract doAction();" that are forcefully implemented on each variation of that class.
There is still just one base implementation, I guess the main difference is using strong typed classes that keep the specific code inside specific classes. With factories one tends to end up with a very large source code file that details with too many specific different topics, was making maintenance and testing harder afterwards.
Or maybe I just never really understood properly the value of factories.
Yeah sorry, I don't mean to cause offense but that doesn't make sense. If you've got abstract methods that require implementation in concrete classes, you've got polymorphism, and at some point you're going to be choosing which concrete class to instantiate.
If you always know which concrete class to instantiate and use at each point in the code, it doesn't sound like you need polymorphism in the first place.
Or I could just be missing something.
Usually when I have polymorphism I have some algorithm that operates on an array or graph of mixed instances of BaseClass. For any particular graph I know statically which concrete nodes I want and their arrangement. Factory really only made sense to me if you want to delay the actual creation of the array members, if the decision comes from something external, or if their creation is deeply entangled with their environment in a way you couldn't otherwise avoid repeating.
Fair, that makes sense.
I agree that you can write java any way you want. My point is that the protypical hello world is a cultural artifact representing the cultural ideals of the java language designers. Its symbolic of what they thought was good programming at the time the language was designed. So it says something about both the language design and the culture surounding the language. Or at least it did 20 years ago. That doesn't mean every java program follows that ideal.
the verbosity is a feature not a bug
that's why java programmers are the most productive programmers ever
if you count productivity by lines of code
>How "ugly" a trivial "Hello, World!" does not really matter much and isn't a good indication of anything about the language's ability to handle more than "Hello, World!"
Sure, but for beginner programmers who don't have the discipline down yet, it's unnecessarily hard. I bought a Java programming book as a kid and got stuck because of a typo that produced an error message I couldn't understand. This was the time before StackOverflow and Reddit. In retrospect, this delayed my programming journey by at least a year.
Longer Hello Worlds make frustration and getting stuck like this more likely.
Many of us took programming 101 in Java and so typed this dozens of times without having a clue what it meant.
I learnt C at Uni (after having taught myself BASIC, Z80 machine code (not assembly), and x86 assembly), when we were taught C it was explained to us what all that sort of thing meant. But having said that most of the class failed to understand.
Now we can type out the same semantics, and remain clueless about what it means, but with a new obfuscated syntax which stops us from asking about the semantics.
Still for the better, because each token you don’t have to type when first learning programming is a token you can’t mistype.
(Though the ultimate conclusion of this line of thinking is that programming 101 courses should be taught in as concise and syntax-light a language as possible, giving the learner as few opportunities to screw up the input as possible. I’m a fan of teaching programming in Ruby, personally. Not theory of programming, mind you; just programming as an iterative human process.)
> programming 101 courses should be taught in as concise and syntax-light a language as possible
100% this. To make Java be the all-language makes it a mess without a defined goal. It is better to start learning with a language better suited for it. And then the learner can specialize and expand to other languages. This also helps to create awareness that different languages have different use cases.
Probably not in the least for developers, but it does affect beginners a lot.
I used to teach Java, and the total sum of magic incantations you needed before starting to actually "Hello, world" were an instant turn off for many students.
How to compile a C or C++ program is also a turnoff, right?
I didn't teach intro to C or C++, so I can't compare for certain.
From my recollections as a student, compiling C or C++ in intro classes was just a matter of calling `gcc myprogram.c` or `g++ myprogram.cpp`, followed by `./a.out` for testing, which is rather easy to explain to students who already know what a command-line is.
I think it’s been at least 5 years since I saw a main in the codebase.
Now that I think of it I rarely even write a truly new class from scratch, usually you just implement/extend some framework-specific thing.
It would matter for CLI, but doubt many CLIs are written in Java
Java sometimes has a culture of "the proper way to do this is to take all these little pieces and put them together in a specific way" which probably makes sense for an object oriented purist but is a bit of a drag day to day.
The scanner class is one such thing, but you also have things like wrapping a Reader in a BufferedReader to add buffering, and building a Pattern object to build a Matcher object which has a few different methods you can call to actually do anything useful
It is very OO, but it's also a bit annoying, and more modern java libs tend to give you a more comfortable API. Sadly modern java also tends to come with springboot and people who can't do anything, unless they use springboot
> Sadly modern java also tends to come with springboot and people who can't do anything, unless they use springboot
Spring Boot (and Spring generally) is more of a “Java culture” issue — someone on this thread used the term “framework fetishism” and it’s spot on.
Thankfully there are teams, typically in mobile or polyglot microservices environments, who are moving away from this. But yeah — still far too common.
Before Spring it was JBoss. Awfully slow and bloated frameworks which then become mandatory in enterprises. In the end they all go back to POJO when things really need to work.
It's insignificant for day-to-day programming for experienced developers, but has importance for learners.
Frieren working on projects that last decades. Ya don't say... ;)