3 ms·

I would actually be curious to hear your perspective on the "best way" that isn't typechecking. I literally cannot comprehend why someone would write such a thi

I would actually be curious to hear your perspective on the "best way" that isn't typechecking. I literally cannot comprehend why someone would write such a thing I readily admit that I am biased in that I believe that having a computer check that every reference to every relationship does what it promises, all the time

postflopclarity 1y ago
first and foremost great documentation & design docs cannot be surpassed as a tool to explain and understand code. and that is entirely language agnostic. more generally, the most important bits of a particular function to understand is * what should it be called with * what should it return * what side effects might it have and the "what" here refers to properties in a general sense. types are a good shortcut to signify certain named collections of properties (e.g., the `Int` type has arithmetic properties). but there are other ways to express traits, preconditions, postconditions, etc. besides types
- lgas 1y ago
  I mean documentation can be wrong whereas types can't, so it seems like it's strictly a worse tool if your goal is to understand what's actually going on and not what someone said was going on at some point in the past.
  - postflopclarity 1y ago
    > whereas types can't they sure can...
    - olddustytrail 1y ago
      Can they? How does that work?
      - adgjlsfhk1 1y ago
        types can be (and almost always are) overly restrictive, preventing otherwise valid code from running. they can also be under powered, and not expressing necessary invariants for the algorithm.
        lgas 1y ago
        I didn't make any claims about that, just that they can't be wrong. And by that, I didn't mean you can't choose the wrong types, just that once you've chosen types that compile they can't be incompatible or other than what they are. That being said, I've always found the argument that types can be overly restrictive and prevent otherwise valid code from running unconvincing. I've yet to see dynamic code that benefits from this alleged advantage. Nearly universally the properly typed code for the same thing is better, more reliable and easier for new people to understand and modify. So sure, you can avoid all of this if the types are really what bother you, but it feels a bit like saying "there are stunts I can pull off if I'm not wearing a seatbelt that I just can't physically manage if I am." If doing stunts is your thing, knock yourself out, but I'd rather wear a seatbelt and be more confident I'm going to get to my destination in one piece.
- const_cast 1y ago
  but there are other ways to express traits, preconditions, postconditions, etc. besides types You can also put that in the type system, and expressive languages do. Its just a compiler limitations when we can't. I mean, even in C++ with concepts we can do most of that. And C++ doesn't have the most expressive type system.

postflopclarity 1y ago

first and foremost great documentation & design docs cannot be surpassed as a tool to explain and understand code. and that is entirely language agnostic. more generally, the most important bits of a particular function to understand is * what should it be called with * what should it return * what side effects might it have and the "what" here refers to properties in a general sense. types are a good shortcut to signify certain named collections of properties (e.g., the `Int` type has arithmetic properties). but there are other ways to express traits, preconditions, postconditions, etc. besides types

lgas 1y ago
I mean documentation can be wrong whereas types can't, so it seems like it's strictly a worse tool if your goal is to understand what's actually going on and not what someone said was going on at some point in the past.
- postflopclarity 1y ago
  > whereas types can't they sure can...
  - olddustytrail 1y ago
    Can they? How does that work?
    - adgjlsfhk1 1y ago
      types can be (and almost always are) overly restrictive, preventing otherwise valid code from running. they can also be under powered, and not expressing necessary invariants for the algorithm.
      - lgas 1y ago
        I didn't make any claims about that, just that they can't be wrong. And by that, I didn't mean you can't choose the wrong types, just that once you've chosen types that compile they can't be incompatible or other than what they are. That being said, I've always found the argument that types can be overly restrictive and prevent otherwise valid code from running unconvincing. I've yet to see dynamic code that benefits from this alleged advantage. Nearly universally the properly typed code for the same thing is better, more reliable and easier for new people to understand and modify. So sure, you can avoid all of this if the types are really what bother you, but it feels a bit like saying "there are stunts I can pull off if I'm not wearing a seatbelt that I just can't physically manage if I am." If doing stunts is your thing, knock yourself out, but I'd rather wear a seatbelt and be more confident I'm going to get to my destination in one piece.
const_cast 1y ago
but there are other ways to express traits, preconditions, postconditions, etc. besides types You can also put that in the type system, and expressive languages do. Its just a compiler limitations when we can't. I mean, even in C++ with concepts we can do most of that. And C++ doesn't have the most expressive type system.