2 ms·

> ...is a roundabout way of saying, "Java", or other static languages with a similarly anemic type system... I agree. In my experience, it's how the median dev

> ...is a roundabout way of saying, "Java", or other static languages with a similarly anemic type system... I agree. In my experience, it's how the median developer writes code, though. Even in more flexible languages they'll reach for type hierarchies and abstract base classes. I've seen people create these things in languages like Lua and Javascript that don't really need them. I think TDD-like approaches make the case for other approaches more clear, for what it's worth.

bunderbunder 9y ago
Further agreement. I haven't looked at a textbook on programming recently, but I'm worried that the standard is still to actively teach new developers to program this way, even though we've _known_ for decades that towering piles of subclasses invariably collapse under their own weight. That said, I still wouldn't lay this tendency for damaged design at the feet of static typing in general. Not when some of the most vigorous arguments for static typing tend to come out of language communities that don't have subclassing in the first place (e.g., Haskell), and when (as you point out) similar mistakes are just as often made in dynamic languages. Dynamic languages are certainly more forgiving about poor design, but whether that's a good thing is yet another fun debate.
- humanrebar 9y ago
  I don't blame statically typed languages. But, yeah, they are a bit more unforgiving if you need to refactor your way out of that mess is all.
  - echlebek 9y ago
    Static languages make refactoring easier, not harder. The more information you have at compile time, the more automated tooling can do for you.
    - humanrebar 9y ago
      The more compile time information you have, the greater coupling you have as well. Make User subclass Entity for polymorphism reasons and now taking a User parameter makes your business logic depend explicitly on your ORM.
      - bunderbunder 9y ago
        But now the conversation's going in a circle. In a decent static language, you should never have to run into that particular problem. Assuming it's a modern static OO language, your business logic should depend on a User interface, so that it never has to take a dependency on implementation details like that. Even if User was a class beforehand, you can easily extract an interface at a later date, when you find that you need to avoid some tight coupling. Don't blame the gun for what happens when you point it toward your foot and pull the trigger.

bunderbunder 9y ago

Further agreement. I haven't looked at a textbook on programming recently, but I'm worried that the standard is still to actively teach new developers to program this way, even though we've _known_ for decades that towering piles of subclasses invariably collapse under their own weight. That said, I still wouldn't lay this tendency for damaged design at the feet of static typing in general. Not when some of the most vigorous arguments for static typing tend to come out of language communities that don't have subclassing in the first place (e.g., Haskell), and when (as you point out) similar mistakes are just as often made in dynamic languages. Dynamic languages are certainly more forgiving about poor design, but whether that's a good thing is yet another fun debate.

humanrebar 9y ago
I don't blame statically typed languages. But, yeah, they are a bit more unforgiving if you need to refactor your way out of that mess is all.
- echlebek 9y ago
  Static languages make refactoring easier, not harder. The more information you have at compile time, the more automated tooling can do for you.
  - humanrebar 9y ago
    The more compile time information you have, the greater coupling you have as well. Make User subclass Entity for polymorphism reasons and now taking a User parameter makes your business logic depend explicitly on your ORM.
    - bunderbunder 9y ago
      But now the conversation's going in a circle. In a decent static language, you should never have to run into that particular problem. Assuming it's a modern static OO language, your business logic should depend on a User interface, so that it never has to take a dependency on implementation details like that. Even if User was a class beforehand, you can easily extract an interface at a later date, when you find that you need to avoid some tight coupling. Don't blame the gun for what happens when you point it toward your foot and pull the trigger.