3 ms·

This is turning into an argument for strong typing, but, in light of your original claims, only for external inputs, not for internal interfaces - but if it is

• marginalia_nu 5y ago
  In some cases, say when you work very close to a business domain, this may very well be a good thing. But for larger applications, especially that do low-level stuff, the tradeoff is cluttering your namespace with single use parameters. You quickly run into scaling problems. It's exactly the same reason bindly following "textbook" OOP design is a bad idea. Unless you're able to do some very prescient upfront design of a large part of your application, you're in for a big headache later.
  • mannykannot 5y ago
    > But for larger applications, especially that do low-level stuff, the tradeoff is cluttering your namespace with single use parameters. What does this mean? I have not figured out any way to interpret this, such that it is a consequence of choosing strong typing. Your second paragraph is more of the straw man that we are discussing in an adjacent thread.
    • marginalia_nu 5y ago
      I mean that you need to assign each type a distinct name, and in many programming languages, the namespace for types is effectively global. If you add say a thousand types for all the things combinations of things you may want to represent, then you've effectively added the need to have a thousand type names.
      • mannykannot 5y ago
        That is merely being explicit about what is implicit otherwise. When you are being explicit, there is at least the possibility that these declarations could be scoped - and, in many languages, this is something you can do.