4 ms·

Any decent programmer working in a dynamically typed language will implement pre-checks (and maybe even post-checks) to validate types at run-time. Some dynami

• kasey_junk 13y ago
  I am strongly anti-dynamically typed for this reason. I spent 5 years in a dynamic language writing so many asserts/unit tests to handle basic compiler type cases that it more than invalidated any argument for conciseness or time to market.
  • andybak 13y ago
    Did you consider not doing that, then? Plenty of code-bases don't and the sky doesn't fall in.
• emn13 13y ago
  That just doesn't happen. People don't check pre-conditions and, frankly, they're right not too: checking all the ways your input might be wrong is often very wordy (much more so than static types), and usually slow. Not to mention that it's not at all trivial to check preconditions; if your program has any kind of duck-typing or dynamic dispatch it's often very hard to check more than the immediately obvious (can it quack?), and that check is often furthermore redundant because you'll use the function. Worst of all, this is extra code that itself can have bugs (and it's code that's likely to see almost no usage in production since you don't make a habit of passing invalid input). Of course, you could check that extra code with extra unit tests... If you want to check preconditions rigorously and pervasively, use a statically typed language (and be a little realistic in what you can check). If you want short code without ceremony, use a dynamic language and don't uglify it with more boilerplate than the worst statically typed language. I've seen that kind of code in ruby, and it's really not a joy. Real life in a dynamic language: people introduce some checks in some high-risk functions, and call it a day. And that's... Just Fine.
  • tel 13y ago
    It's also harder to establish checking boundaries in a dynamic language. If you honestly claim that someone both (a) writes pre-/post-condition checks on all functions and (b) compartmentalizes functionality sanely then you've got an exponential blowup in type verification. So in practice both (a) and (b) are weakened. Usually it's a whole lot of (a) and a little bit of (b). You can reduce the problem by establishing domains, but that limits reusability and requires its own kind of stringent documentation and discipline to handle.
• pjmlp 13y ago
  > Any decent programmer ... That is something that you won't find that often in the enterprise space. Which is actually where most large codebases tend to exist.
  • AnimalMuppet 13y ago
    Yes, but that means that no language can save you.
    • pjmlp 13y ago
      True, but some help better than others the herd to control. :)
  • bruceboughton 13y ago
    >> That is something that you won't find that often in the enterprise space. What utter rubbish. What you won't find that often in the enterprise space is dynamic languages, so your statement is irrelevant as well.
• awj 13y ago
  > Any decent programmer Your "decent programmer" is about as common as a Sufficiently Smart Compiler.