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

Celebrating Tony Hoare's mark on computer science

bertrandmeyer.com

Post reply on HN
Print view View original

11–20 of 39 posts

Re: Celebrating Tony Hoare's mark on computer science

#11

Post by NovemberWhiskey »

mrkeen wrote: post #7

> First, the null pointer is essentially inevitable if you want to model the world, which has references (things containing denotations of other things). I took major exception to this. The real world doesn't have non-things, and references do not demand to refer to non-things. If your domain does actually have the concept of null, just make a type for it. Then you won't accidentally use a 6 or a "foo" where a null w…

The real world is full of relationships that may or may not exist. What’s the referent of “my spouse” if I’m unmarried?

Is your point here that every pointer type for which this can be the case should include an explicitly typed null value?

Re: Celebrating Tony Hoare's mark on computer science

#12

Post by tristramb »

"To explain what I was doing in logic-driven software architecture I looked for a good metaphor and, on the spot, proposed that there was a kind of “contract” between caller and callee. He did not say anything, but his mere presence had enabled me to make my incipient ideas jell."

I hadn't realised that Hoare was present when Meyer first used the term 'contract' to describe his ideas.

Re: Celebrating Tony Hoare's mark on computer science

#13

Post by elviejo »

NovemberWhiskey wrote: post #11
mrkeen wrote: post #7

> First, the null pointer is essentially inevitable if you want to model the world, which has references (things containing denotations of other things). I took major exception to this. The real world doesn't have non-things, and references do not demand to refer to non-things. If your domain does actually have the concept of null, just make a type for it. Then you won't accidentally use a 6 or a "foo" where a null w…

The real world is full of relationships that may or may not exist. What’s the referent of “my spouse” if I’m unmarried? Is your point here that every pointer type for which this can be the case should include an explicitly typed null value?

Another example a web link that points to a page that no lnger exists.

It's a null pointer exception.

Re: Celebrating Tony Hoare's mark on computer science

#16

Post by ratorx »

NovemberWhiskey wrote: post #11
mrkeen wrote: post #7

> First, the null pointer is essentially inevitable if you want to model the world, which has references (things containing denotations of other things). I took major exception to this. The real world doesn't have non-things, and references do not demand to refer to non-things. If your domain does actually have the concept of null, just make a type for it. Then you won't accidentally use a 6 or a "foo" where a null w…

The real world is full of relationships that may or may not exist. What’s the referent of “my spouse” if I’m unmarried? Is your point here that every pointer type for which this can be the case should include an explicitly typed null value?

Making it explicit wouldn’t be particularly problematic no? Option in Rust terms. Or for this specific case, a GADT (Single | Married)?

It could even use a special “NULL” address. Just don’t pollute every type with it.

Re: Celebrating Tony Hoare's mark on computer science

#17

Post by mrkeen »

NovemberWhiskey wrote: post #11
mrkeen wrote: post #7

> First, the null pointer is essentially inevitable if you want to model the world, which has references (things containing denotations of other things). I took major exception to this. The real world doesn't have non-things, and references do not demand to refer to non-things. If your domain does actually have the concept of null, just make a type for it. Then you won't accidentally use a 6 or a "foo" where a null w…

The real world is full of relationships that may or may not exist. What’s the referent of “my spouse” if I’m unmarried? Is your point here that every pointer type for which this can be the case should include an explicitly typed null value?

> What’s the referent of “my spouse” if I’m unmarried?

* It's the same referent as all the other things you don't have. Your struct has a Spouse, why does it not also have a RivieraChateau, a SantaClaus, BankAccountInSwissFrancs. If you can answer why you left those out, you know why to leave out Spouse.

* Why stick to 0-1 Spouses. As soon as you do that you're gonna need n Spouses, where some of them will have an ex- flag set, married from&to timestamps.

> Is your point here that every pointer type for which this can be the case should include an explicitly typed null value?

* It shouldn't make a difference whether it's a pointer or a reference or a value or a class. If you believe null is one of the Integers, you should also believe that null is one of the ints. Why should your domain change to accommodate C idioms.

Re: Celebrating Tony Hoare's mark on computer science

#18

Post by ninalanyon »

zabzonk wrote: post #8
mrkeen wrote: post #7

> First, the null pointer is essentially inevitable if you want to model the world, which has references (things containing denotations of other things). I took major exception to this. The real world doesn't have non-things, and references do not demand to refer to non-things. If your domain does actually have the concept of null, just make a type for it. Then you won't accidentally use a 6 or a "foo" where a null w…

And I would just add: Do we want to model the "real world"? This seems to hark back to that long-forgotten world of "animal-cat-dog" OO programming.

I spent the bulk of my career modelling a small part of the real world and OOP absolutely has a place in that.

Re: Celebrating Tony Hoare's mark on computer science

#19

Post by adrian_b »

ratorx wrote: post #16
NovemberWhiskey wrote: post #11

Earlier quoted context omitted.

The real world is full of relationships that may or may not exist. What’s the referent of “my spouse” if I’m unmarried? Is your point here that every pointer type for which this can be the case should include an explicitly typed null value?

Making it explicit wouldn’t be particularly problematic no? Option in Rust terms. Or for this specific case, a GADT (Single | Married )? It could even use a special “NULL” address. Just don’t pollute every type with it.

Polluting every type with it is just a very bad implementation which has nothing in common with the concept of NULL as proposed by Tony Hoare in the paper "Record Handling".

The concept as proposed by Hoare is strictly necessary for things like partial relations, which are encountered very frequently in practice.

It is true however that a large number of programming languages have misused the concept of a NULL reference proposed by Hoare.

As you say, there must be distinct types that may have or may not have a "nothing" value.

Re: Celebrating Tony Hoare's mark on computer science

#20

Post by adrian_b »

skydhash wrote: post #10
DaleBiagio wrote: post #5

Meyer makes an important point that often gets lost: the null pointer predates Hoare. NIL existed in McCarthy's Lisp in 1959, six years before Hoare added null references to ALGOL W. The "mistake," if it was one, was already widespread. What made Hoare's 2009 confession so impactful wasn't that he was solely responsible — it's that he was the first person with that level of authority to publicly say "this was wrong."…

I don’t know much about algol, but in Lisp, nil represents the empty list. And because the list is a recursive data structure, it always contains the empty list. It’s not the same as java where null is its own value that is part of every type. In Lisp, an atom can’t be nil because an atom is not a list.

What you say may be true for some modern LISPs, but it was false in most early LISPs, certainly in any LISP that has preceded the paper "Record Handling" of Tony Hoare.

I quote from the manual of LISP I: "Here NIL is an atomic symbol used to terminate lists".

I am not sure which is the rule in Common LISP, but in many early LISPs the predicate (atom NIL) was true.

In early LISPs, the end of a list was recognized when its CDR was an atom, instead of being another list. The atom could be different from NIL, because that final list could have been an association pair, pointing towards two associated atoms.

The fact that in early LISPs NIL was an atom, but it was also used to stand for an empty list caused some ambiguities.

EDIT: I have searched now and in Common LISP the predicate (atom NIL) remains true, like in all early LISPs, therefore NIL is still an atom, even if using it almost anywhere is equivalent with an empty list.

Post reply on HN