Hacker News Reader

Comment by HdS84 | Hacker News Reader

As a C# Developer who occasionally uses Java I understand the sentiment. Java just feels dated. You have to do a lot by hand which should be done by the language. And new features like streams are just a bad riff of .NET Linq, which is much better in ergonomics. Finally, Generics are a big turn off, who ever thought that the Java implementation is a good idea was delusional.

View on HN

Java streams have some advantages over C# Linq.

IMHO, there's a more fundamental concept that everybody seems to be missing, which is that general purpose programming languages somehow fail at general purpose queries across trival, in-memory data structures.

A random example I like to bring up is: Can your LINQ-equivalent efficiently and idiomatically calculate both the "min" and "max" of a list without enumerating it twice?

Imagine you're writing some abstract library that can take any IEnumerable as the input(s). Will it scan a 1TB database table twice because the idiomatic coding style is:

    var min = somelist.min();
    var max = somelist.max();

This is such as basic, trivial example, yet C#, Java, Kotlin, etc... languages just fall flat on their face. Meanwhile, in SQL, a 48-year-old query language:

    SELECT min(...), max(...) FROM sometable

But this is just scratching the surface. Ideally, all LINQ-style data inputs should be treated as something like a B-Tree index. Something that can be "walked" (not just enumerated!) efficiently using prefixes, ranges, and similar conditionals. Multiple queries should be able share such as "walk" to minimise the cost of streaming data in from memory... or wherever. Data should be partitioned across CPU cores just as efficiently, and the query language should make this natural.

I'm yet to see a language that scratches this itch.

Well, you can calculate min and max simultaneously with a reduce, but I do get your general point.

Can you honestly tell me any usage of reified generics outside of perhaps ArrayList<int> possibly having another more performant implementation?

The amount of time I’ve seen it complained about, yet in practice I am very seldom hit by that (just a note, Haskell also erases every type yet it doesn’t bother anyone there).

The post gives an example - overloading a method based on the type parameter (e.g separate overloads for Option<Integer> and Option<Double>). This is why Java's generic erasure is more of a problem than Haskell's type erasure: Java erases generic parameters at compile time, whereas Haskell retains type information for long enough to use it when linking modules.

On the other hand Java's generics made it easier for Clojure to be developed.

Can you say more about this? My first thought is that you're talking about the various data types in Clojure being implemented with Java interfaces. But my understanding is (I'm not a Java developer) that interfaces existed pre generics, just without static type checking support, and thus Clojure could have been developed with a pre-generics Java version just fine?

Reply on news.ycombinator.com