This solves the public static void main string args issue.
Still if I need JVM then Scala or Kotlin are still preferable over Java.
Obligatory Java for the Haters in 100 Seconds: https://www.youtube.com/watch?v=m4-HM_sCvtQ
I was/am always glad to pay that tax because non-null-by-default and the vastly superior val/var keyword pairs are totally worth it but it for sure is not a drop-in replacement in team environments. I am already constantly battling the vscoders (to say nothing of vimers) whining that "IJ is too slow for my eeee-leeeet typin'"
That's so 2010. I would avoid Scala like plague. It is a soup of all features imagined and some more. Java is difficult for novice. With Scala even experienced senior devs can look into a snippet and be befuddled. It is designed by academicians who thought clever looking choice is better.
That's just not true. That's the typelevel ecosystem. The official Scala toolkit mostly includes haoyi libraries which is pretty much Python like Scala.
And the foothold in academics has some practical perks, too, like a sound type system (DOT calculus), compatibility guarantees at a theoretical level (TASTy), and what's cooking in the area of capture checking might be a general solution to many of the industry's biggest challenges (e.g. colorless asynchronous programming, safe errors, safe resource management, ... Think of Rust's borrow checker as a special case of this, and the consequences for scala-native as a systems programming platform).
Or maybe we'll all move to Kotlin by then.
Console.WriteLine("Hello, world!") class MyClass {
{
System.out.println("Hello World!");
}
}
(It's also pretty poor style, but occasionally useful in a pinch, like when instantiating an anonymous inner class, which has no constructors that take arguments)
https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals...
I can only think the reason why they did this was to compete with python, as our scripting languages that do not require a main/Main entry point.
Personally, it just feels wrong for compiled-based languages.
I think they could improve on C# with their namespace. Rather, for example, a typical C# file looking like:-
using EFG;
namespace ABC
{
public class XYZ
{
}
}
using EFG;
using namespace ABC;
public class XYZ
{
}
System.out.println("Hello world!");p = print # the print() function
# Now we can do:
p("Hello world")
# endlessly, in this file.
Shorter by 17-odd characters than the above Java version.
println("Hello world!")
It’s okay if you’re only writing a single file, and it really seems intended for beginners or micro applications, but for those of us writing anything besides the most trivial, it’s merely “cute” and just adds inconsistency.
I get gradle is a disaster (but that's more of a poorly managed and evolved DSL problem)
But ... does anyone use Spock and think "groovy sucks"? Yeah, I doubt it.
Spock is also a DSL disaster that's trying to be ScalaTest (https://www.scalatest.org/user_guide/property_based_testing) but in a dynamic language. Every time I use it I have to re-learn the syntax. (I have the same issue with Gradle, so maybe it's just-me?)
A "DSL" like SQL that you use hundreds of times a year you'll learn the model of.
A DSL like groovy that you use once for project setup (and for that you'll one-off it likely and stackoverflow the rest of the question) is not. And it isn't really natural, it's a bunch of arcane steps that at the end might superficially look a bit consistent, but still really isn't.
Groovy really needs an autocompleter or a generator. Or, well, as you say, you stackoverflow for everything outside the very vanilla basics of it.
But good luck getting the right version match to the syntax you need. Christ.
- triple-quote strings / blocks
- minimal class boilerplate (this posting)
- closures (Java closures are worse IMO)
- usable hashbang for UNIX
- I think java has strings in switch now, don't they? Do they have expressions?
WAIT, does Java STILL force you to write getter/setters?
switch on strings is there, as are switch expressions.
records now removes the need for getters in immutable contexts.
Java has the nullsafe operator now and the elvis too, doesn't it?
I don't use the spaceship operator much, implicit sorting works pretty well.
Groovy's closures have a lot less GOTCHAs. They simply work as expected, at least to me. Half the time I use java closures and I get complaints in compilation that I don't get in Groovy, but maybe they've improved closures more.
Groovy's GPars library is the bomb for concurrency/parallelism. I don't know if I could function in normal java constructs.
The .with keyword is a sneaky useful technique where you can declare a piece of data like:
"some cli command" .with { it.execute} .with { /* parse output */ }
It allows chained calls that flow naturally. Groovy generally allows pretty compact flowed calls which makes scripts a lot easier.
Groovy scripting with implicit vars is a lot easier than any java scripting, even with the "simplification" described.
The shorthand access/navigation of nested lists and maps, and the map / list literals (also taken by java at some point I think) are really nice to have. Also a + operator for lists and maps I use a lot
Groovy's ability to generically call methods without mucking through 10 lines of reflection is sometimes nice.
The auto-gen of getter/setters is a must have, I think Kotlin has those too?
CompileStatic lets me selectively use full java speed without groovy overhead.
In general, I like Groovy because it is typing-optional. Python and Javascript suck because they don't really have optional type enforcement. Java sometimes asks for too much typing. Groovy lets me select as needed.
The actual sane = for string assignment and == for sane string comparison is nice.
But honestly, Java with the listed features is a lot better. I'll probably still use groovy for doing what would normally done with bash (UGH) since I have a big CLI/scripting library base that handles argument parsing, json, encode/decode, encrypt/decrypt, zip/unzip, in nice compact syntax.
Groovy is basically a dead language now anyway. The world is overrun by JavaScript and Python, and AI looms to replace us all with horrid AI python or javascript glue code.
Don’t forget traits! When are we getting traits in Java? Probably never.
Optional semicolons and parentheses to cut the line noise and enable internal DSLs.
Though Java has improved implicit typing with `var` and now we have reasonable lambdas, Java is still not a high-level language, but maybe it is now medium-high.
Well, yeah? Java's explicit strategy for the last few decades is to let other languages experiment, then implement the ideas that worked out once the dust has settled.
Given these are still methods of classes this JEP seems pointless to me. Not having to write class x {} isn't a great time saver.
Compare that with Kotlin where you have top-level functions, so `main` is just like any other function.
It's better to just say "we will come to this concept later", rather than make a fake syntax that does this (taken from the JEP) behind the scenes:
new Object() { // the implicit class's body }.main();
It adds more confusion, as you are left explaining that you could not really run an instance method without instantiating the class -- it was just something fake for beginners.
https://openjdk.org/jeps/463
Finally solves the inscrutable Hello World program!
Yes, it's just ergonomics for early beginners. But could be the difference in whether or not someone new to programming sticks with Java or not.