Took the industy a decade or two to arrive at typed languages that were an actually good subset of C++ features. Java, in my opinion, wasn't one.
public static void main(String... args)
When they start with the old style there is an overload of concepts where the teacher just have to say "ignore all this", which is not ideal. With new style they grasp fewer concepts at first.
I'm not truly convinced this is such a big deal, but I lived through my university switching from Pascal to Java in the first programming class, and I can confirm people did get much more confused during the first few classes (to be fair they got way less confused later not having to deal with pointers tho).
"public static void main (String[] args)" teaches A LOT if one takes the time to inquiry about every keyword in there.
> 1: When I was a Freshman in High School I asked a Junior what it meant. He had no clue.
OK... so it's confusing for juniors. A lot of stuff is. I probably didn't know what it all meant when I started either, but so what? You copy and paste it and move on. Eventually it makes sense. Not a big deal.
This (and IO) was also one of the reasons for which my students tended to like OCaml much better than Java.
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.
But if you teach people using Java, you have to teach them to write this:
public class Main {
public static void main(String[] args) {
System.out.println("Hello world");
}
}
print "Hello world"
I don't like Java, and the excessive boilerplate is a big part of that opinion. But it was never nearly as arcane as some people here are making 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.
As much as C++ has a lot of problems, them and other languages (python/ruby/etc) never denied that the procedural world existed, while Java wants to blindfold you and push you through a corridor until you get out of it and into the "perfect (not) OOP world"
If you're speaking of `__main()`-style entry point, though, you're right, and Java makes it... complicated.
Interestingly, those two languages use very different mechanisms for top-level functions - although I’m not sure if there’s a significant difference in practice.
Python has true standalone functions, whereas in Ruby’s they’re really methods of a `main` object.
And yeah, it was pretty cool looking back on it later and realising I knew what it all meant!
And yeah, good riddance nonetheless!
The answer is: infinitely much. You could have to write each character in strings as separate characters for example. It would be absolute utter madness but it "would make sense later".
(I somehow mostly avoided learning Java, and my last passing contact with it was 20+ years ago, so these are honest questions).
The main function can be written with `String[] args` if you need it.
This is a decent summary of the changes:
https://www.happycoders.eu/java/main-method/
Further details:
Thus, many sub-optimal project coordination approaches ended up fighting the design patterns. Java is a good student language, but there are so many better options now... with fewer footguns, and without Oracles farts. =3
Pulling the oracle card when java is mentioned is a useless stunt.
As much as I love hating Oracle, they pushed the language forward much more than Sun ever did.
BufferedReader in = new BufferedReader(new InputStreamReader(System.in));
String input = in.readLine();How does it affect you this change day to day?
Released in Java 21
It would make Java a much better language in my eyes if it allowed package-level methods, or even multiple records/classes per file. But apparently "impact on how Java code is written in general" is not wanted.
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.
If you can't have other top-level functions in Java, then it's a special case, which is ugly.
Decompiled example: https://lab.razor.fyi/#41rAyMUVUJSfXpSYq5dcLDSRsbQ4My9dIbiyu...
> lipstick on a pig's turd
There are several valuable compiler transformations that happen under the hood in languages like this. Closures as types, iterator/generator functions, async state machines. This is just another example.
I assumed this meant that you could have free functions, but you're saying you can ONLY have `main` as a free function? Ok, then I agree this is also garbage.
```Top-level members are interpreted as members of the unnamed class, so we can also write the program as:
String greeting() { return "Hello, World!"; }
void main() { System.out.println(greeting()); }```
I write "return 0" at the end of main in all my programs if that end is reachable.
Btw: in the compact example! The IO class is implicitly imported, so that example truly works without any import at all!
Or, to put that another way: import statements aren’t pure boilerplate that should be thrown away; they encode real information (ambiguous symbol resolutions); and so, by eliding them from code examples, you’re discarding that information and forcing the learner to re-derive it.
Which is especially bad when your code examples are referencing ambiguous undocumented static inner classes nested deep inside your library’s package namespace, where all the potential resolutions differ only by the particular package they exist in (since they’re all e.g. essentially batteries-included extensions of the base library implementing the same interface.) And where all this structure is as ugly as it is precisely because you didn’t expect the end-user of the library to need to understand it / interact with it. Yet your own [usually “advanced” or “feature demonstrating”] code examples force exactly that.
C# does this well by letting you OOPfy your other code but doesn’t require you to use OOP for this monstrosity.
I wouldn't consider OO the way Ruby and other actually well designed languages do it flawed.
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 think this is the exact audience for this change: for newbies in day 1 of 10 years in their programming journey. Less boilerplate to just swallow, less time spent debugging an otherwise-fine lab exercise if not for the wrong instantiation of Scanner, more time actually focusing on the basics they should be focusing on.
Granted, I still think Java is a horrible first language to learn from or teach with but this is a step in the right direction. Might revisit this opinion in a few years, who knows.
Oh also, we use Java in production so we also have a bunch of ad-hoc "scripts" written in Java for mostly one-off interactions. Nonetheless, these scripts can get unwieldy fast. You'd think I'm exaggerating the benefit here but I, for one, welcome one less level of indentation in these scripts.
Fwiw, other JVM languages like SCALA have already done this exact thing way before. But whatever, it isn't either good or bad. And I can still use the old way out of respect for tradition.
To each their own
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.
I also remember casts all over the place in Java because polymorphism wasn't OOP enough.
And then lambdas and functions were not OOP enough to be first class values and that's why we needed numerous "verb-classes" everywhere.
And of course printf() is not OOP enough...
I dont find Java's first versions well designed. The JVM was quite well designed, but the language not.
And changing a popular language is hard. I think Java's dev do it very well (the process of changing it IS "well designed"). But still the language itself suffers a lot from the bad choices in the beginning.
I like Kotlin: an OO language with as much FP in there as makes sense for an OO language.
What's now permitted is:
1. a simpler way of declaring a main method on a class -- you don't need the public or static, and the args is optional, so you can declare a `void main() { ... }` method on a constructable class;
2. declaring a main function (and other variables/functions) outside of a class -- here, the startup code will handle calling the main function, although I don't think the ability to call anonymous functions currently extends outside of the main function/file.
Java 5 (2004) [code sample from the article]:
public class Main {
public static void main(String[] args) {
Scanner scanner = new Scanner(System.in);
System.out.print("What is your name? ");
String name = scanner.nextLine();
System.out.println("Hello, " + name);
}
}
object Main extends App {
val name = readLine("What is your name? ")
println(s"Hello, $name")
}
val name = readLine("What is your name? ")
println(s"Hello, $name")
void main() {
var name = IO.readln("What is your name? ");
IO.println("Hello, " + name);
}and out came in Spanish:
"Secuencia pública de la cañería del vacío de los parásitos atmosféricos"
(Public Sequence of the Vacuum Pipe of Atmospheric Parasites)
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!"
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.
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.
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.
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.
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
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.
For the longest time Java had been very keen to be explicit, to the point of needing a log of cruft where it just felt like the compiler was checking you spelt every letter of the incantation correctly because both the compiler and you knew unambiguously what simple thing you were trying to achieve. But this tone changed in Java around the time the new entrants like Kotlin started taking over as what you develop in in a way that scala and clojure never managed. And suddenly all the get-out-of-your-way of lambdas saving you typing out classes and anonymous classes arrived and Java became a much nicer experience imo.
No reason apart from the framework epidemic that's supposed to make things easier for developers, but in the end hamstrings them and weighs everything down.
(to the downvoters - I am a java developer and this is very real to me at the moment!)
On my university no one got Sun's marketing money in 1998, yet the distributed systems, compilers design, and graphics programming, all adopted Java as the language for new teaching materials, as it sorted out several problem with the assignments.
Also of course the misuse and overuse of classes when designing systems, but the complexity at design time is also the counterpart of the ease of use of well designed APIs. I remember using an IDE to write some code and it skipped the whole documentation and run/compile error phase, I could just cast mismatching types as needed.
Probably C# and Swift/Objective C would only be above Java as top languages, being actually funded by paying customers instead of used by companies that depend on volunteer developed open source software and end-users that equate paying for software with evilness.
For a very long time it completely stagnated and all the features we see added now should've been there 10 years ago, at least, and a bunch of other improvements on top. All because "our goal isn't to adopt the strategy of less successful products, but to forge our own" which now turned into busily adopting all the features that the "less successful products" have had for years: https://news.ycombinator.com/item?id=28985688
Java choose to adopt object oriented purity in a very weird way. Sun has initially rejected the idea of standalone functions (static import was introduced in Java 5, closures in Java 8 and compact source files/instance main is only coming now). Even with static imports and compact source files, there is still a class holding these methods behind the scenes (for practical and compatibility reasons, more than to achieve any ideological or theoretical goals at this point). That seems like Sun was trying to keep the purity of "everything is an object", but at the same time they've introduced primitive values, which are clearly not objects. This was a pretty bad decision in my opinion. There is no practical benefit from requiring every function to be defined inside a class[1]. On the other hand, being able to have methods defined on an integer is a pretty nice feature.
If we look at a Smalltalk, which is generally considered be an example of a "pure" OOP language, we see a striking difference. This is Hello World in Smalltalk:
'Hello, world!' printNl
[1] https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
We even have design patterns like Command, to workaround first class functions in "pure" OOPy way.
And for enterprise software development, I like it that way. It can make up a definition it wants and stick to it. I think it is better for a language's ecosystem and culture to have one dominant paradigm than becoming kitchen sink of programming languages.
Edit: added a link
[1] softwareengineering.stackexchange.com/questions/264697/alan-kay-the-big-idea-is-messaging
Please show an example.
You can just say initially e.g. when I learned C++ that "#include <iostream>" can be "mostly ignored for now, but just know iostream stands for Input / Output stream, and this line is necessary to e.g. output with std::cout"; and there are no scars left from this.
[1]: https://steve-yegge.blogspot.com/2006/03/execution-in-kingdo...
It's just syntactic sugar.
It's somewhat implicit in the JVM spec, but functions are always bound to classes as methods. [2] The only kinds of heap objects you can have a reference to are class instances and arrays. [3]
The lack of free functions is really only a minor inconvenience for language implementers. Clojure, for instance, just compiles new classes to hold functions as methods.
From a programmer's perspective, you can write lambdas, but again, it's just syntactic sugar over an inner class.
[1] https://www.happycoders.eu/java/main-method/ [2] https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-4.h... [3] https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.h...
I'm visibly shaking at this statement. What are you even saying here? A function is the most basic, fundamental unit of code organization. What Java does with its forced classes is a complete perversion of computation, sanity and anything reasonable.
The same things people use free functions for in any other programming language.
if __name__ == '__main__':
sys.exit (main (sys.argv))
# myapp/app.py
def main():
print('Hello!')
[project.scripts]
app = "myapp.app:main"
if __name__ == '__main__':
main()
This looks like a hack just for the main file, it would have been good if these functions can be called from other files.
The IO class is good. The rest is information hiding. Now if you could write anything else in Java in this form,it would make sense.
Or, Ruby is a cute (mostly subset of) Perl.
And after some Kotlin I must say: Kotlin is an acceptable "Ruby with static types".
As we become more and more acquainted with programming, a lot of what we do why we do it is incoherent nonsense to a beginner, but important nonetheless.
The limit is actually your time and effort. But nobody likes to write optimal assembly by hand, the balance has to be struck somewhere.
You can't really escape String[], which imo is fine. It's better than argv/argc in C at least.
Each invocation of the jvm requires that you specify the class for which a single static main exists. The other classes containing other static mains are irrelevant.
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.
Depends on the use-case, but I also like Elixir/Erlang, Julia, and Go.
Not all are very popular, yet each offer something uniquely beautiful. =3
(One might argue Go comes close, though)
Javas selling point is that it can do everything reasonably well and has a huge talent pool.
part of my dislike is probably that I'm a math person, and the lack of operator overloading really makes any math not using the built-in types dreadful to read.
(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.)
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.
The only reason Java is still somewhat relevant is ironically Android/Kotlin, and SAP/heinous-dual-stack-blobs product lines.
Best regards, =3
Java/JVM is literally everywhere. And let me get this clear: not a fan of both java-the-language and java-the-culture.
Most Enterprise level Java I saw was not clean OOP, but rather a heinous kludge sitting next to a half-baked design pattern. The 3.6B Android OS users in the world probably are more relevant in terms of development projects, and keeping your team staffed. Good luck =3
>high--frequency trading systems
Probably not the Java stack itself, given GC latency and precision timing skew would translate into millions of lost dollars a second. However, people do silly things in the wrong languages all the time. =3
Do you actually use that option at enterprise scale? =3
It’s much better than ideal.
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?
> 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.
that's why java programmers are the most productive programmers ever
if you count productivity by lines of code
Both awt and then Swing were pretty bad for anything beyond toy programs, though.
Which is what the respective department was doing before.
Swing is great, it does suffer from bad defaults though.
Anyone serious about it, would be getting books like Filthy Rich Client, and additional libraries like JGoodies.
Granted, they only came to be around Java 1.4 timeframe.
Swing was nice to program, but had sluggish reaction time and more than a few bugs (speaking of Swing 0.9/1.0, never went much further).
Besides, what is "clean OOP" even?
Thus, people that actually leveraged the OO paradigm properly, and in a way that may be sustainably regression-tested/maintained over many continuous integration cycles. That kind of "clean" code tree usually only needs juniors to study around <5 files to understand even the most complex modules operation, helps mitigate bugs, and team-leads can weed out quality "issues" in minutes.
People that churn teams usually discover a YOLO and OO paradigm are fundamentally incompatible concepts. People won't know everything they need in the first release, and they will have stuff they don't need but now have to live with by the third release.
This is not a Java specific problem... but it does make it easy.
Nothing integration "teams" do will likely matter much compared to a 3.6B user-base policy change. Have a great day =3
"Nor would a wise man, seeing that he was in a hole, go to work and blindly dig it deeper..." ( The Washington Post dated 25 October 1911 )
Everything beyond 8 has been nice to have but 8 was the big one.
(I'll ignore Kotlin... I don't get why people like it.)
Fast forward to around 2020 and I had to organize a team to build search engine in JVM. Given how hard it is to find decent Scala developer I surrendered and did this project in Kotlin. Java devs easily pick up and write sensibly FP-style even code, and builtin coroutines are cool. Even though I had to open up the internals of coroutines to get tracing to work they felt a very welcome change compared to say monadic explicit async.
So for me Kotlin is kind of watered down Scala for typical Java folks and I could tolerate it compared to perspective of writing plain Java.
Heh, I once had to work in a code base that used an `Integer premiumDefenseLevel`. It contained the level of premium defense a player had purchased, or null if the player didn't have any levels of premium defense purchased in the recent times.
This was in fact annoying to remove, because a 0 after a 1 was treated differently than a null some time for advertisement reasons: Someone who had bought premium defense in the past is more likely to re-buy than someone who didn't, so they are pestered with ads. But it eventually turned into a neat little domain object.
That's a deal-breaker. If you can't tie together a few values in a record/struct without being forced to box them/heap allocate them, the language will never be used anywhere where you even remotely care about performance.
This is not a difficult problem to solve - C# did it in a very elegant way with structs, and as a direct result, probably for half of all videogames written today, the gameplay portion is written in C#.
Tend to deprecate Java services for a number of other reasons =3
It did look weird, of course, but they're also using Go (which iiuc has worse GC latency) or other garbage-collected languages (OCaml being a famous example).
I guess it is like using a Fiat Coupe as a gravel dump-truck. lol =3
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.