Hacker News Reader

Comment by PaulHoule | Hacker News Reader

I love Java.

Why ?

Clean, orthogonal design. Support for metaprogramming in the form of introspection, reflection, compiling bytecode on the fly. Threads that work. Threads that work cross-platform. No GIL. Efficient memory allocation, garbage collection, JIT compiler. When problems are found with Java they get fixed

https://www.cs.tufts.edu/~nr/cs257/archive/bill-pugh/jmm2.pd...

most other programming languages make excuses. Build system with dependency resolution that works (unlike Python) IDEs take advantage of static nature of language. Static nature of language enables refactoring.

Lambda syntax that's probably more concise than your favorite language. Implementation of Lambdas that meshes perfectly with existing practices in Java. All-virtual polymorphism is one of many ways that Java doesn't steal IQ points from you the way C#, C++ and languages like that do.

What about the fact that Java didn't want lambda in the first places, only to hack anonymous inner classes that were never well promoted until 20 years down the road people realize it's quite useful to express logic as functions ? :)

Who cares? Are you a programmer or a historian?

Thing is, they turned it around.

This was a mistake. Actually, Gosling said he was planning to add lambdas but ran out of time.

Some APIs were excessively verbose due to the lack of lambdas, which were emulated using anonymous inner classes.

Interesting, not what I recall (but my readings on this were quick). AFAIK it was carefully not pursued because they wanted to make everything as classes so they went with AIC.

If you have a link, please share.

There might be some better (primary) sources:

Gosling say closures represent the realization of a dream that was postponed in Java's early days and resulted in the invention of inner classes - "an uncomfortable compromise" that failed to provide the desired level of simplification. He notes criticism that closures are too complex, but advises people to read "through all of what Neal has written".

https://www.theregister.com/2008/02/01/java_closures/

I think I read about early java design on c2. I might dig later.

> they wanted to make everything as classes

Java is mostly about interfaces. Classes are just a way to implement them. This is one of the differences between Java and C/C++.

I mean, from your comments I don't expect you to like it, but lambdas are still mostly anonymous classes.

The way lambdas bind to SAM interfaces and implement them is pretty different than say scala or even C/C++ function pointers where the necessary parameter/return type can be encoded into a variables type and referred to directly.

I think that's cool enough but one of the subtle elements of design brilliance was how local variables must be final to be bound into a closure. There's a whole class of ambiguity removed and static guarantees in the face of concurrency that I think goes unappreciated.

I’m not sure whether you mean semantically or in implementation, but from the latter point of view they are rather compiled as static functions and an invokedynamic instruction that will resolve to them at first occurrence.

> I’m not sure whether you mean semantically or in implementation

I'll have to mull over that. I guess to me they seem aligned enough, thats why it feels so elegant. Or maybe I haven't thought about it enough.

> rather compiled as static functions and an invokedynamic instruction that will resolve to them at first occurrence

Yea! but that invokedynamic calls the lambda metafactory which spins up bytecode for a class with 2 things: a) a constructor to bind the values captured from the scope the lambda was declared in to fields, and b) an instance method that feeds those fields to the static function you referred to.

I'd argue that that class is essentially an anonymous class. Maybe I'm easily impressed, but that functional programming <-> OOP duality of lambdas/closures and SAM interfaces always felt profound.

We can get along! There's no need for this feud!

I just wanted to add something I knew on the topic, but you seem to know much more! Thanks for the interesting read, and it is indeed a cool duality!

Inner classes are pretty useful.

This library contains a huge number of Iterables, each of which has at least one Iterator implementation.

https://github.com/paulhoule/pidove

It is convenient to let the Iterator be immutable and the Iterator be an inner class that gets its configuration information out of the Iterable.

(That said, if people really thought seriously about Iterator being a Supplier<Iterable> people might think more rationally about error handling. Also in a slightly parallel universe the Iterator would only have one method since remove() hardly ever gets used and having both hasNext() and next() methods is asking for bugs.)

The issue is that it's anonymous logic recreated above classes. I think it obscures the purpose, making them quite verbose. Unlike FP languages where it's central and a convenient thinking and working tool. With added bonus of currying, it's really a different feel. The few years i had to operate in java it was seldom used and advertised.

Because it came from a very different time, following closely in C++’s OOP madness footsteps.

Slow startup and build times aside, the JVM is a very robust, production-ready environment. Excellent cross-platform support (if we ignore pretty GUIs) and runtime performance within a factor of 3 of C's. There are plenty of open source libraries and the Java ecosystem is massive. The language is safe and garbage collected by default, but you can achieve performance on par with C when you absolutely need to. You can use it for anything short of driver/kernel development. Even the slow start-up time is being fixed with GraalVM. If they can port over some of C#'s syntax improvements, then the language would be perfect. Compared to .Net for example, the JVM is much more well understood.

Graalvm has support for ahead-of-time compilation of JVM languages. They promise "native executables [that] start nearly instantaneously, are smaller, and consume less resources of the same Java application".

This is how things like Babashka (Clojure CLI scripting runtime) are possible [0]

0. https://babashka.org/

Native isn't quite there yet, but once it matures and the potential can be realized, it's going to be pretty cool indeed!

Because it has a VM (portability, multiple languages interact seamlessly, bytecode manipulation at runtime, low compile times), insanely fast GC, best tools in the industry (IDEs, static code analysis, debugger, libraries), and it's still fast enough to write HFT software with it.

It's even possible to compile it ahead of time, making projects like a Clojure CLI scripting runtime with almost instant startup time possible (babashka).

Reply on news.ycombinator.com