Hacker News new | comments | show | ask | jobs | submit login

> Now when I go back to Java I often get frustrated and the amount of code I have to write simply to work around the fact that functions are not first class objects.

Frankly, I've mostly gotten over Java's lack of first-class functions and just make do with the boilerplate involved with regular for-loops or with anonymous implementations of interfaces that are just stand-ins for functions, etc. What I really struggle with nowadays is Java's (relative to Haskell's) weak type system. I'm only a novice Haskell programmer, but even so I miss things like Maybe, Either, tuples, etc, which can be really painful to work around the lack of in Java. I've realized I would rather work in a dynamically typed language or a strong statically typed language than the wretched mess that is Java.

Remember, Maybe and Either are not language features in Haskell, but rather library features! Java is totally capable of hosting them. (Though, there isn't any special syntax for tuples in Java).

But if you implemented Maybe in Java, there still wouldn't be any compile-time guarantee that Nothing would be handled, right? At best you'd have something in code that more strongly encourages a certain convention.

Just now I briefly looked at implementations of Maybe in Java and at least one of them fakes this with checked exceptions, while another seems to lean heavily on Guava's Function interface, which is just awkward to use. I'd certainly be interested in seeing alternative implementations, if you know of any that are decent.

Also, a maybe more serious issue is that since it's not idiomatic Java you'd have to do a lot of wrapping around libraries, and hard-selling to colleagues. Admittedly no longer dealing with flaws in Java's type system, but a big part of a language is the community and ecosystem, and in Haskell's case people using it have already bought on to the advantages of stronger types.

There's also no compiletime guarantee that Nothing is handled in Haskell; there are plenty of unsafe partial functions. In a non-total language, you unfortunately have to avoid partial functions without help from the compiler.

You're quite right that programming with these kinds of types in Java introduces you to a whole new kind of Hell! I'm not sure I'd recommend it.

However, I'm simply pointing out that types like these are _not_ language features. Some languages may be better suited to them than others, but they are definitely library features, and had best not be considered otherwise.

Yes, but without pattern matching and a do-like syntax sugaring they are close to useless, unfortunately.

> Java is totally capable of hosting them.

No, because your Maybe or Either reference may still be null, so you get "Maybe fuck you" and "Either fuck you, or fuck you". That's the first part.

The second part is, due to the lack of match completeness check (or more generally match) and the shitty type system, APIs forcing developers to safely unwrap or rewrap values are... shitty.

Whilst you're mostly right about the second bit, your first complaint really isn't valid, since in Haskell, every value is basically "My Type + Fuck You" (because codata isn't distinguished from data).

fuckYou :: a

fuckYou = fuckYou

justTrolling = Just fuckYou

That said, however, I'm very sympathetic to the rejection of non-total languages. But we must note that even though Haskell is inconsistent as a logic, it is still able to derive tolerable advantage from the use of option types, etc.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact