4 ms·

I've always thought it bizarre that many languages with static typing allow arbitrary values to be null. It's par for the course with dynamic typing, of course.

• tome 16y ago
  He did apologise for it: http://en.wikipedia.org/wiki/C._A._R._Hoare#Quotes http://en.wikipedia.org/wiki/C._A._R._Hoare#Quotes
• _delirium 16y ago
  It's a common design change in C dialects, but none seem to have really caught on. For example, Cyclone has both nullable and non-nullable pointers (http://cyclone.thelanguage.org/wiki/Cyclone%20for%20C%20Programmers#Pointers http://cyclone.thelanguage.org/wiki/Cyclone%20for%20C%20Prog...).
  • eelco 16y ago
    I like Objective-C's solution, where one can just send messages to nil. The practical result when writing code is pretty close to using the Maybe monad applicatively (i.e., write your code like the value is never nil, only check for nil when it's part of the (bigger) logical flow in your code.)
    • masklinn 16y ago
      The problem is that, though operations flow better, it's a good way to hide bugs until you've completely lost its context, and then finding out its source is a pain unless you have a backtracking debugger. An option type, especially one which allows you to lift operations into it (as Haskell's does) is a much better solution as it gives the programmer the choice of behavior: does he not care and just want to keep his option, or does he want to know and unwrap the value within the container? Objective-C allows half of this, but it's generally the wrong half. Most other statically typed languages allow neither solution and are therefore broken.