Comment by nostrademons | Hacker News Reader

Comment by nostrademons | Hacker News Reader

Parent Full thread

You could perhaps use it to say stuff about Haskell or ML vs. Ruby or Python, but not about Java or C++.

The particular errors Carmack talks about are all holes in the type system - they're areas where the type system of C/C++ is unsound (as in the type-theory definition, not the colloquial definition). Null pointer exceptions don't exist in Haskell, because null pointers don't exist; you have to explicitly use a Maybe type. Printf errors do (at least with Text/Printf), but there's a lot of research on dependent types to solve specifically that error.

Again, though, it's a tradeoff. Haskell lets you find a lot of errors at compile time, but the tradeoff is that you spend much more time figuring out why your program won't compile. For a lot of software, you're better off shipping with bugs than not shipping at all. Particularly for exploratory software, it makes more sense to build something that works for your demo just to see if it's useful than build something for everyone that nobody wants to use. Specs that don't meet customer needs are just as buggy as code that doesn't meet the spec.

You can use undefined, the nearest equivalent to null in Haskell, anywhere you like and it is just as bad as using null! However, typically you don't because as you point out Maybe is a better alternative.

Shhhhh. That's probably a good thing not to say loudly, or people will try to use it. (I didn't know about it, so it obviously has not hurt me.)

`undefined` does not behave like a null though, it behaves much like `error` (it's basically `assert False`), it lets code typecheck but it will instantly throw an exception when executed.

It's usually used to stub code during development in TDD-type scenarios:

    myFunction = undefined

    myOtherFunction foo = doSomethingWith value
        where value = myFunction foo

will typecheck letting you fail your tests.

You can't have `undefined` "pass through" your code the way `null` does.

Sure you can, it doesn't error until it's evaluated, and haskell is lazy, so the failure can occur some distance from the original undefined, and can occur only some of the time.

> You can use undefined, the nearest equivalent to null in Haskell

I'm not sure you can say that. `undefined` is a case of `error`, so it will blow up any time it's encountered (it's often used to stub code) not just when you try to use it, it's closer to putting a `throw` than to putting a `null`.

Don Stewart on undefined vs. null: http://stackoverflow.com/a/3963464/17439

Reply on news.ycombinator.com