6 ms·

The value of static typing depends very much on the application domain. In a closed-world application domain where you can be reasonably sure that you know upfr

The value of static typing depends very much on the application domain. In a closed-world application domain where you can be reasonably sure that you know upfront all entities, their attributes, their valid ranges, etc, static typing is extremely valuable. That applies to domains like compilers, system software, embedded systems, and more. In open-world domains, like business information systems, static typing is often an obstacle to fast adaptation. Whereas immutability provides value in every domain, unless the performance requirement cannot be met.

bad_user 2y ago
I've heard that argument before, but it never really clicked, and I'm a former fan of dynamic typing. The application domain is not relevant because you rarely know the domain up-front. Even if the domain is fully known by business stakeholders, it's not known by the application developers, and those domains can be vast. Application development is a constant process of learning the domain and of extending the existing functionality. This is why all the talk about how LLMs are going to make it possible to replace programmers with people using prompts in English doesn't make much sense. Because the act of programming is primarily one of learning and translating requirements that are initially confusing and context dependent into a precise language. Programming is less about making the computer dance, and more about learning and clarifying requirements. Static typing helps with refactoring, A LOT! So when your understanding of the domain changes, YOU WANT static typing because you want to safely change already existing code. You want static typing precisely because it gives you “fast adaptation”. It's the same argument for why someone would pick Clojure over other dynamic languages. Clojure gives you some guarantees due to the pervasive use of immutability, such that it gives you a clearer view of the API's contract and how you can change it. But statically typed FP goes even further. I've been involved in projects using dynamic typing (PHP, Perl, Ruby, Python) and with no exception, the code became a mess due to the constant evolution. This is one reason for why we preferred an architecture of microservices because it forces you to think of clear boundaries between services, and then you can just throw away or rebuild services from scratch. Large monoliths are much more feasible in statically typed languages, due to the ability for refactoring. And no, while unit testing is always required, IMO, it isn't the same thing.
- randomdata 2y ago
  Static typing exists on a gradient. A ounce of static typing is useful to help with the refactoring, as you suggest, but the tradeoffs seem to quickly take over once you go beyond typing basics. Not even the static typing die hards are willing to write line of business applications under complete type system.
  - bad_user 2y ago
    It's a spectrum, of course. I, for one, prefer more static typing, rather than less. I prefer Scala, OCaml, F#, or Rust. And I've seen some difficult refactorings accomplished in Scala due to its expressive type system, although I can understand why it can be a turnoff. The downside of having more static typing is a bigger learning curve, so you end up sacrificing horizontal scaling of software development (hiring juniors fast) over vertical scaling (doing more with fewer, more senior people). Another downside is many times a slower compiler, which changes how you work. Once the code compiles, it may be correct, but then again, you end up doing less interactive development, so you work more in the abstract, instead of interactively playing with the code. I.e., Python's `pdb.set_trace()` is rarely available in static languages. I've always found this difference between dynamic and static languages quite interesting.
    - randomdata 2y ago
      > I, for one, prefer more static typing, rather than less. I prefer Scala, OCaml, F#, or Rust. Why, then, don't you prefer languages with more static typing? Scala, Ocaml, F#, and Rust are middle of the road at best. It seems you're echoing that the pragmatic choice for a business application is to stick to typing basics (within some margin of what is considered basic).
      - bad_user 2y ago
        I recognize there are diminishing returns, and also, while I don't want first-tier mainstream languages, at the very least I want second-tier mainstream languages :) Haskell, for example, is harder to pick, and I wouldn't pick Idris even if I founded my own company.

bad_user 2y ago

I've heard that argument before, but it never really clicked, and I'm a former fan of dynamic typing. The application domain is not relevant because you rarely know the domain up-front. Even if the domain is fully known by business stakeholders, it's not known by the application developers, and those domains can be vast. Application development is a constant process of learning the domain and of extending the existing functionality. This is why all the talk about how LLMs are going to make it possible to replace programmers with people using prompts in English doesn't make much sense. Because the act of programming is primarily one of learning and translating requirements that are initially confusing and context dependent into a precise language. Programming is less about making the computer dance, and more about learning and clarifying requirements. Static typing helps with refactoring, A LOT! So when your understanding of the domain changes, YOU WANT static typing because you want to safely change already existing code. You want static typing precisely because it gives you “fast adaptation”. It's the same argument for why someone would pick Clojure over other dynamic languages. Clojure gives you some guarantees due to the pervasive use of immutability, such that it gives you a clearer view of the API's contract and how you can change it. But statically typed FP goes even further. I've been involved in projects using dynamic typing (PHP, Perl, Ruby, Python) and with no exception, the code became a mess due to the constant evolution. This is one reason for why we preferred an architecture of microservices because it forces you to think of clear boundaries between services, and then you can just throw away or rebuild services from scratch. Large monoliths are much more feasible in statically typed languages, due to the ability for refactoring. And no, while unit testing is always required, IMO, it isn't the same thing.

randomdata 2y ago
Static typing exists on a gradient. A ounce of static typing is useful to help with the refactoring, as you suggest, but the tradeoffs seem to quickly take over once you go beyond typing basics. Not even the static typing die hards are willing to write line of business applications under complete type system.
- bad_user 2y ago
  It's a spectrum, of course. I, for one, prefer more static typing, rather than less. I prefer Scala, OCaml, F#, or Rust. And I've seen some difficult refactorings accomplished in Scala due to its expressive type system, although I can understand why it can be a turnoff. The downside of having more static typing is a bigger learning curve, so you end up sacrificing horizontal scaling of software development (hiring juniors fast) over vertical scaling (doing more with fewer, more senior people). Another downside is many times a slower compiler, which changes how you work. Once the code compiles, it may be correct, but then again, you end up doing less interactive development, so you work more in the abstract, instead of interactively playing with the code. I.e., Python's `pdb.set_trace()` is rarely available in static languages. I've always found this difference between dynamic and static languages quite interesting.
  - randomdata 2y ago
    > I, for one, prefer more static typing, rather than less. I prefer Scala, OCaml, F#, or Rust. Why, then, don't you prefer languages with more static typing? Scala, Ocaml, F#, and Rust are middle of the road at best. It seems you're echoing that the pragmatic choice for a business application is to stick to typing basics (within some margin of what is considered basic).
    - bad_user 2y ago
      I recognize there are diminishing returns, and also, while I don't want first-tier mainstream languages, at the very least I want second-tier mainstream languages :) Haskell, for example, is harder to pick, and I wouldn't pick Idris even if I founded my own company.