> The best approach I ever saw to using Haskell at scale was to severely disallow any complex type system feature, like even disallowing lensing or custom type classes. Just ruthlessly stick only to basic language features and module oriented design.
I agree. It's not unlike what you can do with reflections and other dynamic features of dynamicaly-typed languages. So it's not a problem of static typing itself. It's a problem of taking a feature of the language and strangling the code with it.
I had to do some refactors of JS code where everything was a shapeless objects with random fields, as the language doesn't even nudge the developer into considerations like keeping consistent "shapes" of data. Had similar experiences with some Python code, where I had to fight both data types fuzziness, reflective-features inventions (hello __getattr__!) and OOP over-abstracted nonsense at the same time.
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...
IMO, static typing gets blamed for problems that are usually caused by OOP: complexity caused by needless abstractions (mostly inheritance taxonomies).
> “ 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.
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.
> “ 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.
I agree. It's not unlike what you can do with reflections and other dynamic features of dynamicaly-typed languages. So it's not a problem of static typing itself. It's a problem of taking a feature of the language and strangling the code with it.
I had to do some refactors of JS code where everything was a shapeless objects with random fields, as the language doesn't even nudge the developer into considerations like keeping consistent "shapes" of data. Had similar experiences with some Python code, where I had to fight both data types fuzziness, reflective-features inventions (hello __getattr__!) and OOP over-abstracted nonsense at the same time.
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...
IMO, static typing gets blamed for problems that are usually caused by OOP: complexity caused by needless abstractions (mostly inheritance taxonomies).