Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NULL: The worst mistake of computer science? (2015)

lucidchart.com

Post reply on HN
Print view View original

161–170 of 377 posts

Re: NULL: The worst mistake of computer science? (2015)

#161

Post by grive »

mbel wrote: post #79
grive wrote: post #37

Earlier quoted context omitted.

This is only true in C, which is part of why C is less insane than C++. The two languages should not be conflated anymore.

This is not even true in C. 0 is a "null pointer literal" when used in pointer context, this does not imply that the actual null pointer has a value of zero.

Ah yes you are right, an interesting point however,

    6.3.2.3 Pointers
    
       3. An integer constant expression with the value 0, or such an expression cast to type void *,
          is called a null pointer constant. If a null pointer constant is converted to a pointer type,
          the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer
          to any object or function.
    
       4. Conversion of a null pointer to another pointer type yields a null pointer of that type.
          Any two null pointers shall compare equal.
Looking at the definition of NULL:

    7.17 Common definitions 
    
        3 The macros are
        
                NULL
       
          which expands to an implementation-defined null pointer constant;
Meaning that NULL is implementation defined, but is assured by the standard to compare equal to any 0-valued pointer of any type, even if it is itself another special value.

Re: NULL: The worst mistake of computer science? (2015)

#162

Post by kiriakasis »

bfrydl wrote: post #155
rusk wrote: post #92

Earlier quoted context omitted.

> All you need is a list of what width each type is. This is exactly the kind of minutiae that GP was bemoaning. > If anything it pushes code to a slightly lower level Yeah by way of higher-level abstractions ...

> This is exactly the kind of minutiae that GP was bemoaning. How is this “minutiae”? You should always know the possible range of a numeric variable or field when you create it, so why not just write what size it is? In Rust the main numeric types look like this: i32, u64, u8. You just pick the one you want.

the main numeric type is usize

Re: NULL: The worst mistake of computer science? (2015)

#163

Post by MichaelMoser123 »

Checking if the optional is present is very similar to checking for NULL values. Now if you have a nice match statement like rust and lambda functions for streams, that may make things a bit more readable.

You will still need analysis tools to check that all code paths check for none before accessing that value ..

Re: NULL: The worst mistake of computer science? (2015)

#164

Post by cultus »

jstimpfle wrote: post #65
knocte wrote: post #31

Earlier quoted context omitted.

Have you ever dealt with the Maybe(Haskell)/Option(F#) types? If not, then you don't understand what's wrong with NULL and how to easily avoid it without much work.

I find Maybe a bad idea. It forces me to write denormalized code when I know that something is not NULL. It's not possible to specify this knowledge as a data structure since data structures are static but context is dynamic. I much prefer the simple NULL sentinel that blows up like an assertion when I made a mistake. That said, there's not very often a need for NULL at all if you structure the code correctly.

If you know something can't be null, then don't use an option. Simple as that. For example, a SQL library can return a non-nullable column of String as just a String, not an Option[String]. Thus, you actually get a solid distinction that you don't get with null pointers.

There's no reason to include sentinels that will randomly blow up your program.

Re: NULL: The worst mistake of computer science? (2015)

#166

Post by cultus »

jstimpfle wrote: post #99
funciton wrote: post #72

Earlier quoted context omitted.

> I much prefer the simple NULL sentinel that blows up like an assertion when I made a mistake. Haskell, for instance, has the 'fromJust :: Maybe A -> A' function that allows you to do just that. It unpacks the Maybe typed value and throws a runtime error if it fails.

Yes. Most Haskellers will sneer at it, while personally I think it's the right thing to do because it conveys the programmer's ideas about invariants. But syntactically an explicit unwrapping function is still a lot of noise. Simple null pointers as we have in C, with an unmapped segment at address zero so that it throws a segmentation fault, are much better.

I haven't drank all my coffee yet this morning, but are you saying that throwing a segfault can be a good thing?

Either you unwrap the Option, or you have to remember to do an manual null check. The second option is more verbose.

Re: NULL: The worst mistake of computer science? (2015)

#167

Post by steveklabnik »

kiriakasis wrote: post #162
bfrydl wrote: post #155

Earlier quoted context omitted.

> This is exactly the kind of minutiae that GP was bemoaning. How is this “minutiae”? You should always know the possible range of a numeric variable or field when you create it, so why not just write what size it is? In Rust the main numeric types look like this: i32, u64, u8. You just pick the one you want.

the main numeric type is usize

That’s not correct, it’s i32. usize has a specific purpose: when you need a length of something in memory.

Re: NULL: The worst mistake of computer science? (2015)

#168

Post by lmm »

bunderbunder wrote: post #149

You know who works on a platform with NULL but doesn't have quite so many problems with it? DBAs. There's some need to draw a distinction between the basic idea of NULL, and the way that NULL has been implemented in most high-level programming languages. In most RDBMSes, values can't be null unless you say they are. Sometimes explicitly, as in table definitions, sometimes implicitly, when you select a JOIN type. Eith…

NULL in SQL is a notorious source of errors and confusion (particularly when it comes to e.g. tri-state boolean logic). It certainly can come from nowhere and surprise you - if anything the behaviour is even worse than in Java or C#. So I don't think there's anything to learn from there. (Rather what modern languages should have done - and increasingly do - is follow ML practice and avoid null entirely, implementing option types as ordinary library types where the programmer explicitly wants to represent absence).

Re: NULL: The worst mistake of computer science? (2015)

#170

Post by lmm »

captainmuon wrote: post #107

I've made my peace with null. Null is basically just an implicit assert(valid(x)) before every time you call a method on x. Similary, I think of exceptions as explicit "crash-unless-caught" commands. If you write your program with the "blow up early" mentality anway, or use static checking tools and a bit of discipline, I've found that null looses it's terror.

Sure, null can be a non-problem for the low, low price of 3 or 4 extra lines on each function. But those extra lines distort your program architecture, pulling you away (perhaps without even noticing) from short, composable functions.
Post reply on HN