Hacker News Reader

Comment by cfontes | Hacker News Reader

Could you define good?

Java's way of expressing variance is really awkward (even quite popular libraries get their types wrong as a result), arrays are special-cased into unsoundness, Serializable is a total mess where it could be a perfect example of how to use a type system, there are no higher kinds, the exception system is like a second parallel type system (it even has union types, which would be incredibly useful if you could use them in the rest of the language). More than that, the standard library doesn't really use the type system to its full effect, e.g. errors in JDBC are C-style numeric codes, Comparable returns an int for what should be a 3-value enum.

(To answer your question, a type system should be sound unless and until the user explicitly requests otherwise, easy to use, but above all consistent)

Besides null being a potential type for any reference and causing a ton of issues I do not think most Java programmers regularly care about the lack of abstractions like higher-kinded or union types. Would be nice to have, but never have I felt like I needed them.

Enum types didn't exist in Java when the Comparable interface was implemented. That's why some API's look old-school by comparison because newer language features didn't exist yet.

> I do not think most Java programmers regularly care about the lack of abstractions like higher-kinded or union types. Would be nice to have, but never have I felt like I needed them.

That could be stated about pretty much every feature added since Java 1 really, it's not like the blub paradox has disappeared from our reality. How do you know that you wanted union types when you've never used a language which had them (and had features hindering such a conceptualisation, C-style enums are not really helpful there, even less so when extended the way Java did)

> I do not think most Java programmers regularly care about the lack of abstractions like higher-kinded or union types. Would be nice to have, but never have I felt like I needed them.

My counterargument would be the popularity of annotation-based libraries in Java. An annotation is basically a place where the official type system has proven inadequate.

That's not entirely true, part of annotation's use case is metasyntactic: codegen, code analysis and just plain structured/extractable comments.

For an eye-opening experience, walk through the tour of Ceylon sometime. It has the most sophisticated implementation union & intersection types I've yet seen:

http://ceylon-lang.org/documentation/1.1/tour/types/

Compared to union/intersection types, I find myself craving higher kinded types less frequently. I do feel the absence strongly, however, when I'm writing tools. I think the lack of higher kinded types manifests in the Java community as inferior libraries (eg ORMs) that require more manual-feeding of information via annotations or extra parameters to methods.

> I do not think most Java programmers regularly care about the lack of abstractions like higher-kinded or union types.

When you become used to a given language, you start to reason in its terms. A programmer who is used to Java is used to its shortcomings and will not miss Lisp macros or dynamic types.

> Comparable returns an int for what should be a 3-value enum.

To be fair, I can think of another functional language starting with "O" guilty of exactly the same thing...

I was about to refute your argument by proposing creating a union type. Here is a relevant reference: https://realworldocaml.org/v1/en/html/functors.html

(This idiom is a bit of a historical error. It would be better if compare returned a variant with three cases for less than, greater than, and equal. But it's a well-established idiom at this point, and unlikely to change.)

Eiffel is similar to ocaml : http://www.infor.uva.es/~felix/referencia_smart_eiffel/libra...

Does anyone know the advantages of the above signature over the Haskell alternative? Because this seems to be more obvious and easier to read. So there are more than one language guilty of using a ternary operator for compare.

Haskell does define the appropriate constructors, rightly so: https://hackage.haskell.org/package/base-4.8.1.0/docs/Data-O...

data Ordering :: *

Constructors LT EQ GT

> Does anyone know the advantages of the above signature over the Haskell alternative?

Historical reasons, mostly. The only practical advantage I can imagine is that it's a bit shorter to implement a reverse comparison, since you just multiply by -1.

Reply on news.ycombinator.com