[toadstone]

I find this absurd. I don't even call them bugs when I get compiler errors. They are typos. They are trivial to fix, and I'd much rather fix them at 3pm before I've checked in the code than at 3am when it's live or 5 minutes before a presentation. If you really want to sketch a function, just make a stub that throws. It will only be 3 lines long.

[jamii]

Indeed, haskell has a standard library function for this:

    bar z = foo z + baz z
    foo = undefined
    baz = undefined

[jonnytran]

A trivial example is always trivial to fix. And you can raise an unimplemented exception in just about every language.

But what I'm talking about is usually when the code works correctly at first. Then you come along 6 months later to this code that you didn't write and know nothing about to add some new feature. Along the way, you change a few things. And that breaks something subtle. A parameter becomes nil that used to be something. Or a key in a map is no longer created.

Static type systems would say, "if a parameter or map lookup may be nil, you must wrap its uses with a case to handle it". Which makes a lot of sense in the scope of this one function.

But if I don't care about the case when the parameter is nil -- when it is, it usually means something much bigger is wrong or I simply don't care about having that feature working anymore -- why should I spend the time to track it down to handle it? It's not something trivial like a method is undefined. It's more like, a method is not defined on the specific instance of a class, whose methods get defined at runtime with metaprogramming, so it takes some tracking down. Sure when it's just you, and your entire code base is 300 lines, it doesn't matter. But when it's a large project and you have shit to get done in order for your company to get paid that day, whether or not your function handles the nil case that no one ever uses simply isn't so important.