4 ms·

> Without loops you can't write a nontrivial program, and, without case analysis, you can't have non-infinite loops! ...and yet there are Java programs that ha

by cbsmith 10y ago

> Without loops you can't write a nontrivial program, and, without case analysis, you can't have non-infinite loops! ...and yet there are Java programs that have completed their loops time & again! ;-) > Type system - Accurate modeling = Annoying bureaucracy. 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. > Can you imagine pattern matching on abstract syntax trees or other complicated mutually recursive data structures in this way? Or god forbid, using an Enum and an EnumMap!!! > Even the visitor pattern sounds less painful, and that says a lot. Double dispatch really isn't the end of the world. You'll make it. I promise. > Then I can't understand my code in terms of itself. I'd have to know what the attribute processor works transforms it into. You can use the attribute processor to do the reasoning. It becomes an extension of the language. > Trust me, it can cut the size of case-analyzing code by a factor of more than 3. Yes, it cuts code size dramatically. Out of curiosity, how much more compact is that case-analyzing code with a dynamic type system? ;-) > If the class library were the only problem, then the solution would be to make a new one. Hey, if you are just going to write an entirely new class library, then problem solved: you can just as easily write a new language parser and code generator. > A zero potential field isn't a null reference to anything. I didn't say zero potential, I said, "no magnetic field", as in, your magnetic field slot is non-existent/unknown. You've got notions of dimensions that may or may not exist, etc. The point is, you've got nothings that aren't just a magnitude of zero, but which have a type. You have that at least as much as you have a distinct type for nothing.

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

by cbsmith 10y ago

catnaroek 10y ago

> ...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.