4 ms·
I stated the problem with citing that research when trying to appeal to people familiar with Haskell-like type systems (as in the linked blog post). My real po
by mej10 12y ago
I stated the problem with citing that research when trying to appeal to people familiar with Haskell-like type systems (as in the linked blog post).
My real point is that you can't really draw strong conclusions from this research when talking about type systems in general. If you wanted to say "It doesn't seem like type systems like Java's improve productivity" then I wouldn't have any issues, and would probably even agree.
> You sound like a stuck-up jerk rather than a thoughtful person.
I will agree that I phrased what I said a little harshly, but damn.
- AnimalMuppet 12y agoOK, now you sound like a thoughtful person that I can actually have a conversation with. And I probably responded a bit overly harshly, too. But I keep seeing this "Java's type system is essentially worthless" idea, tossed off glibly as if it was God's own truth, and I've never seen a justification for it. I get that it's not Hinley-Milner. I get that it doesn't have higher-kinded types. Why does that make Java's type system worthless?
- zak_mc_kracken 12y agoObviously, it's not worthless, that's just hyperbole, but it's sad to see people who would probably be the first to say that they are reasonable, evidence-based, pragmatic computer engineers fall into the manichaean trap that is extremism: either something sucks (Java) or it's awesome (Haskell). The truth is that Java's type system is a bit in-between. It's a reasonable type system that's tractable for a huge portion of the developer community (hence its success) but which falls short of some required qualities to be able to show proofs by applying the Curry-Howard isomorphism.
- rntz 12y agoAs a type system, purely formally speaking, Java is... well, it's just kind of OK. It has parametric polymorphism. It gets subtyping & co-/contra-variance right -- for generic types only, not arrays, and requires explicit annotations ("extends", "super"). It can express higher-order functions. Its primary formal weakness compared with, say, Haskell98 or SML, is the lack of higher-kinded types (ignoring for the moment the issue of Haskell-style typeclasses or ML-style modules & functors), which is a pretty big weakness but not a game-killer (see: Rust, Elm). But pragmatically, it's a pain in the ass to work with. (Possibly this has improved since I worked with it. I hope it has!) It has a weird "everything must be an object" view of the world; it requires a file for every type I wish to define (barring nested classes, and anonymous classes - the latter of which is a notable but late improvement). Expressing HOFs is possible, but very unpleasant (AIUI it's gotten better lately). And just to top it all off, it doesn't have type inference, which just makes everything a chore. The way I see it, Java is playing catch-up with the innovations introduced by more forward-thinking languages. It seems doomed to being forever a middle-of-the-road language. Which is... well, it's just kind of OK. But it's not gonna inspire devotion, and people who worked with it when it really did suck (perhaps it still does, I dunno) are gonna remember that and hate it.
- AnimalMuppet 12y agoThanks for the answer. But could you clarify something for me? What's the difference between higher-order functions and higher-kinded types? And, yeah, Java's type system... I'm not going to claim enthusiasm, merely that it seemed adequate for what I wanted it to do.
- dragonwriter 12y ago> But could you clarify something for me? What's the difference between higher-order functions and higher-kinded types? roughly, the relation is: (type constructor):(simple function)::(higher-kinded type):(higher-order function) That is, a higher-kinded type is a type which takes a type constructor as one of its parameters, in the same way that a higher-order function is a function that takes a function as one of its parameters.