Hacker News Reader

> It doesn't if the systems are well-designed sytems, comprised of loosely-coupled components

I've been going down a similar line of thought. But I went the other direction. That perhaps in "poorly designed" systems where there is lots of coupling, static typing at least gives you the "maintenance" benefit that is one of the bigger justifications that the static type apologist tends to give. You actually hear this a lot: "in large systems, static typing is a must..."

So it's interesting to me that you're going the other way and saying that actually in big, messy systems that static types may hurt you. That's not a common position.

When I walk through some of the big problems in "poorly designed" systems it almost always comes down to coupling: I can't touch one part of the system without having an effect on other parts of the system.

Interestingly, Rich Hickey criticizes the common static typer's idioms (like pattern matching and ADTs) as coupling. And he's right. What always surprises me though is that the static typer doesn't disagree -- they look at this coupling as a feature! They usually say something along the lines of "I choose static typing because if I change my Person class, then the compiler reminds me of all the places in my code that I need to go fix." What's remarkable about this is that it's not a reminder...it's an obligation that your choices plus the compiler are burdening you with: you must go update all those places in the code. This is the very definition of coupling.

There is a way to architect code such that you don't have to revisit 100 places in your architecture when some new data model decision is made/discovered. There is a way to build systems wherein you only have to touch one place in your code when some new feature or data information is needed.

View on HN

class Person { age: number constructor (age: number) { this.age = age } } class Cat { age: number constructor (age: number) { this.age = age } } const printNextAge = (thing: { age: number }) => { console.log(thing.age + 1) } // These all work printNextAge(new Person(12)) printNextAge(new Cat(23)) const someRandomObject = { age: 10, colour: 'green', weight: 'heavy' } printNextAge(someRandomObject) // These don't: const lady = { name: 'carol' } printNextAge(lady) // error TS2345: Argument of type '{ name: string; }' is not assignable to parameter of type '{ age: number; }'. // Property 'age' is missing in type '{ name: string; }'. const caveman = { age: 'stone' } printNextAge(caveman) // error TS2345: Argument of type '{ age: string; }' is not assignable to parameter of type '{ age: number; }'. // Types of property 'age' are incompatible. // Type 'string' is not assignable to type 'number'.