4 ms·

> ...and yet there are Java programs that have completed their loops time & again! ;-) Sure, by branching on booleans. Unfortunately, branching on raw booleans

> ...and yet there are Java programs that have completed their loops time & again! ;-) Sure, by branching on booleans. Unfortunately, branching on raw booleans is problematic for a variety of reasons, which are lucidly explained here: https://existentialtype.wordpress.com/2011/03/15/boolean-blindness/ https://existentialtype.wordpress.com/2011/03/15/boolean-bli... . The tl;dr is that when you compute a boolean, your actual intention is to learn something about the state of other variables, but the type system doesn't keep track of this additional knowledge. So you're on your own, just as if you were using a dynamic language. > Oh sure, lots of annoyance, but few languages have a good type system, and those that do have a limited pool of programmers to draw upon who can reason about them. There's another possibility: using a language with (gasp!) no static type system. > Double dispatch really isn't the end of the world. You'll make it. I promise. I'll spare myself the pain. > You can use the attribute processor to do the reasoning. It becomes an extension of the language. Will I get error messages in terms of the abstraction itself, or in terms of what it elaborates into in the base language? > Out of curiosity, how much more compact is that case-analyzing code with a dynamic type system? ;-) `isinstance` in Python is roughly as verbose as Java's `instanceof`, which is the type-unsafe solution to this problem. It's still more verbose than proper pattern matching, but a lot less verbose than visitors. > I didn't say zero potential, I said, "no magnetic field", as in, your magnetic field slot is non-existent/unknown. Sorry for misunderstanding in my first attempt. But what you describe doesn't correspond to Java-style `null` either. Dimensional analysis corresponds to parameterizing a scalar type by the exponent of each primitive dimension, say: template <class Magnitude, int time, int length, int mass, int charge...> struct scalar { Magnitude magnitude; }; And then overloading all arithmetic operators in a dimensionally consistent way. Which again Java is incapable of expressing.

cbsmith 10y ago
> The tl;dr is that when you compute a boolean, your actual intention is to learn something about the state of other variables, but the type system doesn't keep track of this additional knowledge. That's right. Sometimes the type system doesn't have all the answers. I have yet to see a type system that solves the halting problem. It's a tragedy, but amazingly the type system can still be useful. Hence... why we have type systems. > > Double dispatch really isn't the end of the world. You'll make it. I promise. > I'll spare myself the pain. ...not if it is by using a dynamic type system. > Will I get error messages in terms of the abstraction itself, or in terms of what it elaborates into in the base language? I guess that is up to you. > `isinstance` in Python is roughly as verbose as Java's `instanceof`, which is the type-unsafe solution to this problem. It's still more verbose than proper pattern matching, but a lot less verbose than visitors. The vast majority of Java code wants for neither instanceof nor visitors. That's the win. ...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. > Dimensional analysis corresponds to parameterizing a scalar type by the exponent of each primitive dimension.. That's one way of modeling it I guess, but that's a choice you are making about how it is modeled. Most people's mental models include moments where you know the type of something, but you don't actually have anything there. The type of your unfilled referee slot in your league planning application is not the same as a missing fifth dimension in someone else's physics simulator.
- catnaroek 10y ago
  > 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.

cbsmith 10y ago

> The tl;dr is that when you compute a boolean, your actual intention is to learn something about the state of other variables, but the type system doesn't keep track of this additional knowledge. That's right. Sometimes the type system doesn't have all the answers. I have yet to see a type system that solves the halting problem. It's a tragedy, but amazingly the type system can still be useful. Hence... why we have type systems. > > Double dispatch really isn't the end of the world. You'll make it. I promise. > I'll spare myself the pain. ...not if it is by using a dynamic type system. > Will I get error messages in terms of the abstraction itself, or in terms of what it elaborates into in the base language? I guess that is up to you. > `isinstance` in Python is roughly as verbose as Java's `instanceof`, which is the type-unsafe solution to this problem. It's still more verbose than proper pattern matching, but a lot less verbose than visitors. The vast majority of Java code wants for neither instanceof nor visitors. That's the win. ...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. > Dimensional analysis corresponds to parameterizing a scalar type by the exponent of each primitive dimension.. That's one way of modeling it I guess, but that's a choice you are making about how it is modeled. Most people's mental models include moments where you know the type of something, but you don't actually have anything there. The type of your unfilled referee slot in your league planning application is not the same as a missing fifth dimension in someone else's physics simulator.

catnaroek 10y ago
> 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.