Null pointer: The villain.

Tony Hoare famously called null references his "billion-dollar mistake" during a presentation at QCon London in 2009. His remarks have inspired many programming languages to devise complex solutions to this problem, such as Option/Maybe types or Result types. While these approaches aim to reduce runtime errors, they often come with trade-offs, such as increased cognitive load and reduced readability.

The truth is, null references themselves aren’t inherently flawed. Hoare was simply the first to give a name to the concept of a pointer with a 0 value. If he hadn’t, someone else would have. The real problem lies not in the null value itself but in how it’s used.

What's the Problem with Null Pointers?

The issue arises when a single value, such as null, is used to multiplex multiple concerns:

• Legitimate value: A valid pointer to data.
• Error condition: An indication of failure.
• Unknown state: Signaling uninitialized or absent data.

This overload of responsibilities creates ambiguity. For example, in a typical null pointer scenario, the value 0 (or null) is used to signify an invalid state, while any other value is assumed valid. This approach singles out only one value as invalid, leaving the validity of all others uncertain.

The Proper Solution

The solution to this problem is straightforward: use a separate indicator to signal whether a pointer is valid. A simple Boolean value can clarify whether the pointer can be safely dereferenced or not. This avoids the ambiguity of multiplexing multiple concerns into a single variable.

In Ardent, null pointers are handled in two ways:

1. Dedicated Error Flow

Ardent separates error handling from the main logic flow. Errors trigger a dedicated flow where the pointer is assumed invalid for all values, not just 0. This guarantees that pointers will always be valid in the main flow unless explicitly checked otherwise. There’s no reliance on "magic values" like null to signal errors.

Example:

This approach ensures that error handling is isolated, making the code more predictable and easier to reason about.

2. Explicit Validation with Tuples

The second approach involves using tuples to separate state indicators from actual values. A Boolean value explicitly signals whether the pointer is valid, eliminating the ambiguity of overloaded variables.

Example:

 

Here, isvalid explicitly indicates whether the pointer (funky_obj) can be used. This approach avoids the pitfalls of null references by keeping concerns separate.

 

By addressing the real problem—multiplexing multiple concerns into a single variable—Ardent’s approaches make null pointers less problematic:

1. Error Isolation: Dedicated error flows remove the need for checks scattered throughout the code.
2. Explicitness: Boolean indicators provide a clear and unambiguous signal for validity.
3. Readability: The code remains straightforward and easy to follow, avoiding the cognitive load associated with complex type systems like Option or Result.

Conclusion

Null references are actually the only reliable state, all other values for those references are questionable.

Ardent’s solutions show that pointers can be managed effectively without resorting to overly complex abstractions. By separating error conditions and using explicit indicators, Ardent avoids the ambiguity that has plagued developers for decades.

What are your thoughts on handling null references? Have you faced issues with null pointers in your own projects? Share your experiences in the comments below!