7 ms·

> 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

> 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.
    - naasking 3y ago
      > 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're neglecting that these guardrails guide you towards solutions that can be naturally expressed and checked by the language. That's a feature, not a bug. > 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. Yeah, except for logical consistency or soundness, but who cares about that?
      - auggierose 3y ago
        No, I don't neglect that. These guardrails are guiding you towards something, but it is very optimistic to assume that they guide you towards the best solution. There is a lot of religion and faith involved here. I care a lot for logical consistency and soundness, probably more than anyone else you know. But it is wrong to think that static type systems are the best way towards this. Logic is the best way towards this, and static type systems are just one way of implementing logic, and not the best one. Especially in programming, what static type systems were really good at, was automating some correctness checks. I believe in a future where automation gets so good that static type systems become a hindrance, and where their benefit vanishes when weighed up against your freedom to express things as they really are.
        naasking 3y ago
        > These guardrails are guiding you towards something, but it is very optimistic to assume that they guide you towards the best solution. "Best solution" is a fantasy. Any solution must be expressed in a language with concrete semantics, but there is no best language for all possible problems. This was the lesson of Kolmogorov complexity. Therefore, we will always necessarily be using a suboptimal language, and we should let go of any wish for ill-defined optimality. We should instead use a language that guides towards engineering good solutions to problems with desirable properties. Sometimes that might mean strict control over resources (as with Rust), sometimes that isn't necessary (so OCaml,F#, etc. would do). An empirical fact of engineering is that most mistakes people make are trivial, eg. typos, one off errors, forgetfulness to change code in all relevant places during refactoring, etc. Good abstractions enforced by static types solve all of these problems, allowing you to focus on the core problem without being bothered that you might have missed some silly details. Yes the compiler bothers you to correct these details, but this is typically simple mechanistic work that nevertheless can't be automated by any other language without sacrificing other desirable properties. I'm not going to argue that any static type system is better than no static types, because it's easy to invent a bad type system. We've had pretty damn good type systems since the 70s though, they just didn't see much use until recently.
- Arelius 3y ago
  The misconception that all "early optimization" is premature optimization is a dangerous one. I'll agree with you that starting with static type systems is an early optimization. But if it's premature or not is clearly context dependent. And it is often "right on time" optimization. Just as are many things engineers like to deride as "premature optimization". It's not premature if it's known to be needed and the cost of doing it later greatly outweighs doing it now.
samatman 3y ago
I've been getting a lot of mileage out of Julia recently, and would counter that plenty of fans of statically typed languages just haven't learned to use an effectively-typed dynamic language. It's great, give it a shot sometime.
- samatman 3y ago
  Here, lemme help those of you who would rather use your reflexes than your frontal cortex https://docs.julialang.org/en/v1/manual/types/ https://docs.julialang.org/en/v1/manual/types/ It's possible to get the advantages of a dynamic runtime and the advantages of a powerful type system, Julia is proof of that.

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.
  - naasking 3y ago
    > 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're neglecting that these guardrails guide you towards solutions that can be naturally expressed and checked by the language. That's a feature, not a bug. > 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. Yeah, except for logical consistency or soundness, but who cares about that?
    - auggierose 3y ago
      No, I don't neglect that. These guardrails are guiding you towards something, but it is very optimistic to assume that they guide you towards the best solution. There is a lot of religion and faith involved here. I care a lot for logical consistency and soundness, probably more than anyone else you know. But it is wrong to think that static type systems are the best way towards this. Logic is the best way towards this, and static type systems are just one way of implementing logic, and not the best one. Especially in programming, what static type systems were really good at, was automating some correctness checks. I believe in a future where automation gets so good that static type systems become a hindrance, and where their benefit vanishes when weighed up against your freedom to express things as they really are.
      - naasking 3y ago
        > These guardrails are guiding you towards something, but it is very optimistic to assume that they guide you towards the best solution. "Best solution" is a fantasy. Any solution must be expressed in a language with concrete semantics, but there is no best language for all possible problems. This was the lesson of Kolmogorov complexity. Therefore, we will always necessarily be using a suboptimal language, and we should let go of any wish for ill-defined optimality. We should instead use a language that guides towards engineering good solutions to problems with desirable properties. Sometimes that might mean strict control over resources (as with Rust), sometimes that isn't necessary (so OCaml,F#, etc. would do). An empirical fact of engineering is that most mistakes people make are trivial, eg. typos, one off errors, forgetfulness to change code in all relevant places during refactoring, etc. Good abstractions enforced by static types solve all of these problems, allowing you to focus on the core problem without being bothered that you might have missed some silly details. Yes the compiler bothers you to correct these details, but this is typically simple mechanistic work that nevertheless can't be automated by any other language without sacrificing other desirable properties. I'm not going to argue that any static type system is better than no static types, because it's easy to invent a bad type system. We've had pretty damn good type systems since the 70s though, they just didn't see much use until recently.
Arelius 3y ago
The misconception that all "early optimization" is premature optimization is a dangerous one. I'll agree with you that starting with static type systems is an early optimization. But if it's premature or not is clearly context dependent. And it is often "right on time" optimization. Just as are many things engineers like to deride as "premature optimization". It's not premature if it's known to be needed and the cost of doing it later greatly outweighs doing it now.

samatman 3y ago

I've been getting a lot of mileage out of Julia recently, and would counter that plenty of fans of statically typed languages just haven't learned to use an effectively-typed dynamic language. It's great, give it a shot sometime.

samatman 3y ago
Here, lemme help those of you who would rather use your reflexes than your frontal cortex https://docs.julialang.org/en/v1/manual/types/ https://docs.julialang.org/en/v1/manual/types/ It's possible to get the advantages of a dynamic runtime and the advantages of a powerful type system, Julia is proof of that.