4 ms·

> “ IMO, static typing gets blamed for problems that are usually caused by OOP: complexity caused by needless abstractions (mostly inheritance taxonomies).” Th

by mlthoughts2018 6y ago

> “ IMO, static typing gets blamed for problems that are usually caused by OOP: complexity caused by needless abstractions (mostly inheritance taxonomies).” That’s fair, since most of the issues are caused by poor attempts to create “concepts” that match a problem domain and encode them in the type system, which is a very OO mentality. But it’s not exclusive to OO, you can get the same problems in functional languages or plain module languages too if you go too far with type system designs. But functional languages offer plenty of ways to successfully avoid it too. Nonetheless, I still argue that safety & correctness should be treated like resources, not absolutes. Safety and correctness are things you want more or less of, depending on costs (in terms of extensibility, extra code, rigidity, difficulty to onboard new people to conceptual complexity, etc.) no different than making memory trade offs for better runtime or vice versa. Languages should facilitate thinking of enforced correctness as a gradual concept, like gradual typing in Python, so the programmer has freedom to make these choices. Languages should not dictate one way (eg always enforcing type safety), and especially not at the cost of extra code or complexity. > “ One way or another, in larger teams/projects dynamic typing just doesn't scale. Type system works like a most basic documentation / developer aid / consistency encouragment, even if it is pushed into complexity nightmare.” > “I don't think I've ever even seen a reasonably well working large project in a dynamically-typed language...” My experience is the exact opposite. I’ve never seen a large codebase that is statically typed which doesn’t turn into a complete ball of mud with overlapping type system concepts that bring extensibility and innovation to a grinding halt and cause months of delays to adjust for even the simplest changes to business requirements. Meanwhile the two largest code bases I’ve ever worked in (one was the entire search engine implementation of a giant tech company, the other was a document editing CMS system also at a large tech company) were both 100% Python on the backend, both on the order of 500k to 1MM lines of code, and working with them was very enjoyable. Plenty of tech debt and headaches like any big enterprise codebases, but none of the “grinding halt“ - “we can’t do anything like this because our earlier brittle commitments to certain type system designs would have to be fundamentally refactored to allow it” - sorts of existential, death of velocity kind of problems.

dpc_pw 6y ago
Interesting. Seems we have very opposite experiences. I definitely agree that one can paint themselves into a static-typing corner where refactoring becomes painful (but as I said, usually because of OOP). Also in big projects care needs to be taken to keep compilation times manageable. > Languages should facilitate thinking of enforced correctness as a gradual concept, like gradual typing in Python, so the programmer has freedom to make these choices. Depends on the domain. In web-based non-critical applications, maybe. If there's a bug, users gets and error etc. reports it, you push a fix to prod and things are usually OK. In things I mostly worked with (embedded, automotive, on-premise appliances, systems, p2p, finance), the cost of debugging and fixing small bugs is far too high. I am supporter of gradual typing though, if someone wants to go with dynamic typing route.
- mlthoughts2018 6y ago
  > “ Depends on the domain. In web-based non-critical applications, maybe. If there's a bug, users gets and error etc. reports it, you push a fix to prod and things are usually OK. In things I mostly worked with (embedded, automotive, on-premise appliances, systems, p2p, finance), the cost of debugging and fixing small bugs is far too high.” I disagree here. The main systems I worked on using dynamic typing and treating safety and correctness like resource trade-offs have been high-frequency trading, banking, ecommerce fraud detection, and real time image processing - all cases where failures are costly and stakes were high. In fact when the stakes are high, it’s even more critical to use gradual notions of safety & correctness, because you even more urgently need to put the trade off decisions in the hands of engineers and business / product leaders.

dpc_pw 6y ago

Interesting. Seems we have very opposite experiences. I definitely agree that one can paint themselves into a static-typing corner where refactoring becomes painful (but as I said, usually because of OOP). Also in big projects care needs to be taken to keep compilation times manageable. > Languages should facilitate thinking of enforced correctness as a gradual concept, like gradual typing in Python, so the programmer has freedom to make these choices. Depends on the domain. In web-based non-critical applications, maybe. If there's a bug, users gets and error etc. reports it, you push a fix to prod and things are usually OK. In things I mostly worked with (embedded, automotive, on-premise appliances, systems, p2p, finance), the cost of debugging and fixing small bugs is far too high. I am supporter of gradual typing though, if someone wants to go with dynamic typing route.

mlthoughts2018 6y ago
> “ Depends on the domain. In web-based non-critical applications, maybe. If there's a bug, users gets and error etc. reports it, you push a fix to prod and things are usually OK. In things I mostly worked with (embedded, automotive, on-premise appliances, systems, p2p, finance), the cost of debugging and fixing small bugs is far too high.” I disagree here. The main systems I worked on using dynamic typing and treating safety and correctness like resource trade-offs have been high-frequency trading, banking, ecommerce fraud detection, and real time image processing - all cases where failures are costly and stakes were high. In fact when the stakes are high, it’s even more critical to use gradual notions of safety & correctness, because you even more urgently need to put the trade off decisions in the hands of engineers and business / product leaders.