3 ms·

> It just makes everything harder in the long term. Opinions. I'd gladly refactor a C# legacy monster because I can follow the compiler errors and reason about

> It just makes everything harder in the long term. Opinions. I'd gladly refactor a C# legacy monster because I can follow the compiler errors and reason about the shape of the types and how they interact in an abstract, codeless way. I can modify 200+ files and not lose track of what I'm doing. I can apply the latest language features to make the code more concise and expressive while preserving the semantics. I can use my IDE to modify every single reference to some type or object across the entire solution in a couple of keystrokes without worrying that my search and replace regex will match something it shouldn't. I can simplify and generalize redundancies. I can transform everything in my head and make sure it's internally consistent. I can even use reflection to do advanced metaprogramming and make sure that it, too, is consistent (with a couple of tests). If it compiles, chances are it's going to work. The more static typing, the better, because that means that most of the logic is baked in the abstractions and I don't have to run the debugger. I would never refactor a legacy Javascript application because I'm not a masochist. There are many juniors who don't yet know what a pain it is to work on large dynamic projects so I'll let them have all the fun while I use my time productively. I haven't done a null check in years (in my personal projects; at my workplace they don't even know what an option type is). But I'll take Prolog. It's dynamic, but unification is basically type theory anyway. You can declare all your constraints and reason about them clearly. As God intended for us applied mathematicians. So your claim that static typing makes things harder in the long term is alien to me. The real issue is that companies are afraid of refactoring because the client doesn't see the immediate benefit, so they simply don't do it, and then 10 years later they just redo the project from scratch in the latest shiny language (while reinventing the whole domain mapping layer because the old engineers were probably idiots since they wrote such unmaintanable code -- let's ignore the fact that they, too, never had time to refactor and dogfood).

Groxx 2y ago
My claim isn't that static typing is harder in general: >... it tends to mean enormous pain when making small obvious fixes to past mistakes, and you really don't want to block those. It just makes everything harder in the long term. It's that not making fixes is harder in the long term. That means either manual migrations or automated ones (e.g. API-compatible ones are trivially automation-friendly). And the more difficult you make the migration, the less likely people are to migrate (which I don't think is a contentious claim). Static typing is great, but it does generally mean more full-automation-unfriendly migrations, because it's forcing you to see and make decisions on more kinds of changed assertions. Generally that's a very good thing, but it does add some struggles that looser typing can simply ignore and sometimes still succeed.

Groxx 2y ago

My claim isn't that static typing is harder in general: >... it tends to mean enormous pain when making small obvious fixes to past mistakes, and you really don't want to block those. It just makes everything harder in the long term. It's that not making fixes is harder in the long term. That means either manual migrations or automated ones (e.g. API-compatible ones are trivially automation-friendly). And the more difficult you make the migration, the less likely people are to migrate (which I don't think is a contentious claim). Static typing is great, but it does generally mean more full-automation-unfriendly migrations, because it's forcing you to see and make decisions on more kinds of changed assertions. Generally that's a very good thing, but it does add some struggles that looser typing can simply ignore and sometimes still succeed.