What it contains is "pavement", and "pavement" is NULL.
Stop saying "there is no spoon". It's right there. The pavement exists no matter how much you want it to disappear while there are no cars on it*. Since it is a physical object that must be maintained, it is NOT analogous to NULL. NULL is data that indicates the absence of data. (Which actually doesn't make sense in the real-world, but I digress.) The pavement is a collection. It is a thing that holds zero to many of something else.
Now, if you add "car" to "pavement", the space no longer contains NULL.
If you were referring to the space ABOVE the pavement, then I could agree with you. There's nothing there. (If you ignore the atmosphere for a moment.) That is NULL. Which is to say, *nothing*. There is nothing there. Which is exactly the meaning of "null"; a word which derives from the Latin word "nulla" which means... (wait for it)... "nothing".
* Putting aside quantum states while the pavement is not being observed.
And yes, I'm fully aware that you'd probably burn my eyes out with a red-hot poker right now if you were able.
Why? A simply "whoosh" will do. In case it wasn't obvious, I was deliberately avoiding both nulls and undefineds to make a point. If one allows undefineds, your objections disappear with a simple change:
while(list)
{
count++;
list = list.next;
}
return count;
To your second objection, I could have used a "while(true)" in the original code, but that just offends my sense of style.;-)
The theory of type checking is that the sooner an error is caught, the less likely it is to cause damage. Thus if null does not exist, errors will occur as soon as the non-existent reference is used. This is in direct opposition to a null value where the null can be passed all over the place before it triggers an error. Potentially, incorrect processing may even be done with the null value in the mix.
In addition, code analysis can be done on reference checks. If the compiler knows that a member is undefined when you attempt to access it, it can throw an error if it's unguarded. Similar to this situation:
Object myobj;
myobj.blah();
The compiler will complain very loudly about myobj being uninitialized. Member variables don't currently have this protection because they default initialize to "null".
1. He places the map/emit/reduce functions in the page itself. This is unnecessary. Since Javascript can easily be passed around in text form, the packet that initializes the job can pass a map/emit/reduce function to run. e.g.:
var myfunc = eval("(function() {/*do stuff*/ })");
In fact, the entire architecture would work more smoothly using AJAX with either JSON or XML rather than passing the data around as HTML content. As a bonus, new types of jobs can be injected into the compute cluster at any time.
2. Both Gears and HTML5 have background threads for this sort of thing. Since abusing the primary thread tends to lock the browser, it's much better to make use of one of these facilities whenever possible. Especially since multithreading appears to be well supported by the next batch of browser releases.
(As an aside, I realize this is just a proof of concept. I'm merely adding my 2 cents worth on a realistic implementation.;-))
Nope. Pavement is a collection. Depending on the size of the collection it may have enough "memory" for one car, or for millions. (We call the latter an "interstate".) An absence of a car is simply an empty collection.
I'm not saying there aren't real-world reasons why things are done the way they're done. In fact, I use many of them myself. And I'm especially not arguing that everyone should leave this thread determined to delete the existence of all nulls everywhere.
I'm only continuing on the topic, which is an explanation of how computer science views nulls. Which is that it's a concept that shouldn't exist in languages; at least not in the way it does today. (For example, Javascript has the concept of an 'undefined' value which is similar to a null, except that it is truly non-existent. The only time you ever see it is when you attempt to manipulate values that don't exist. e.g. Paste "javascript:alert(window.qwerty)" into your URL bar. The result will be "undefined". You can test for undefined values without invoking undefined as a value itself, and write appropriate language to handle the situation.)
It seems that you have only sidestepped the question "what should hashmap.get("myvalue") return when it can't find anything?"
An error. Or more to the point, it wouldn't return at all. The software would fail. The idea being that the programmer should be forced to do an exists() check prior to performing a get(). He can't rely on checking a null return value. Theoretically, this prevents him from making mistakes in his code where the null slips through into a critical section.
If the box on the list does not exist, then the pointer is null.
Actually, the slot doesn't exist. The "null" you're thinking of is merely an artifact of the language.
This, for me, was very useful in XML parsing. A zero-length string means an element "foo" exists as thus: A NULL reference means that the element does not exist at all in the XML fragment.
A NULL reference shouldn't exist. There should simply be no reference. i.e. If I see this:
<myxml><foo/></myxml>
It might parse to this:
ArrayList
[0]Foo
But if I have this:
<myxml/>
It should parse to an empty list like this:
ArrayList
But what if you only ever expect one instance of Foo? Might you do this?
class MyXML {
public Foo foo; }
You could, but this would be a denormalization of the data. None the less, it is a situation that needs to be handled. In an ideal world, the "foo" member wouldn't exist until it is assigned a value. (See Javascript for a language that works this way.) Thus you would need to test for the existence of "foo" rather than checking "if(myxml.foo == null)".
Begging your pardon, but that gets rather absurd if you scale it up.
Yes it does. Which is why NULLs are almost a requirement for existing RDBMSes. Absolutely no one is going to make an effort to reach 6th normal form, regardless of what relational theory says. An artifact of theory vs. reality if you will. That does not make RDBMSes correct, only convenient.
Many of today's OODBMSes attempt to smooth away these ugly warts caused by implementation issues. Their success is so-so, but they are catching on. I think the biggest hurdle to their adoption is that programmers confuse OODBMSes and O/R mappings. The two are only tangentially related at best. That and there is a rather significant investment in existing RDBMS technology.
If there's no null value, there's no way to null out a collection short of:
a) Not declaring it b) Deleting the reference altogether
Deleting the reference would mean that there's nothing to track it by. Any attempt to use a deleted reference would throw an error. e.g. If I did "delete(link)" the link variable would cease to exist. This is the thought process behind the Javascript language, which is probably the closest language I can think of to the ideal solution for this problem. (Of course, it still inherited a 'null' value even if you shouldn't ever use it.)
What if I needed to know whether or not you were offered an Apple?
Do you have an apple in your possession? No. You have an offer for an apple in your possession. Which is different from a certificate saying you have no apple.
or turned down an Apple?
Simple. You have no apple. Period. End of story. If you wish to remember the decision as a piece of information, you must record it. Then you have a record of the decision to reject an apple. You still don't have an apple and the certificate saying you don't have an apple is just as useless.
or you had consumed the Apple?
Simple. You have no apple. Period. End of story. If you wish to remember the consumption as a piece of information, you must record it. Then you have a record of the decision to reject an apple. Or you can investigate your gastrointestinal tract for evidence of apple consumption. Either way, you still don't have an apple and the certificate saying you don't have an apple is just as useless.
Those are different things, but in your world you would make them the same.
Actually, you are equating non-equatable information to null. It's a bit like if I scribbled information about apples on my certificate telling me I don't have an apple. I still don't have an apple regardless of what you infer from its absence.
You need to have NULL to represent missing data, anything else is actual data.
I don't think you understand the argument. Having the following is incorrect:
ID|Name|State|Address|Address2 5|Bob|MN|12 East St.|NULL
THIS is correct:
ID|Name|State 5|Bob|MN
ID|Parent|Address|Order 22|5|12 East St.|1
Note how there is no NULL value. In fact, NULL is antithetical to relational theory as all set values should have a value. Missing data should be normalized away.
There are only people who can't intuitively understand 3VL.
3 value logic has nothing to do with it. 3VL actually creates problems in this case. In fact, your very own snarky comment above is a perfect example of how things go wrong with 3VL:
ID|Contestant|Prize 2|AKAImBatman|NULL
resultset = sql("select Prize from Contestants where Contestant = 'AKAImBatman');
//Prints the stupid "NULL" answer while(resultset.next()) print("He leaves with " + resultset["prize"] + " the home game.");
FAIL.
Now look at this situation:
ID|Contestant 2|AKAImBatman 3|geekoid
Parent|Prize 3|Remedial 6th Normal Form
resultset = sql("select Prize from Prizes join Contestants on Contestants.ID = Prizes.Parent where Contestant = 'AKAImBatman'");
//Correctly prints nothing while(resultset.next()) print("He leaves with " + resultset["prize"] + " the home game.");
More like assuming that a variable has to exist before you can refer to it in code.
Indeed. However, I will argue that it's the acceptance of null that causes this problem. Even in class-based code. There's nothing to say that I can't define a class like this:
class Link {
Object next;
Object prev; }
And still be unable to deal with the non-existence of "next" or "prev". In fact, all we've done is assume that only "next" and "prev" are valid values. So "new Link().next = new Object()" would work while "new Link().myObject = new Object()" would fail. Thus "if(!mylink.prev)" can be perfectly valid syntax in a class-based language.
However, that does leave one gap. We want to do as much type checking as possible. Ergo, we would probably want to introduce a "phantom" modifier. e.g.:
class Link {
phantom Object next;
phantom Object prev;
Object value;
public Link(Object initialValue)
{
this.value = initialValue;
} }
The idea is that the compiler would throw an error if any of the following are true:
An attempt to access a member is made prior to its initialization.
A non-phantom reference is not initialized in the constructor.
An attempt is made to delete the value of a non-phantom member.
A runtime error would be thrown if the value of uninitialized phantom member is assigned to anything. e.g. These are errors:
Link link = new Link(new Object());
link.next = link.prev;//Error! prev is not initialized. link.value = link.next;//Error! next is not initialized.
return link.next;//Error! next is not initialized.
That last line would make getter methods slightly more dangerous, but that's a good thing from a comp-sci perspective. Having your getters blow up immediately would demonstrate an issue with the program as soon as possible. For many situations, the compiler can even do an analysis and detect the situation at compile time. Thus the ultimate goal of type checking is better achieved by eliminating null values.
Of course, that gets into the argument of whether type checking actually produces more reliable software or not...
The Babylonians did not have zeros. They simply omitted the number, leaving a space in its stead. Eventually they began using a symbol in certain circumstances to clarify the empty space, but it was not a true "zero" value as we think of it today.
That's a misunderstanding of the spec. NULL has no type, so evaluating NULL = 1 results in an unknown. That does not imply that NULL is an unknown value. I believe this reply on the PostgreSQL mailing list explained it best:
0 <> NULL (Indeed nothing equals NULL, other then sometimes NULL itself)
0 <> 1
Therefore, the statement: 0 NOT IN (NULL, 1) Should always equate to false.
Therefore No rows returned. Ever.
It's a bit weird, but it makes sense when you actually follow the logic.
Null predates zero in the western world. The Romans had no number for zero, but they did represent the concept of nothing with the word 'nulla'. Thus if I had IIII denarii and spent all IIII, I would have nulla remaining. i.e. "nothing".
As an aside, the numbering is correct. The subtractive form of IV for four is a more modern construct that was not in common use during the Roman empire.
If you're still hell-bent on finding who defined zero as a legitimate numerical value, you'd need to look to 9th century India. Their mathematics had evolved far enough to where they stopped asking the philosophical question of "is nothing a number?" and simply used it to get math completed.
My problem is that null references are typically used to signal the ends of lists or the place where the tree ends.
From the perspective of comp-sci, is that a correct solution? The answer is "no". An absence of data should simply be an absence of data, not a piece of data that represents the absence of data.
In other words, you need to imagine a language where the second reference is potentially non-existent. This is quite easy to represent in languages where maps are not closely related to 'null' values. Javascript comes to mind as an exmaple:
var end = {}; var start = {next: end};
end.prev = start;
if(!start.prev) alert("The reference 'prev' does not exist at the start of the list."); if(!end.next) alert("The reference 'next' does not exist at the end of the list.");
alert("There are "+count(start)+" items in the list.");
function count(list) {
var count = 0;
while(list)
{
count++;
if(!list.next) return count;
else list = list.next;
} }
That solution seems sort of ridiculously complex on non-OO languages, and a pain even for OO languages.
This issue is caused by the structure of modern languages, nearly all of which assume that "null" is a valid value.
Consider the situation of apples. If you have an apple, then something is in your possession. If you don't have an apple, what do you have? Do you have some sort of object that depicts your lack of an apple? Obviously not. Yet in the world of computers, we have this special piece of data that shows our lack of data. It's a bit like getting a certificate that you have no apples. The certificate accomplishes nothing except to fill a space that does not need to be filled.
doesn't NULL in SQL represent "unknown", which is something entirely different that a NULL reference
No. NULL in SQL represents an absence of data. Which is occasionally used to cover for unknown values. However, NULL is a piece of data that says there is an absence of data. Which is incorrect. Absence of data means that it doesn't exist. Therefore, nothing should exist in its place.
Normalizing the database can create a situation where the NULL is unnecessary. Therefore, the concept is not needed by computer science. The problem is that real-world considerations often override the ivory tower of comp-sci. And one of those considerations was the fact that RDBMSes have traditionally been organized according to a fixed column model. The inflexibility of the model is driven by the on-disk data structures which are optimized for fast access. OODBMSes (which are really fancy RDBMSes with many "pure" relational features that work around the traditional weaknesses of RDBMSes) attempt to solve this issue by introducing concepts like table-less storage, columns that may or may not exist on a per-row basis, and a dynamic typing system that potentially allow for any data type to show up in particular column. (Note that columns are often handled more as key-value pairs than what we normally think of as columns. This does not undo the theoretical foundation of the Relational model, only results in a different view on it.)
Slashdot Mirror
Does a collection disappear when it is empty?
Stop saying "there is no spoon". It's right there. The pavement exists no matter how much you want it to disappear while there are no cars on it*. Since it is a physical object that must be maintained, it is NOT analogous to NULL. NULL is data that indicates the absence of data. (Which actually doesn't make sense in the real-world, but I digress.) The pavement is a collection. It is a thing that holds zero to many of something else.
If you were referring to the space ABOVE the pavement, then I could agree with you. There's nothing there. (If you ignore the atmosphere for a moment.) That is NULL. Which is to say, *nothing*. There is nothing there. Which is exactly the meaning of "null"; a word which derives from the Latin word "nulla" which means... (wait for it)... "nothing".
* Putting aside quantum states while the pavement is not being observed.
What is wrong, Sid? You no like-ink my evil laugh? Here, I do it more: Mwhahahah! :-P
Why? A simply "whoosh" will do. In case it wasn't obvious, I was deliberately avoiding both nulls and undefineds to make a point. If one allows undefineds, your objections disappear with a simple change:
To your second objection, I could have used a "while(true)" in the original code, but that just offends my sense of style. ;-)
Which is to say that Javascript is the future of all computing progress.
"First they ignore you, then they ridicule you, then they fight you, then you win." --Mahatma Gandhi
Mwuhahaha! MWHahaha! MUHAHAHAAAAAAaaaaaa--
*cough* *cough* *wheeze* *sputter* *wheeze*
*clears throat* 'scuze me!
MWUHAHAHAAHAHAAAA!!!! :-P
What does Java have to do with anything?
Maybe you should try reading the post you're responding to?
The theory of type checking is that the sooner an error is caught, the less likely it is to cause damage. Thus if null does not exist, errors will occur as soon as the non-existent reference is used. This is in direct opposition to a null value where the null can be passed all over the place before it triggers an error. Potentially, incorrect processing may even be done with the null value in the mix.
In addition, code analysis can be done on reference checks. If the compiler knows that a member is undefined when you attempt to access it, it can throw an error if it's unguarded. Similar to this situation:
The compiler will complain very loudly about myobj being uninitialized. Member variables don't currently have this protection because they default initialize to "null".
Two comments:
1. He places the map/emit/reduce functions in the page itself. This is unnecessary. Since Javascript can easily be passed around in text form, the packet that initializes the job can pass a map/emit/reduce function to run. e.g.:
In fact, the entire architecture would work more smoothly using AJAX with either JSON or XML rather than passing the data around as HTML content. As a bonus, new types of jobs can be injected into the compute cluster at any time.
2. Both Gears and HTML5 have background threads for this sort of thing. Since abusing the primary thread tends to lock the browser, it's much better to make use of one of these facilities whenever possible. Especially since multithreading appears to be well supported by the next batch of browser releases.
(As an aside, I realize this is just a proof of concept. I'm merely adding my 2 cents worth on a realistic implementation. ;-))
Nope. Pavement is a collection. Depending on the size of the collection it may have enough "memory" for one car, or for millions. (We call the latter an "interstate".) An absence of a car is simply an empty collection.
I'm not saying there aren't real-world reasons why things are done the way they're done. In fact, I use many of them myself. And I'm especially not arguing that everyone should leave this thread determined to delete the existence of all nulls everywhere.
I'm only continuing on the topic, which is an explanation of how computer science views nulls. Which is that it's a concept that shouldn't exist in languages; at least not in the way it does today. (For example, Javascript has the concept of an 'undefined' value which is similar to a null, except that it is truly non-existent. The only time you ever see it is when you attempt to manipulate values that don't exist. e.g. Paste "javascript:alert(window.qwerty)" into your URL bar. The result will be "undefined". You can test for undefined values without invoking undefined as a value itself, and write appropriate language to handle the situation.)
An error. Or more to the point, it wouldn't return at all. The software would fail. The idea being that the programmer should be forced to do an exists() check prior to performing a get(). He can't rely on checking a null return value. Theoretically, this prevents him from making mistakes in his code where the null slips through into a critical section.
Actually, the slot doesn't exist. The "null" you're thinking of is merely an artifact of the language.
A NULL reference shouldn't exist. There should simply be no reference. i.e. If I see this:
It might parse to this:
But if I have this:
It should parse to an empty list like this:
But what if you only ever expect one instance of Foo? Might you do this?
You could, but this would be a denormalization of the data. None the less, it is a situation that needs to be handled. In an ideal world, the "foo" member wouldn't exist until it is assigned a value. (See Javascript for a language that works this way.) Thus you would need to test for the existence of "foo" rather than checking "if(myxml.foo == null)".
Yes it does. Which is why NULLs are almost a requirement for existing RDBMSes. Absolutely no one is going to make an effort to reach 6th normal form, regardless of what relational theory says. An artifact of theory vs. reality if you will. That does not make RDBMSes correct, only convenient.
Many of today's OODBMSes attempt to smooth away these ugly warts caused by implementation issues. Their success is so-so, but they are catching on. I think the biggest hurdle to their adoption is that programmers confuse OODBMSes and O/R mappings. The two are only tangentially related at best. That and there is a rather significant investment in existing RDBMS technology.
If there's no null value, there's no way to null out a collection short of:
a) Not declaring it
b) Deleting the reference altogether
Deleting the reference would mean that there's nothing to track it by. Any attempt to use a deleted reference would throw an error. e.g. If I did "delete(link)" the link variable would cease to exist. This is the thought process behind the Javascript language, which is probably the closest language I can think of to the ideal solution for this problem. (Of course, it still inherited a 'null' value even if you shouldn't ever use it.)
Do you have an apple in your possession? No. You have an offer for an apple in your possession. Which is different from a certificate saying you have no apple.
Simple. You have no apple. Period. End of story. If you wish to remember the decision as a piece of information, you must record it. Then you have a record of the decision to reject an apple. You still don't have an apple and the certificate saying you don't have an apple is just as useless.
Simple. You have no apple. Period. End of story. If you wish to remember the consumption as a piece of information, you must record it. Then you have a record of the decision to reject an apple. Or you can investigate your gastrointestinal tract for evidence of apple consumption. Either way, you still don't have an apple and the certificate saying you don't have an apple is just as useless.
Actually, you are equating non-equatable information to null. It's a bit like if I scribbled information about apples on my certificate telling me I don't have an apple. I still don't have an apple regardless of what you infer from its absence.
See, I interpreted his post as an evaluation rather than as truth statements. Though I certainly see your interpretation. I read it as:
0 <> NULL = NULL
1 <> 0 = true
NULL && true = NULL
NULL ~= false
Which makes perfect sense. So I guess the above is really what I was going after. :-)
I don't think you understand the argument. Having the following is incorrect:
THIS is correct:
Note how there is no NULL value. In fact, NULL is antithetical to relational theory as all set values should have a value. Missing data should be normalized away.
3 value logic has nothing to do with it. 3VL actually creates problems in this case. In fact, your very own snarky comment above is a perfect example of how things go wrong with 3VL:
FAIL.
Now look at this situation:
Indeed. However, I will argue that it's the acceptance of null that causes this problem. Even in class-based code. There's nothing to say that I can't define a class like this:
And still be unable to deal with the non-existence of "next" or "prev". In fact, all we've done is assume that only "next" and "prev" are valid values. So "new Link().next = new Object()" would work while "new Link().myObject = new Object()" would fail. Thus "if(!mylink.prev)" can be perfectly valid syntax in a class-based language.
However, that does leave one gap. We want to do as much type checking as possible. Ergo, we would probably want to introduce a "phantom" modifier. e.g.:
The idea is that the compiler would throw an error if any of the following are true:
A runtime error would be thrown if the value of uninitialized phantom member is assigned to anything. e.g. These are errors:
That last line would make getter methods slightly more dangerous, but that's a good thing from a comp-sci perspective. Having your getters blow up immediately would demonstrate an issue with the program as soon as possible. For many situations, the compiler can even do an analysis and detect the situation at compile time. Thus the ultimate goal of type checking is better achieved by eliminating null values.
Of course, that gets into the argument of whether type checking actually produces more reliable software or not...
The Babylonians did not have zeros. They simply omitted the number, leaving a space in its stead. Eventually they began using a symbol in certain circumstances to clarify the empty space, but it was not a true "zero" value as we think of it today.
That's a misunderstanding of the spec. NULL has no type, so evaluating NULL = 1 results in an unknown. That does not imply that NULL is an unknown value. I believe this reply on the PostgreSQL mailing list explained it best:
It's a bit weird, but it makes sense when you actually follow the logic.
Here you go: http://developers.slashdot.org/comments.pl?sid=1147437&cid=27052083
The correct solution is absence of data is absence of data. Which means that even the reference should not exist.
Null predates zero in the western world. The Romans had no number for zero, but they did represent the concept of nothing with the word 'nulla'. Thus if I had IIII denarii and spent all IIII, I would have nulla remaining. i.e. "nothing".
As an aside, the numbering is correct. The subtractive form of IV for four is a more modern construct that was not in common use during the Roman empire.
If you're still hell-bent on finding who defined zero as a legitimate numerical value, you'd need to look to 9th century India. Their mathematics had evolved far enough to where they stopped asking the philosophical question of "is nothing a number?" and simply used it to get math completed.
From the perspective of comp-sci, is that a correct solution? The answer is "no". An absence of data should simply be an absence of data, not a piece of data that represents the absence of data.
In other words, you need to imagine a language where the second reference is potentially non-existent. This is quite easy to represent in languages where maps are not closely related to 'null' values. Javascript comes to mind as an exmaple:
This issue is caused by the structure of modern languages, nearly all of which assume that "null" is a valid value.
Consider the situation of apples. If you have an apple, then something is in your possession. If you don't have an apple, what do you have? Do you have some sort of object that depicts your lack of an apple? Obviously not. Yet in the world of computers, we have this special piece of data that shows our lack of data. It's a bit like getting a certificate that you have no apples. The certificate accomplishes nothing except to fill a space that does not need to be filled.
No. NULL in SQL represents an absence of data. Which is occasionally used to cover for unknown values. However, NULL is a piece of data that says there is an absence of data. Which is incorrect. Absence of data means that it doesn't exist. Therefore, nothing should exist in its place.
Normalizing the database can create a situation where the NULL is unnecessary. Therefore, the concept is not needed by computer science. The problem is that real-world considerations often override the ivory tower of comp-sci. And one of those considerations was the fact that RDBMSes have traditionally been organized according to a fixed column model. The inflexibility of the model is driven by the on-disk data structures which are optimized for fast access. OODBMSes (which are really fancy RDBMSes with many "pure" relational features that work around the traditional weaknesses of RDBMSes) attempt to solve this issue by introducing concepts like table-less storage, columns that may or may not exist on a per-row basis, and a dynamic typing system that potentially allow for any data type to show up in particular column. (Note that columns are often handled more as key-value pairs than what we normally think of as columns. This does not undo the theoretical foundation of the Relational model, only results in a different view on it.)
Derr... haven't had my coffee yet. Thanks for pointing that out so that no one gets confused. :-)