3 ms·

“Strong types” (a term that hardly means anything, now that everyone and their dog claims their favorite language is “strongly typed”) don't have anything to do

“Strong types” (a term that hardly means anything, now that everyone and their dog claims their favorite language is “strongly typed”) don't have anything to do with functional programming. And the fact that algebraic data types were originally used in functional languages is just a historical accident.

danbruc 10y ago
Strongly typed was never really a useful description of any language. Eric Lippert nicely points out [1] that descriptions like statically typed, type safe and memory safe are a lot more useful when one wants to compare programming languages than those fuzzy terms strongly and weakly typed. [1] https://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-a-weakly-typed-language/ https://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-...
- catnaroek 10y ago
  A more useful term is “sound”: does the type system protect the language's basic abstractions? (0) Standard ML: Yes. (1) Java: No, but dynamic checks are used to patch the type soundness holes. (2) C: No, and if you do anything wrong, may God help you.
  - danbruc 10y ago
    If you don't use casts, then you should come pretty close to soundness, at least in Java. Array covariance is really the only exception I can ad hoc think of. I am not really sure of C without casts.
    - catnaroek 10y ago
      > If you don't use casts, then you should come pretty close to soundness, at least in Java. If you forbid casts or reflection, then you're throwing away much of the Java ecosystem.
    - kilink 10y ago
      What about null?
      - danbruc 10y ago
        You could say all Java reference types are sum types - either a real instance of that type or a null reference. A function returning a string guarantees that you either get a string or a null reference, I don't think that has (necessarily) implications for soundness. But then again the theory of type systems is not something I have a deep understanding of so I may actually be wrong.
        catnaroek 10y ago
        > You could say all Java reference types are sum types - either a real instance of that type or a null reference. That's not true. There are two fundamental differences: (0) Options can nest. Nullability doesn't nest. (1) Options are manipulated by pattern matching (or direct application of their induction principle, that is, Haskell's `maybe` function). In Java, you just assume a nullable variable isn't null, and if it is, well, you get an exception.
        danbruc 10y ago
        That is certainly a limitation but I don't think that makes this view wrong. I also can not have List<int> but that does not mean List<T> is not a generic list type just because there are some constraints on what T can be.
        catnaroek 10y ago
        In the vast majority of situations, when a Java programmer has a value of type `Foo`, he or she expects it to be a non-`null` reference. Having a `null` one is a possibility, but it's an error. Dictating that reference types are in actuality option types is creating a gigantic mismatch between the prescriptive semantics of the language and the actual model inside the heads of programmers, which is the worst sin a language's semantics can commit. Witness the flame wars about whether it would be a good idea to remove some undefined behavior from C.
- bertiewhykovich 10y ago
  You should post that to the front page -- the ensuing discussion would be definitely interesting.
  - danbruc 10y ago
    That was already posted [1] but received essentially no attention. [1] https://news.ycombinator.com/item?id=4656028 https://news.ycombinator.com/item?id=4656028

danbruc 10y ago

Strongly typed was never really a useful description of any language. Eric Lippert nicely points out [1] that descriptions like statically typed, type safe and memory safe are a lot more useful when one wants to compare programming languages than those fuzzy terms strongly and weakly typed. [1] https://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-a-weakly-typed-language/ https://ericlippert.com/2012/10/15/is-c-a-strongly-typed-or-...

catnaroek 10y ago
A more useful term is “sound”: does the type system protect the language's basic abstractions? (0) Standard ML: Yes. (1) Java: No, but dynamic checks are used to patch the type soundness holes. (2) C: No, and if you do anything wrong, may God help you.
- danbruc 10y ago
  If you don't use casts, then you should come pretty close to soundness, at least in Java. Array covariance is really the only exception I can ad hoc think of. I am not really sure of C without casts.
  - catnaroek 10y ago
    > If you don't use casts, then you should come pretty close to soundness, at least in Java. If you forbid casts or reflection, then you're throwing away much of the Java ecosystem.
  - kilink 10y ago
    What about null?
    - danbruc 10y ago
      You could say all Java reference types are sum types - either a real instance of that type or a null reference. A function returning a string guarantees that you either get a string or a null reference, I don't think that has (necessarily) implications for soundness. But then again the theory of type systems is not something I have a deep understanding of so I may actually be wrong.
      - catnaroek 10y ago
        > You could say all Java reference types are sum types - either a real instance of that type or a null reference. That's not true. There are two fundamental differences: (0) Options can nest. Nullability doesn't nest. (1) Options are manipulated by pattern matching (or direct application of their induction principle, that is, Haskell's `maybe` function). In Java, you just assume a nullable variable isn't null, and if it is, well, you get an exception.
        danbruc 10y ago
        That is certainly a limitation but I don't think that makes this view wrong. I also can not have List<int> but that does not mean List<T> is not a generic list type just because there are some constraints on what T can be.
        catnaroek 10y ago
        In the vast majority of situations, when a Java programmer has a value of type `Foo`, he or she expects it to be a non-`null` reference. Having a `null` one is a possibility, but it's an error. Dictating that reference types are in actuality option types is creating a gigantic mismatch between the prescriptive semantics of the language and the actual model inside the heads of programmers, which is the worst sin a language's semantics can commit. Witness the flame wars about whether it would be a good idea to remove some undefined behavior from C.
bertiewhykovich 10y ago
You should post that to the front page -- the ensuing discussion would be definitely interesting.
- danbruc 10y ago
  That was already posted [1] but received essentially no attention. [1] https://news.ycombinator.com/item?id=4656028 https://news.ycombinator.com/item?id=4656028