19 ms·

> That's right. Sometimes the type system doesn't have all the answers. (...) It's a tragedy, but amazingly the type system can still be useful. Hence... why we

> That's right. Sometimes the type system doesn't have all the answers. (...) It's a tragedy, but amazingly the type system can still be useful. Hence... why we have type systems. I'm not saying that any single type system can have the answer to every question, or that every question is worth having a compile-time answer for. But a useful type system must have some class of questions that it can answer clearly, accurately and with minimal fuss: (0) ML and Haskell can answer questions of the form “how many qualitatively different outcomes can an operation have?” (1) C++ can answer questions of the form “who's responsible for cleaning up this resource?” (2) Rust can answer both (0) and (1), as well as “for how long can I hold a non-owning reference?” (3) Java hardly ever gives any useful answers to anything. The right language for a given task is the one that maximizes how efficiently you can get answers for the kind of questions you need to ask to construct a correct solution. > ...and if isinstance really is preferable for you than the visitors pattern, then you've got no reason to prefer dynamic dispatch. You can muddle through your multi-type scenarios using Object and instanceof tests... and you still get lots of help for the single-type scenarios. Yes, but if every single variable will have type `Object`, I might as well ditch the static type system, since it isn't providing any value. > That's one way of modeling it I guess, but that's a choice you are making about how it is modeled. My model is consistent with how people actually perform dimensional analysis with pencil and paper. > Most people's mental models include moments where you know the type of something, but you don't actually have anything there. Don't conflate “most programmers” with “most people”. Most people would be horrified if they found out how programmers model things. > The type of your unfilled referee slot in your league planning application Of course, the referee slot doesn't contain a `Referee`. It contains a `Maybe Referee`. > is not the same as a missing fifth dimension in someone else's physics simulator. Sure, I don't perform arithmetic on `Referee`s.

cbsmith 10y ago
> C++ can answer questions of the form “who's responsible for cleaning up this resource?” It can't. You have to follow explicit conventions in order for it to do that, and an untrusted shared library can completely subvert the model. On the same basis you are judging Java, that makes its entire type system a waste of time. > Java hardly ever gives any useful answers to anything. BS. Java's type system gives you an ability to know the type of a given parameter with a high degree of confidence. For the majority of cases, you only have one possible type, and Java does a great job of validating those cases. Sure it's a simple thing, but I'd rather have a tool that at least does the simple things for me, rather than one that doesn't. If nothing else, IDE developers have demonstrated that a lot of value can be unlocked from these simple assurances. > Of course, the referee slot doesn't contain a `Referee`. It contains a `Maybe Referee`. No, it contains a referee slot. Maybe in your type model, it has a maybe referee, but you're artificially throwing in the notion of None as a crucial bit of the type system (and I agree it is important, but so are a lot of other things). Java's type system basically makes all reference variable types "maybe" types. Python's type system basically makes all variables "maybe" for any type. > Yes, but if every single variable will have type `Object`, I might as well ditch the static type system, since it isn't providing any value. No, every single variable will have type Object. Only the ones involving multiple types. Amazingly, if you look at Java code, the vast majority of the time, programmers are able to find more specific types to tag their variables, and rarely need to use instanceof or the visitor pattern. > Sure, I don't perform arithmetic on `Referee`s. That's great, and I'm sure from your vantage point all that matters is arithmetic, but it turns out a lot of other programs and programmers write code that largely has nothing to do with arithmetic.
- catnaroek 10y ago
  > It [C++] can't. You have to follow explicit conventions in order for it to do that, and an untrusted shared library can completely subvert the model. Point taken. > BS. Java's type system gives you an ability to know the type of a given parameter with a high degree of confidence. For the majority of cases, you only have one possible type, and Java does a great job of validating those cases. If that's the entire point, why have complicated features like wildcards and F-bound polymorphism? ML and Haskell (no GHC extensions) give you stronger guarantees than that, with far less complicated type systems: in fact, their type systems are simple enough that global type inference is decidable! > Sure it's a simple thing, but I'd rather have a tool that at least does the simple things for me, rather than one that doesn't. Well, for me, everything is ultimately subject to a benefit/cost analysis. Ceteris paribus, more static guarantees is better, but marginally more static guarantees than Python in exchange for a lot of additional ceremony isn't a tradeoff I find attractive enough. > If nothing else, IDE developers have demonstrated that a lot of value can be unlocked from these simple assurances. By heroically overcoming expressiveness limitations that shouldn't be there in the first place? > Maybe in your type model, it has a maybe referee, but you're artificially throwing in the notion of None as a crucial bit of the type system It's not artificial if it reflects what's actually going on. An incomplete league schedule doesn't always contain a `Referee` in every referee slot, and I have to model this fact. > Java's type system basically makes all reference variable types "maybe" types. This isn't true. `Maybe`s compose. You can have a `Maybe (Maybe Foo)`, which isn't the same thing as a `Maybe Foo`, and the type checker will require you to be very aware. OTOH, `null` can't be layered in this way, and that's why, for example, `TreeMap.get()` returns `null` in two qualitatively different circumstances. > Python's type system basically makes all variables "maybe" for any type. Again, this isn't true. Python has a single static type: the type of every Python expression. > Amazingly, if you look at Java code, the vast majority of the time, programmers are able to find more specific types to tag their variables, and rarely need to use instanceof or the visitor pattern. At the price of never knowing whether their case analyses are exhaustive. > That's great, and I'm sure from your vantage point all that matters is arithmetic, but it turns out a lot of other programs and programmers write code that largely has nothing to do with arithmetic. What matters to me, as I've made explicit above, is accurate modeling. Sometimes it involves arithmetic, other times it doesn't. Sometimes it doesn't even involve types! But, when types don't help, I prefer them to get out of the way.

cbsmith 10y ago

> C++ can answer questions of the form “who's responsible for cleaning up this resource?” It can't. You have to follow explicit conventions in order for it to do that, and an untrusted shared library can completely subvert the model. On the same basis you are judging Java, that makes its entire type system a waste of time. > Java hardly ever gives any useful answers to anything. BS. Java's type system gives you an ability to know the type of a given parameter with a high degree of confidence. For the majority of cases, you only have one possible type, and Java does a great job of validating those cases. Sure it's a simple thing, but I'd rather have a tool that at least does the simple things for me, rather than one that doesn't. If nothing else, IDE developers have demonstrated that a lot of value can be unlocked from these simple assurances. > Of course, the referee slot doesn't contain a `Referee`. It contains a `Maybe Referee`. No, it contains a referee slot. Maybe in your type model, it has a maybe referee, but you're artificially throwing in the notion of None as a crucial bit of the type system (and I agree it is important, but so are a lot of other things). Java's type system basically makes all reference variable types "maybe" types. Python's type system basically makes all variables "maybe" for any type. > Yes, but if every single variable will have type `Object`, I might as well ditch the static type system, since it isn't providing any value. No, every single variable will have type Object. Only the ones involving multiple types. Amazingly, if you look at Java code, the vast majority of the time, programmers are able to find more specific types to tag their variables, and rarely need to use instanceof or the visitor pattern. > Sure, I don't perform arithmetic on `Referee`s. That's great, and I'm sure from your vantage point all that matters is arithmetic, but it turns out a lot of other programs and programmers write code that largely has nothing to do with arithmetic.

catnaroek 10y ago
> It [C++] can't. You have to follow explicit conventions in order for it to do that, and an untrusted shared library can completely subvert the model. Point taken. > BS. Java's type system gives you an ability to know the type of a given parameter with a high degree of confidence. For the majority of cases, you only have one possible type, and Java does a great job of validating those cases. If that's the entire point, why have complicated features like wildcards and F-bound polymorphism? ML and Haskell (no GHC extensions) give you stronger guarantees than that, with far less complicated type systems: in fact, their type systems are simple enough that global type inference is decidable! > Sure it's a simple thing, but I'd rather have a tool that at least does the simple things for me, rather than one that doesn't. Well, for me, everything is ultimately subject to a benefit/cost analysis. Ceteris paribus, more static guarantees is better, but marginally more static guarantees than Python in exchange for a lot of additional ceremony isn't a tradeoff I find attractive enough. > If nothing else, IDE developers have demonstrated that a lot of value can be unlocked from these simple assurances. By heroically overcoming expressiveness limitations that shouldn't be there in the first place? > Maybe in your type model, it has a maybe referee, but you're artificially throwing in the notion of None as a crucial bit of the type system It's not artificial if it reflects what's actually going on. An incomplete league schedule doesn't always contain a `Referee` in every referee slot, and I have to model this fact. > Java's type system basically makes all reference variable types "maybe" types. This isn't true. `Maybe`s compose. You can have a `Maybe (Maybe Foo)`, which isn't the same thing as a `Maybe Foo`, and the type checker will require you to be very aware. OTOH, `null` can't be layered in this way, and that's why, for example, `TreeMap.get()` returns `null` in two qualitatively different circumstances. > Python's type system basically makes all variables "maybe" for any type. Again, this isn't true. Python has a single static type: the type of every Python expression. > Amazingly, if you look at Java code, the vast majority of the time, programmers are able to find more specific types to tag their variables, and rarely need to use instanceof or the visitor pattern. At the price of never knowing whether their case analyses are exhaustive. > That's great, and I'm sure from your vantage point all that matters is arithmetic, but it turns out a lot of other programs and programmers write code that largely has nothing to do with arithmetic. What matters to me, as I've made explicit above, is accurate modeling. Sometimes it involves arithmetic, other times it doesn't. Sometimes it doesn't even involve types! But, when types don't help, I prefer them to get out of the way.