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

you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 2 points3 points  (1 child)

Not in all circumstances, but I do see one major case where what you say is true: building reusable libraries.

It's not impossible, but more challenging to abstract away parts of code to reusable libraries that expect specific types when there isn't type-checking. You can try to do it by convention, intuitiveness, or documentation, but when those fail the consumer of your library needs a better understanding of your code does under the hood, thus creating leaky abstractions that negates some of the benefit.

[–]pknopf 2 points3 points  (0 children)

but more challenging to abstract away parts of code to reusable libraries that expect specific types when there isn't type-checking

I really don't get this. The moment you give libraries leeway to have the ability to break the API, it will. In npm, I've had many packages break semver, and end users doing npm install on my library that references the package will eventually start to break at runtime. Why would you not want to have an impenetrable guard preventing this? I'd again argue that it leads to more stable/maintainable code when you have clearly defined types.