I remember when first learning Java in 1995, and already being familiar with OOP from C++, I found it curious that such an OOP-focused language didn’t represent a program 1:1 as an object instantiated and initialized at load time, with a main/run method invoked on it to start execution. The choice of having main() be static was made even weirder by its still having to be defined within a class. Then if you’d want to have your application be an object, you’d have to do the extra `new MyApp(args).run()` bit manually, and have run() be the “real” main method. It all seemed very backwards.
Paving the on-ramp to Java
121–130 of 156 posts
Re: Paving the on-ramp to Java
#122When i read the title, I thought they were finally going to fix gradle or improve maven. Those are the real on-ramps and they are a much bigger barrier to entry than main(). A cleaner/simpler alternative was Kobalt, but it’s now abandoned. A simple, official build tool would make the ecosystem easier to learn. https://github.com/cbeust/kobalt
There are a bunch of different problems better described as "off-cliffs" than on-ramps; initial syntax / conceptual complexity is one, build systems are another. Not that other ecosystems are necessarily better. Modern web dev is pretty damn confusing for beginners as well. I helped an ex-girlfriend as she went through a coding bootcamp. Very little of the material stuck and it wasn't her fault. The whole stack is ju…
> Even if they stick with Java and try to learn jpackage they quickly realize they need Windows, and a Mac, and maybe Linux just to make packages that their friends can run at all
And when they test it on Windows they'll realize that the launcher that jpackage creates does something weird on startup (possibly involving relaunching itself? [1]) that makes Windows display a busy cursor for a while after the program has launched, so they'll have to forget about jpackage and redo it all with something like Packr [2] and Wix# [3]...
[1] https://github.com/openjdk/jdk/blob/fe45835f7cebfccd4544ae19...
Re: Paving the on-ramp to Java
#123I am amused by this: > Worse, the early exposure to static methods will turn out to be a bad habit that must be later unlearned. I have been using Java since 1.0 and it is my default language. I am writing Java code today. I write functions using ‘static’ all the time. I prefer that a function be static. It shows that it does not depend on state of the enclosing object. Using ‘static’ on methods is not a bad habit. H…
So many creational design patterns rely on static factory methods too.
I'm not really sure what they're on about.
Re: Paving the on-ramp to Java
#124Earlier quoted context omitted.
I always find it funny when people bring up Kotlin in the context of Java's evolution. It's not one of Java's main competitors, and while Java has borrowed many features from other languages [1], to date it has not adopted a single feature from Kotlin [2]. In fact, almost at every turn -- from data classes, through async/await, to string interpolation (JEP 430) -- Java has opted for a different approach. Is Kotlin th…
> Is Kotlin the only other language they know? On the JVM: I'd say yes. Scala, Groovy, Jython, JRuby, and what not came and went. I'd say Clojure is the third, and it take a nice place in the design space. But Kotlin to me is so close to Java that it is basically Java 2.0: the Java that Java cannot be due to intended organizational slowness. > Python is one of Java's main competitors, and when it comes to teaching a…
> the Java that Java cannot be due to intended organizational slowness.
When Java was created in the '90s, James Gosling said that it is intended to be a slow-evolving conservative language that will only pick features from other languages once they have been sufficiently proven to be worth it. We try to live up to that goal and be a last-mover. It's not organisational slowness but conservatism in design that has worked very well for Java. Java will never adopt many if not most of the features Kotlin has, because most features never prove themselves as particularly beneficial over time, and because we try to make the language as minimal as possible, because it's intended for a very wide audience, and, in general, most programmers prefer languages with fewer features to languages with more features.
I'd say Kotlin was Java 2.0 ten to five years ago, but now it's a language that's going in a different direction from Java's.
> The changes outlines in the article are not going to help here I'm afraid.
Not alone, but this is just the beginning.
Re: Paving the on-ramp to Java
#125I have long considered that having to have the class definition explicit in the file is redundant, especially as the 2 have to have the same name anyway. Obviously if you need to `extend` or `implement` then an explicit declaration is needed. But otherwise, just defaulting to the file base name is more than sufficient.
Groovy does a good job with this type of thing.
Edit: but a bad job at a lot of other things.
Re: Paving the on-ramp to Java
#126Earlier quoted context omitted.
Static methods should be treated like functions. Same input same output. Keep them small. If you find yourself needing to mock them they are doing too much.
But even here you’re testing the same code twice. One directly with the tests for the class the static methods live in and once accidentally when you test the class that includes the util class as a dependency. This situation can be fixed by replacing the static methods with Functions.
> But even here you’re testing the same code twice
So what? How is that a problem?
Re: Paving the on-ramp to Java
#127I am amused by this: > Worse, the early exposure to static methods will turn out to be a bad habit that must be later unlearned. I have been using Java since 1.0 and it is my default language. I am writing Java code today. I write functions using ‘static’ all the time. I prefer that a function be static. It shows that it does not depend on state of the enclosing object. Using ‘static’ on methods is not a bad habit. H…
static should be removed from Java. static is bad, not always but because it can be misused and because it makes debugging more difficult and most important of all, it makes testing impossible and PowerMock is to be avoided at all costs.
Right, methods that call Math.min() are literally untestable without PowerMock.
Re: Paving the on-ramp to Java
#128Applause! However, it's not always about "saving keystrokes"... it's about lowering accidental complexity and making code easier to reason about by requiring less cognitive load on the reader. Another example: the lack of literals for collections in Java. Imagine this: Map x = {"a": "A", "b": "B"}; // not Java vs: Map x = new java.util.HashMap(); x.put("a", "A"); x.put("b", "B"); The first case is more declarative, a…
Java is deliberately nudging you not to do things like that. It would rather you create a class with fields a and b -- which has its own verbosity, though they've improved it. I find that I use structures like that primarily when interfacing with other loosely-typed languages, like Javascript, which do encourage you to create structures on the fly like that. Impedance mismatch is always a pain, no matter where it occ…
Unit tests very frequently need Map declarations like that.
Re: Paving the on-ramp to Java
#129Earlier quoted context omitted.
> Otherwise everybody complains about Java boilerplate. Do serious people actually complain about this often? I think it's more of a drive-by comment from people who don't like Java for whatever other reasons.
I wrote a lot of Java in the 2000's and the early 2010's. The verbosity of the language was always my #1 complaint. The amount of stuff I had to type vs the productivity of those lines was always out of whack. Maybe it's better now?
Requiring fewer lines for Hello World doesn't really change that though.
Re: Paving the on-ramp to Java
#130When i read the title, I thought they were finally going to fix gradle or improve maven. Those are the real on-ramps and they are a much bigger barrier to entry than main(). A cleaner/simpler alternative was Kobalt, but it’s now abandoned. A simple, official build tool would make the ecosystem easier to learn. https://github.com/cbeust/kobalt
Maybe you will appreciate https://github.com/sormuras/bach/ ?