3 ms·

I don't understand why people still think static types makes programming slower. If anything they make me quite a bit faster. Especially if the problem domain i

I don't understand why people still think static types makes programming slower. If anything they make me quite a bit faster. Especially if the problem domain is shifting. Without types I have to spend a lot of time hunting down forgotten parts of the code where I didn't apply a refactor. With types the compiler just tells me and I can fix those errors in record time.

throwaway894345 5y ago
I agree. The same people who argue that types make programs slower to write and harder to maintain also argue (incorrectly) that tests have all of the benefits of types and then some. But if you’re writing lots of tests to compensate for types (and indeed I hear many dynamic typing advocates argue for exactly this) then your code is far harder to change than it would be if you just used types in the first place (and for the same reasons that it’s easier to write typed code and a few tests rather than i typed code and lots of tests). Not only does it not make sense in theory, but in my 15 years with Python and 10 years with Go, it bears out in practice. I’m much more productive in Go because of the tooling and confidence that follow from static types, and that delta only increases as the project grows in lines of code, contributors, and/or age.
- Fannon 5y ago
  A really good talk on the myth of "testing makes static types unnecessary" from Gary Bernhardt (Wat Talk) https://www.destroyallsoftware.com/talks/ideology https://www.destroyallsoftware.com/talks/ideology
atty 5y ago
As someone who works on a decently complex project (essentially a graph execution engine for multi-node, data-parallel+model-parallel deep learning models), writing it in python is not really ideal. Python is great for the end user, but I’d be far more efficient if the code base was in C++ with some Python bindings. I think my conclusion after about 10 years of programming is this: the larger and more complicated a project is, the more I as a maintainer/implementer benefit from constraints in the language itself (where by constraints I mean things like compiler type checking, or Rusts borrow checker, even if I haven’t had a reason to use Rust yet). The more work the compiler/interpreter does, the less I have to explicitly keep in my head.
ferdowsi 5y ago
It's because when developers are handed an abstraction like static types, they will tend to go as far as possible to create overengineered solutions using that tool, creating complexity that becomes a problem in its own right. TypeScript in particular has been adding features at far too fast a pace, creating wild amounts of complexity in the type system. This is from one popular type library. Type theorists may enjoy this. I personally would not if I am onboarding to a new codebase and trying to understand this at a glance. export type CamelCasedPropertiesDeep<Value> = Value extends Function ? Value : Value extends Array<infer U> ? Array<CamelCasedPropertiesDeep<U>> : Value extends Set<infer U> ? Set<CamelCasedPropertiesDeep<U>> : { [K in keyof Value as CamelCase<K>]: CamelCasedPropertiesDeep<Value[K]>; };
- __float 5y ago
  With a powerful type system, I think you tend to see examples of libraries that fall along a spectrum of how deep into the type system they're willing to go. This is an example of the farther end, but "ideally" as a user of the library, the actual complexity would be hidden, and it "just works" for you.

throwaway894345 5y ago

I agree. The same people who argue that types make programs slower to write and harder to maintain also argue (incorrectly) that tests have all of the benefits of types and then some. But if you’re writing lots of tests to compensate for types (and indeed I hear many dynamic typing advocates argue for exactly this) then your code is far harder to change than it would be if you just used types in the first place (and for the same reasons that it’s easier to write typed code and a few tests rather than i typed code and lots of tests). Not only does it not make sense in theory, but in my 15 years with Python and 10 years with Go, it bears out in practice. I’m much more productive in Go because of the tooling and confidence that follow from static types, and that delta only increases as the project grows in lines of code, contributors, and/or age.

Fannon 5y ago
A really good talk on the myth of "testing makes static types unnecessary" from Gary Bernhardt (Wat Talk) https://www.destroyallsoftware.com/talks/ideology https://www.destroyallsoftware.com/talks/ideology

atty 5y ago

As someone who works on a decently complex project (essentially a graph execution engine for multi-node, data-parallel+model-parallel deep learning models), writing it in python is not really ideal. Python is great for the end user, but I’d be far more efficient if the code base was in C++ with some Python bindings. I think my conclusion after about 10 years of programming is this: the larger and more complicated a project is, the more I as a maintainer/implementer benefit from constraints in the language itself (where by constraints I mean things like compiler type checking, or Rusts borrow checker, even if I haven’t had a reason to use Rust yet). The more work the compiler/interpreter does, the less I have to explicitly keep in my head.

ferdowsi 5y ago

It's because when developers are handed an abstraction like static types, they will tend to go as far as possible to create overengineered solutions using that tool, creating complexity that becomes a problem in its own right. TypeScript in particular has been adding features at far too fast a pace, creating wild amounts of complexity in the type system. This is from one popular type library. Type theorists may enjoy this. I personally would not if I am onboarding to a new codebase and trying to understand this at a glance. export type CamelCasedPropertiesDeep<Value> = Value extends Function ? Value : Value extends Array<infer U> ? Array<CamelCasedPropertiesDeep<U>> : Value extends Set<infer U> ? Set<CamelCasedPropertiesDeep<U>> : { [K in keyof Value as CamelCase<K>]: CamelCasedPropertiesDeep<Value[K]>; };

__float 5y ago
With a powerful type system, I think you tend to see examples of libraries that fall along a spectrum of how deep into the type system they're willing to go. This is an example of the farther end, but "ideally" as a user of the library, the actual complexity would be hidden, and it "just works" for you.