3 ms·

(just going' down this rabbit hole with you all) The problem I have with static typing (as widely implemented) is it solves little problems at the cost of arbi

by jmull 9y ago

(just going' down this rabbit hole with you all) The problem I have with static typing (as widely implemented) is it solves little problems at the cost of arbitrary inflexibility which ends up rippling through a code base. And the little problems are better solved in other ways. E.g., unit tests and the like catch type errors on the way to validating that your code actually does what you think it should do. Static typing also isn't useful when dealing with data that moves through distributed systems. You know, like pretty much all the data. The static types you had at compile time are fundamentally not related to the data you are processing at run time and static types don't equip you to deal with that very well. Systems map "wild" incoming data to the internal static types but the static type environments strongly encourage this to happen early, which is often not the right place.

loup-vaillant 9y ago
> The problem I have with static typing (as widely implemented) Mainstream type systems are best ignored. If it doesn't have sum types, it's not a good type system. If it doesn't have generics, it's not a good type system.
- jmull 9y ago
  More flexible static type systems can help, but they don't address the fundamental problem that they are trying to make a strong statement at development time about something that isn't known until runtime. This pushes dealing with the problem (of what if something isn't the expected type/is malformed/is missing/is incomplete) to the wrong place, causing unnecessary complexity, dependencies and bugs.
  - loup-vaillant 9y ago
    Give me an example of a correct program you actually want to write, that a decent static type system. I do have examples of correct programs that almost no static type checker will accept, but I don't want to write those programs. For instance: if true then 1 else "one" This is an expression of type int, that yields the value 1. But I don't want to write such crap, because of (i) dead code, and (ii) mismatched types between the the branches (one is an int, the other is a string).
rifung 9y ago
I don't often feel constrained by static typing but perhaps we are just working on different kinds of problems. As for distributed systems, it's true that static typing doesn't solve that on it's own, but combined with something like protobuf, it should right? Admittedly I've only recently learned of protobufs so feel free to correct me.
- jmull 9y ago
  I hadn't heard of protobufs before now. But if I understand it correctly, I don't think it addresses (what I think is) the fundamental problem with static typing in a distributed system. It's that the your static types that exist at development/compile time aren't really strongly related to the runtime data. Meaning, the strong guarantees that static types make aren't actually true. Systems deal with this by recreating the relationship: they convert incoming data to instances of the static types. But you have to note, this code exists to satisfy the static type system. If you didn't have a static type system, you don't need that code: you don't have to write it, test it, maintain it, etc. protobufs looks like one way to recreate the relationship between your runtime data and the static types. It looks pretty nice, but it has its own complexities -- another language to learn on top of anything else you're doing, another tool to install and learn with its own quirks (I notice the generated C++ code files have a .cc extension), a code generation step to integrate into your build, new versions of protobuf to be integrated to get new features). Stuff you don't need to deal with if you don't have a static type system. But it's not just that its wasteful. It also encourages you to deal with changes to your data model early, in a generic way (because your inflexible static type system pervades the entire code base... you can't do anything with the data until you wrestle it into an instance of a static type). But that's often not the best place to do it because at that point, the system doesn't know what will be done with the data. Not that static types don't have their place. They certainly have their uses, but I think it's in small, inner-boxes, not throughout a codebase. E.g., let's make it something you have to opt-in to on a case-by-case basis, not a pervasive assumed default. Sure, provide a mechanism for type hinting to drive helpful static code analysis, like auto-complete and refactoring tools. Perhaps provide some kind of flexible dynamic-type/static-type bridge that helps you solve dynamic-type/static-type issues rather than encourage them. E.g., something that at run time keeps track of the difference between runtime data and the static type it is supposed to be according to the type hinting.

by jmull 9y ago

loup-vaillant 9y ago

> The problem I have with static typing (as widely implemented) Mainstream type systems are best ignored. If it doesn't have sum types, it's not a good type system. If it doesn't have generics, it's not a good type system.

jmull 9y ago
More flexible static type systems can help, but they don't address the fundamental problem that they are trying to make a strong statement at development time about something that isn't known until runtime. This pushes dealing with the problem (of what if something isn't the expected type/is malformed/is missing/is incomplete) to the wrong place, causing unnecessary complexity, dependencies and bugs.
- loup-vaillant 9y ago
  Give me an example of a correct program you actually want to write, that a decent static type system. I do have examples of correct programs that almost no static type checker will accept, but I don't want to write those programs. For instance: if true then 1 else "one" This is an expression of type int, that yields the value 1. But I don't want to write such crap, because of (i) dead code, and (ii) mismatched types between the the branches (one is an int, the other is a string).

rifung 9y ago

I don't often feel constrained by static typing but perhaps we are just working on different kinds of problems. As for distributed systems, it's true that static typing doesn't solve that on it's own, but combined with something like protobuf, it should right? Admittedly I've only recently learned of protobufs so feel free to correct me.

jmull 9y ago
I hadn't heard of protobufs before now. But if I understand it correctly, I don't think it addresses (what I think is) the fundamental problem with static typing in a distributed system. It's that the your static types that exist at development/compile time aren't really strongly related to the runtime data. Meaning, the strong guarantees that static types make aren't actually true. Systems deal with this by recreating the relationship: they convert incoming data to instances of the static types. But you have to note, this code exists to satisfy the static type system. If you didn't have a static type system, you don't need that code: you don't have to write it, test it, maintain it, etc. protobufs looks like one way to recreate the relationship between your runtime data and the static types. It looks pretty nice, but it has its own complexities -- another language to learn on top of anything else you're doing, another tool to install and learn with its own quirks (I notice the generated C++ code files have a .cc extension), a code generation step to integrate into your build, new versions of protobuf to be integrated to get new features). Stuff you don't need to deal with if you don't have a static type system. But it's not just that its wasteful. It also encourages you to deal with changes to your data model early, in a generic way (because your inflexible static type system pervades the entire code base... you can't do anything with the data until you wrestle it into an instance of a static type). But that's often not the best place to do it because at that point, the system doesn't know what will be done with the data. Not that static types don't have their place. They certainly have their uses, but I think it's in small, inner-boxes, not throughout a codebase. E.g., let's make it something you have to opt-in to on a case-by-case basis, not a pervasive assumed default. Sure, provide a mechanism for type hinting to drive helpful static code analysis, like auto-complete and refactoring tools. Perhaps provide some kind of flexible dynamic-type/static-type bridge that helps you solve dynamic-type/static-type issues rather than encourage them. E.g., something that at run time keeps track of the difference between runtime data and the static type it is supposed to be according to the type hinting.