4 ms·

It's certainly a language design decision, but as I've been using more powerful type systems I'm coming to the conclusion that not using a language with a good

It's certainly a language design decision, but as I've been using more powerful type systems I'm coming to the conclusion that not using a language with a good type system for any project intended to be maintainable in the long term is just bad engineering.

chrisco255 8y ago
Type systems do nothing to save you from making unmaintainable code. How many awfully engineered, slow to iterate, legacy monolith systems with convoluted OOP architectures were built in Java or .NET? All that type safety was a mere crutch for deeply nesting state in 14 layers of inheritance. I've worked on enterprise systems that take 10x as long to ship a feature in than something like Node. Nevermind that it's easy to add types to JS these days if you really want them. How you architect a system and manage state (and how simple you keep it) has far bigger implications than types.
- filleduchaos 8y ago
  Yes, this is why TypeScript and Flow never got off the ground, and why PHP, Python and Ruby are all definitely not adding static type checking.
  - chrisco255 8y ago
    Adding TS won't magically make your code base maintainable. TS/Flow are both successful, great projects for adding types. They help with tooling, and you spend less time inspecting the underlying code. But now you also have to maintain those types when things change. I work on a very large JS code base and the number of type errors I see is pretty rare. That being said, I'm not opposed to types. It's just not the panacea that people claim it is. Good tests and simple architectures will do more to make a code base maintainable than types will.
- jayshua 8y ago
  Yes, it's clearly true that architecture plays a major role. I've worked on one of those inheritance towers before. But adding/changing/removing code in a dynamically typed language always leaves me worried that I've missed something. The only notice I have in such systems that I have missed something is a production runtime exception. Sure it takes longer up front to add a feature. And it's typically harder than in a dynamic language. My point is that taking the convenience of an untyped language is usually a poor/lazy architectural decision.
  - _Tev 8y ago
    > adding/changing/removing code in a dynamically typed language always leaves me worried that I've missed something. Looking from the other side, this seems like "static typing gives me illusion of safety, and I miss it in dynamic languages". Sure, it might be justified for large projects in the long run, but > taking the convenience of an untyped language is usually a poor/lazy architectural decision. sounds like not understanding (or unwilligness to use?) trade-offs involved, due to personal preference. I don't like these (unintentional?) claims of superiority based purely on personal preference. Static typing is just a tool, with its pros&cons.

chrisco255 8y ago

Type systems do nothing to save you from making unmaintainable code. How many awfully engineered, slow to iterate, legacy monolith systems with convoluted OOP architectures were built in Java or .NET? All that type safety was a mere crutch for deeply nesting state in 14 layers of inheritance. I've worked on enterprise systems that take 10x as long to ship a feature in than something like Node. Nevermind that it's easy to add types to JS these days if you really want them. How you architect a system and manage state (and how simple you keep it) has far bigger implications than types.

filleduchaos 8y ago
Yes, this is why TypeScript and Flow never got off the ground, and why PHP, Python and Ruby are all definitely not adding static type checking.
- chrisco255 8y ago
  Adding TS won't magically make your code base maintainable. TS/Flow are both successful, great projects for adding types. They help with tooling, and you spend less time inspecting the underlying code. But now you also have to maintain those types when things change. I work on a very large JS code base and the number of type errors I see is pretty rare. That being said, I'm not opposed to types. It's just not the panacea that people claim it is. Good tests and simple architectures will do more to make a code base maintainable than types will.
jayshua 8y ago
Yes, it's clearly true that architecture plays a major role. I've worked on one of those inheritance towers before. But adding/changing/removing code in a dynamically typed language always leaves me worried that I've missed something. The only notice I have in such systems that I have missed something is a production runtime exception. Sure it takes longer up front to add a feature. And it's typically harder than in a dynamic language. My point is that taking the convenience of an untyped language is usually a poor/lazy architectural decision.
- _Tev 8y ago
  > adding/changing/removing code in a dynamically typed language always leaves me worried that I've missed something. Looking from the other side, this seems like "static typing gives me illusion of safety, and I miss it in dynamic languages". Sure, it might be justified for large projects in the long run, but > taking the convenience of an untyped language is usually a poor/lazy architectural decision. sounds like not understanding (or unwilligness to use?) trade-offs involved, due to personal preference. I don't like these (unintentional?) claims of superiority based purely on personal preference. Static typing is just a tool, with its pros&cons.