4 ms·

Before even loading up the papers I knew they'd be using some horseshit type system like Java's.

rbehrends 12y ago
The programming tasks did not require complex data structures (such as a scanner and parser), so one would not expect Java's type system to be a limiting factor.
- mej10 12y ago
  This comment alone is enough to make Haskellers (or other proponents of good type systems) not take this seriously. Anything trying to cast broad strokes about the usefulness and effectiveness of type systems can't use a language with a type system like Java's.
  - AnimalMuppet 12y ago
    And your comment is enough to make people not take you seriously. You sound like a stuck-up jerk rather than a thoughtful person. Perhaps you could explain exactly what it is about Java's type system that makes it not worth even discussing. That would be a comment that was actually useful. (And don't say something like "because Java doesn't have higher-kinded types". We know that it doesn't. What about that lack makes it not even worth discussing?)
    - 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 ago
        OK, 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 ago
        Obviously, 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 ago
        As 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.
- rntz 12y ago
  Parsing, at least, absolutely can benefit from a powerful type system: consider Haskell's Parsec library, which uses monads & monad transformers to express a powerful parser combinator system.
  - dragonwriter 12y ago
    > Parsing, at least, absolutely can benefit from a powerful type system: consider Haskell's Parsec library, which uses monads & monad transformers to express a powerful parser combinator system But AFAICT, you don't really need type-system support to use monads or monad transformers -- Haskell's purity, static typing, and use of monads for IO forces Haskell users to become familiar with monads, which may encourage Haskellers to develop the skill to use them for other purposes, but there is nothing stopping you from using monads and monad transformers in a dynamically typed language.
    - rntz 12y ago
      No, you don't. But the question at hand isn't using a dynamically vs. a statically typed language, it is, given that you are in a statically typed language, is a Java-style one sufficient? Indeed, this is one of the benefits of dynamically typed languages: you're not restricted to any particular type discipline; you don't have to worry that the type system of the language you're in is too restrictive. OTOH, if you want it to be easy to write reusable code, having static typeclasses with type inference can be quite useful. You could write a monad transformer stack in a dynamically typed language, but you can't always write code that's generic across any monad without explicitly passing around an object that represents the monad in question. (Racket's "units" might be a reasonable solution to this problem, though.)
  - rbehrends 12y ago
    Writing a parser combinator library does not require a powerful type system, especially not a custom one for a specific task (the students who were doing the scanner/parser task were limited to an environment where they had no access to third-party libraries, not that any existed for the language they were given). For a simple parser combinator implementation from scratch you require nothing more than basic types and the type of whatever AST you're generating. Parametric polymorphism is useful when you want to write a reusable parser combinator library, something that wasn't necessary, but even then you don't really need more than that (see other existing parser combinator libraries). Higher order functions can make your life easier, but note that the students had access to a Java-like language (of which there was both a statically and a dynamically typed version) with Ruby-style closures, so that wasn't an obstacle.

The programming tasks did not require complex data structures (such as a scanner and parser), so one would not expect Java's type system to be a limiting factor.

mej10 12y ago
This comment alone is enough to make Haskellers (or other proponents of good type systems) not take this seriously. Anything trying to cast broad strokes about the usefulness and effectiveness of type systems can't use a language with a type system like Java's.
- AnimalMuppet 12y ago
  And your comment is enough to make people not take you seriously. You sound like a stuck-up jerk rather than a thoughtful person. Perhaps you could explain exactly what it is about Java's type system that makes it not worth even discussing. That would be a comment that was actually useful. (And don't say something like "because Java doesn't have higher-kinded types". We know that it doesn't. What about that lack makes it not even worth discussing?)
  - 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 ago
      OK, 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 ago
        Obviously, 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 ago
        As 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.
rntz 12y ago
Parsing, at least, absolutely can benefit from a powerful type system: consider Haskell's Parsec library, which uses monads & monad transformers to express a powerful parser combinator system.
- dragonwriter 12y ago
  > Parsing, at least, absolutely can benefit from a powerful type system: consider Haskell's Parsec library, which uses monads & monad transformers to express a powerful parser combinator system But AFAICT, you don't really need type-system support to use monads or monad transformers -- Haskell's purity, static typing, and use of monads for IO forces Haskell users to become familiar with monads, which may encourage Haskellers to develop the skill to use them for other purposes, but there is nothing stopping you from using monads and monad transformers in a dynamically typed language.
  - rntz 12y ago
    No, you don't. But the question at hand isn't using a dynamically vs. a statically typed language, it is, given that you are in a statically typed language, is a Java-style one sufficient? Indeed, this is one of the benefits of dynamically typed languages: you're not restricted to any particular type discipline; you don't have to worry that the type system of the language you're in is too restrictive. OTOH, if you want it to be easy to write reusable code, having static typeclasses with type inference can be quite useful. You could write a monad transformer stack in a dynamically typed language, but you can't always write code that's generic across any monad without explicitly passing around an object that represents the monad in question. (Racket's "units" might be a reasonable solution to this problem, though.)
- rbehrends 12y ago
  Writing a parser combinator library does not require a powerful type system, especially not a custom one for a specific task (the students who were doing the scanner/parser task were limited to an environment where they had no access to third-party libraries, not that any existed for the language they were given). For a simple parser combinator implementation from scratch you require nothing more than basic types and the type of whatever AST you're generating. Parametric polymorphism is useful when you want to write a reusable parser combinator library, something that wasn't necessary, but even then you don't really need more than that (see other existing parser combinator libraries). Higher order functions can make your life easier, but note that the students had access to a Java-like language (of which there was both a statically and a dynamically typed version) with Ruby-style closures, so that wasn't an obstacle.