4 ms·

I think there are at least two ways to write safe and robust code, one being to rely on static types to provide automatic guarantees, and another being to struc

I think there are at least two ways to write safe and robust code, one being to rely on static types to provide automatic guarantees, and another being to structure the program in a way where tests reveal errors immediately. They are mutually incompatible, and so different from one another that few people can be experts at both, but I don't think one is objectively inferior to the other. Both styles require code to be disciplined, and undisciplined code cannot be caught by compilers, linters or automatic tools, it has to be through code review (or experience and sheer willpower). It's easy to think of examples where a lack of static types would allow brittle code to be written, but it's important to question whether that brittle code may be considered unacceptable by someone experienced in working without static types, in the same way that code using a Dictionary<string, object> instead of an actual type would be considered unacceptable by a type-safety practitioner despite being (technically) type-safe.

evrimoztamur 3y ago
Why are they incompatible?
- victorNicollet 3y ago
  For example, with static typing one would define many different complex types over the program, in order to have the compiler enforce the many different constraints (here the value can be null, but not there ; these two values must be provided together ; and so on). Things like structural typing or algebraic data types even allows the creation of unnamed types on the fly. When sum types are used, conditional operators will be used to deconstruct these in a type-safe way, resulting in many branches. With dynamic typing, one would have only a small number of very different types, because having many types increases the risk of using the wrong one, and having similar types makes it harder to notice that the wrong one is being used. The types must be very simple, because deconstructing complex types requires having branches, and branches should be kept to a minimum because they are hard to cover properly with unit tests.
  - evrimoztamur 3y ago
    These complex constructs already appear unnamed within dynamically typed programs, you just don't keep track of them at all. The inherent disarray of your unit tests must stem from the complexity of your algorithms, not from your types.

evrimoztamur 3y ago

Why are they incompatible?

victorNicollet 3y ago
For example, with static typing one would define many different complex types over the program, in order to have the compiler enforce the many different constraints (here the value can be null, but not there ; these two values must be provided together ; and so on). Things like structural typing or algebraic data types even allows the creation of unnamed types on the fly. When sum types are used, conditional operators will be used to deconstruct these in a type-safe way, resulting in many branches. With dynamic typing, one would have only a small number of very different types, because having many types increases the risk of using the wrong one, and having similar types makes it harder to notice that the wrong one is being used. The types must be very simple, because deconstructing complex types requires having branches, and branches should be kept to a minimum because they are hard to cover properly with unit tests.
- evrimoztamur 3y ago
  These complex constructs already appear unnamed within dynamically typed programs, you just don't keep track of them at all. The inherent disarray of your unit tests must stem from the complexity of your algorithms, not from your types.