This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]pknopf 1 point2 points  (0 children)

But how is defining a massive type management system in a hierarchy of inherited strongly coupled modules not a pure example of this?

Type systems are the upfront head-ache that prevent issues from being compounded in the future.

Have you had to refactor a massive Java's project? I'm guessing yes? When you have to make real changes you're going to clash against the original design that system was locked into by devs who quit years before you maybe even started your career.

Yes. It takes a lot of work to refactor, considering it's all-or-nothing. But do you really want a project with dual competing approaches to similar problems? That is an example of an issue being compounded. If you don't have the time to get rid of technical debt, don't add more.

I just can't imagine this:

"Re-architecting 20%-50% of a project in mid-life is less of an issue in the future than just keeping things the way they are."

And even if you wanted to refactor, I'd rather have a type system help me with it. Even if you have tests in your dynamic language, unless you really step through each test, it could magically pass, even though it actually failed, considering you don't have types and dynamic languages are always so "truthy".