6 ms·

In almost all (strongly typed) languages, there is still a need for runtime checks like divide by zero and array bounds checks. Certainly languages like Rust &

In almost all (strongly typed) languages, there is still a need for runtime checks like divide by zero and array bounds checks. Certainly languages like Rust & Haskell bring a high level of static analysis and that is good when you are relying on the tool for memory safety. Personally I prefer gradual type systems that need less up front wrestling so that the coding process is more productive, more time can be spent on tuning the design rather than “finally I made it work” acceptance of compiler driven design. Such languages such as Python, Raku use GC for safety so not perfect for embedded or OS type tasks but easier on the brain. I mentioned Raku since it has extensive runtime type support which allows code like: subset Zero of Int where * == 0; subset NonZero of Int where * != 0; multi infix:<div>(Int \a, Zero \b) {warn “you dolt”; Inf} multi infix:<div>(Int \a, NonZero \b) {a div b} So Larry Wall chose to leverage a runtime typesystem to make it easier to write and maintain code rather than go down the straitjacket route.

apgwoz 3y ago
> Personally I prefer gradual type systems that need less up front wrestling so that the coding process is more productive, more time can be spent on tuning the design rather than “finally I made it work” acceptance of compiler driven design. If your style is to hack hack hack until it’s right, yeah, types are challenging. If your style is to think first about types, you can also create guardrails in your code that naturally create the correct thing. Static vs Dynamic vs Gradual… it’s really more a question of “how does my brain like to get to a solution and keep it functioning” and I find that fascinating.
- deprecative 3y ago
  I think there's a line or maybe some Venn Diagram meme about hack back hackers and "I'll refactor this later". Not trying to start anything with either type. We're all guilty of these platitudes and well intentioned lies.
- MaxBarraclough 3y ago
  > it’s really more a question of “how does my brain like to get to a solution and keep it functioning” and I find that fascinating Sure, but this is largely a matter of training and experience. Plenty of fans of dynamically typed languages just haven't learnt how to make effective use of decent static type systems.
  - Exoristos 3y ago
    And plenty of them wouldn't want to learn it, so I think OP's observation still holds.
  - auggierose 3y ago
    Static type systems are premature optimization, and come with all of its problems. So a more fluid solution is a great thing, if done right. TypeScript comes to mind, although it has other problems, in particular mutable data structures by default.
    - clhodapp 3y ago
      Why do you say that static type systems are a "premature optimization"? On its face, that seems like a (very spicy) opinion that's been stated as fact.
      - auggierose 3y ago
        It is a fact, that is why I state it as one. You are basically trying to write a correctness proof before you actually have a good idea of what it is you are trying to build. I've done this plenty of times myself, and it is a good way to waste time and tell yourself you are productive. Yes, I am also looking at all the "let's rewrite stuff in Rust" projects. Especially problematic is that the type system doesn't necessarily reflect the correctness you care about, but just some properties the language cares especially about. You are spending your time trying to shoehorn your solution into somebody else's idea of correctness, who doesn't really know anything about your program at hand. That's why I like TypeScript, its type system is expressive enough for many simple correctness checks I actually care about, while at the same time not getting (too much, and with the above caveats) in the way of how I think about what I build. It is especially clear to me that static type systems are dinosaurs of the past. The future is on-the-fly checking of arbitrary logical properties of your program, which can always contain what static type systems used to be for as a subset.
anonzzzies 3y ago
I like Raku (it fits my brain as I was programming a lot of Perl in the 90s) and I like these features. You want to be able to do this. A lot of this you can easily make static though (so you have both) (maybe that happens under the hood?).

apgwoz 3y ago

> Personally I prefer gradual type systems that need less up front wrestling so that the coding process is more productive, more time can be spent on tuning the design rather than “finally I made it work” acceptance of compiler driven design. If your style is to hack hack hack until it’s right, yeah, types are challenging. If your style is to think first about types, you can also create guardrails in your code that naturally create the correct thing. Static vs Dynamic vs Gradual… it’s really more a question of “how does my brain like to get to a solution and keep it functioning” and I find that fascinating.

deprecative 3y ago
I think there's a line or maybe some Venn Diagram meme about hack back hackers and "I'll refactor this later". Not trying to start anything with either type. We're all guilty of these platitudes and well intentioned lies.
MaxBarraclough 3y ago
> it’s really more a question of “how does my brain like to get to a solution and keep it functioning” and I find that fascinating Sure, but this is largely a matter of training and experience. Plenty of fans of dynamically typed languages just haven't learnt how to make effective use of decent static type systems.
- Exoristos 3y ago
  And plenty of them wouldn't want to learn it, so I think OP's observation still holds.
- auggierose 3y ago
  Static type systems are premature optimization, and come with all of its problems. So a more fluid solution is a great thing, if done right. TypeScript comes to mind, although it has other problems, in particular mutable data structures by default.
  - clhodapp 3y ago
    Why do you say that static type systems are a "premature optimization"? On its face, that seems like a (very spicy) opinion that's been stated as fact.
    - auggierose 3y ago
      It is a fact, that is why I state it as one. You are basically trying to write a correctness proof before you actually have a good idea of what it is you are trying to build. I've done this plenty of times myself, and it is a good way to waste time and tell yourself you are productive. Yes, I am also looking at all the "let's rewrite stuff in Rust" projects. Especially problematic is that the type system doesn't necessarily reflect the correctness you care about, but just some properties the language cares especially about. You are spending your time trying to shoehorn your solution into somebody else's idea of correctness, who doesn't really know anything about your program at hand. That's why I like TypeScript, its type system is expressive enough for many simple correctness checks I actually care about, while at the same time not getting (too much, and with the above caveats) in the way of how I think about what I build. It is especially clear to me that static type systems are dinosaurs of the past. The future is on-the-fly checking of arbitrary logical properties of your program, which can always contain what static type systems used to be for as a subset.

anonzzzies 3y ago

I like Raku (it fits my brain as I was programming a lot of Perl in the 90s) and I like these features. You want to be able to do this. A lot of this you can easily make static though (so you have both) (maybe that happens under the hood?).