Slashdot Mirror
Null References, the Billion Dollar Mistake
jonr writes "'I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years. In recent years, a number of program analysers like PREfix and PREfast in Microsoft have been used to check references, and give warnings if there is a risk they may be non-null. More recent programming languages like Spec# have introduced declarations for non-null references. This is the solution, which I rejected in 1965.' This is an abstract from Tony Hoare Presentation on QCon. I'm raised on C-style programming languages, and have always used null pointers/references, but I am having trouble of grokking null-reference free language. Is there a good reading out there that explains this?"
It's hard to imagine life without the null pointer! That being said, the author is not really responsible for billions of dollars of mistakes, the programmers are.
If there is one thing I'll complain about, it's the choice of the value 0. It's almost impossible to trace it. When we do hardware debug of chips, we prefer to use a much more visible value such as 0xdeadbeef for instance. Otherwise a bad pointer will bland too much with all the uninitialized values out there.
In assembly, null has no particular meaning. If you dereference an address, you can do it in any range you like. It's just that 0 on most machines was not a good place to store anything, since it would typically be used to boot the OS or some other critical IO function that you don't want to mess up with. Thus null was born.
If you're familiar with SQL, then a simple "MyColumn NOT NULL" definition should explain it. Basically, the value can never be set to a null value. Attempting to do so is an error condition itself.
In fact, DB design is a pretty good analogy for the concept as databases often are forced to wrestle with this issue.
Consider for a moment how you would design a database that has absolutely NO null references. Not a one. Zip, zero, nada. Obviously the best way of accomplishing such a database is to denormalize any value that might be null. So if Address2 is optional, you would want to split Address into its own table with a parent key pointing back to the user entry. If the user has an Address2 value, there will be a row. If the user does NOT have an Address2, the row will be missing. In that way, empty result sets take the place of null values.
In terms of programming languages, there are a varity of ways to map such a concept. Collections are a 1:1 mapping to result sets that can work. If you don't have any values in your collection, then you know that you don't have a value. Very easy. Similarly, you can be sure that none of the values passed to a function or method will ever contain a null value. Cases where you might want to pass some of the values but not all can be handled either by method overloading (e.g. Java) or by allowing a variable number of parameters. (e.g. C)
Some pieces of programming would become slightly more difficult. For example, 'if(hashmap.get("myvalue") != null)' would not be a valid construct. You'd need to perform a check like this: 'if(hashmap.exists("myvalue")'
Of course, the latter is the "correct" check anyway, so the theory goes that the software will be more robust and reliable.
Javascript + Nintendo DSi = DSiCade
Null-terminated strings. The bane of modern computing.
Website Hosting
Yeah, but wouldn't the first thing you'd do in the system API design of any non-null language be, the creation of a singleton object instance of the superclass of all objects, named 'null' ?
Also, apart from 'null' there are loads of parameters than can have illegal ranges and must be checked to be proper.
Thirdly, a similar rant can be had against non-range checking of enums in C (but then warning against it in switches (WTF?)).
Religion is what happens when nature strikes and groupthink goes wrong.
Fine. No null references. So I create the same thing by having a reference to some unique structure (probably named Null) and I still *fail to check for it*.
Null references don't kill programs. Programmers do.
-CZ
Umm... no? The first thing done is usually a superclass called "Object". If you don't extend anything else, you extend Object. Depending on the language, the superclass of Object would either be self-referential or the option to obtain a superclass wouldn't exist. (The latter being the "correct" solution. See my next statement for why.)
That's actually a problem. Null is a piece of data that represents the absence of data. The paradox here should be obvious. If the data doesn't exist, why do we create data about it not existing? If I have no apples, do I have an object that represents my lack of apples? No, I simply have no apples. At best, I might have a special container for apples. If it's empty, then I can infer that I have no apples. Just as a program can infer the absence of data through an empty collection.
There's a lot of things wrong with C as a language. Don't try to use those as arguments. (Remember, C is more or less high-level assembly. On the scale of comp-sci it barely even rates. Its popularity stems from the excruciating slowness of computers in days gone by.)
Javascript + Nintendo DSi = DSiCade
The concept of "no null references" would be very limiting in a language without algebraic datatypes. You can think of null references as a sort of teeny limited braindead algebraic data type, actually. I get the feeling that much of the incredulity here stems from the posters not being familiar with languages that support them. If this describes you, check out Haskell and OCaML! They're the sort of languages that make you a better programmer no matter what language you're using.
The opinions stated herein do not necessarily represent those of anybody at all. Deal with it.
Eiffel recently added void safety.
Is it not a tad arrogant to claim that he single-handedly is responsible for a billion dollars in mistakes? First, as an earlier poster remarked, the programmers themselves, or at least the current business context of programming, are perhaps more responsible. Second, while I'm aware that Tony Hoare is largely responsible for defining Algol -- though it was a committee effort -- it may just be on the edge of possibility that a high performance language such as C would have still included null references even if Algol did not. And Hoare's reference to Microsoft's work is nothing but PR; MSR is his current employer. Plenty of other earlier efforts have addressed null pointer dereferences; and of course certain classes of languages avoid the problem entirely.
for Pascal type strings in C. The fact that null-terminated strings existed wasn't the problem, they make some sense in some respects, such as when you want to pass text of arbitrary length. But the real problem, the real bug was not having a standard way of doing real strings in C. Everybody had to do it himself, poorly. Had there been a standard, no matter how poor, it would have been a starting point to do something better if needed, and would have been better anyway for many uses than C strings. It would have avoided MANY vulnerabilities from common software.
A write-up on this very topic from the Java perspective after a discussion at the JFokus conference: http://dow.ngra.de/2009/02/01/correcting-the-billion-dollar-mistake/
In a low-level language like C or assembly, anyway? The only workable alternative I ever saw was to store the length in (or with) the string, which can be very wasteful of memory.
Best Slashdot Co
I'm raised on C-style programming languages, and have always used null pointers/references, but I am having trouble of grokking null-reference free language.
Take a look at C++, in which you can declare methods to be "pass by reference" rather than "pass by pointer". Although the former is actually really just passing a pointer too, the semantics of the construct make it impossible to pass NULL.
"Wise men talk because they have something to say; fools, because they have to say something" - Plato
The concept of the null value should have been patented. If so, it would have validated that patents in software can be a good thing by stopping the destructive spread of bad ideas in the same way they stop the spread of good ones.
Either that, or whoever invented the concept would be far richer than Bill Gates, Larry Ellison, and Steve Ballmer combined!
This post brought to you by your friendly neighborhood MBA.
They should be shot for that one :-) This is lead to so many costly buffer-overflow virus attacks. Early languages like FORTRAN and COBOL had safer strings, but not as elegant as C. You had to pre-declare string storage size in early compilers.
It's unitialized pointers (and, for that matter, other variables) that are the problem. At least in assembly and C/C++. I don't think I ever had cause to use pointers in Perl or Python. Or C#. Null pointers or zero values in other variables are easy to test for anyway. It's the uninitialized variables that bite you in the ass.
Best Slashdot Co
You'll just have developers replace it like:
$foo = NULL;
getRef( $foo );
if ( $foo != NULL ) {
doSomething( $foo );
}
with
$foo = "dummy";
getRef( $foo );
if ( $foo != "dummy" ) {
doSomething( $foo );
}
Basicly, you can write any null code as non-null code just like you can hammer a square peg in a round hole. All you'd have is that instead of missed null checks you'd have missed dummy checks and it's be even less sane and understandable. Compared to every other way of enforcing error flagging the null references are the KISS solution. Though I much prefer the object oriented way where "isNull()" is the opposite of "isValid()" and that'll try to behave "nice" (usually by doing nothing and return error values) when something calls it instead of killing the application.
Live today, because you never know what tomorrow brings
Zero. The bane of all. It was the gateway math to all modern problems. It would be so much simpler with just countables. Surely the current crisis, measured in trillions would look so much better without all those zeros.
Whoever it was who invented zero should take responsibility for all the worlds problems, ex nehilo.
-- Each tock of the Planck clock is a new world and here we are still life. --
Could you try a better analogy. I think we might all understand a car analogy better...
My blog
Stroustrup's "C++ Programming Language" book introduces a concept called "resource acquisition is initialisation" that was eye-opening enough to me that it forever changed the way I think about code, and also seems relevant to your point.
The basic idea is that an object is always meant to represent something tangible. As an example, consider the design of file object that abstracts file I/O operations. As a developer, I've come across this one several times, it is normal that such objects have open and close methods, however that makes the design of the object in contradiction with Stroustrup's concept because open/close provided as methods rather than only called in the constructor/destructor means the object may be in existence yet be in a state where it is not associated with an open file. You basically have to grok that having a file object around that doesn't directly map to an open file just adds overhead to the system and is basically bad OO design in that in some sense that object is meaningless.
Apply the same concept to a reference and you have your answer. If a reference is pointing at nothing, then what is its purpose? The only thing a NULL reference is good for is when the software design ascribes a special meaning to the value NULL. Instead of just meaning address location 0, it gets subverted to mean "variable unassigned" or the "tail node of list" or somesuch. Ascribing multiple meanings to a variable value (especially pointers/references that are only ever meant to hold memory addresses) is one example of bad programming practice known as programming by side-effect which most people agree should be avoided.
Another point is that in most OO lanugages, references have an extra benefit of being more strongly typed than pointers, menaing that reference is guaranteed to only ever be pointing at an instantiated object of its specific type. That guarantee also gets broken when a reference can be NULL.
The reason it's hard to grok null-reference-free languages is because "a reference to nothing" is a natural concept. For instance, you want to find an object in a list. What's the result when the object you want isn't in the list? A language that can't express that concept leaves the programmer scratching their head.
The problem I run into's usually two-fold. First, programmers who don't really think about the failure case. They go looking for something, and skip the check for whether they found it. Sometimes it's just that they're lazy, sometimes it's that handling that case will be really hard, and sometimes it's because they've been told what they're looking for has to always exist so the operation can't fail. Second, compilers often treat null references/pointers as valid. Combined with the "initialize everything, always" coding style it yields nasty failures. The compiler doesn't gripe about using uninitialized variables because the variable was initialized, and neither the compiler nor the run-time gripe about using a null reference/pointer because it's considered valid. Solving those problems doesn't involve eliminating the null reference, though.
Because forcing inherently procedural/algorithmic code into a functional paradigm makes for readable code, AMIRITE?
Of course you're wrong; you want to be.
Stop with the "functional languages are a panacea" bullshit already.
They're definitely not a panacea, and I don't think anybody claimed them to be (and if they did, I don't agree with them). Your parent definitely didn't.
What he's saying is that a particular kind of type system (let's call it the ML-like) has something that works much better than null.
For instance, say you want to factor a number; you may want to return [2, 3, 5] for 30, [] for 1 (that is, the empty list) and some non-list thing for "error". What you can do instead of returning "list of int" is to return "either a list of int or nothing at all". But, and here's the real trick: other functions can be specified as always return a list of int without it being possible to return a non-list value, thus eliminating the possibility of "wrong" null refs.
That's the benefit.
This is why I love programming in Obj-C. If you make a method call to a nil-valued object, nothing happens. No program crashes! Nothing! Simply no messages are sent to the object. Thus no fuss.
We have NAN to represent numbers that aren't. The hardware should have NAP (or NAR if they must) to represent a Pointer or Reference that is intentionally not dereferencable. The difference between this and a zero pointer would be well defined results when you 1) dereferenced, or 2) indexed based on the pointer.
You may deposit my share of the billion of dollars saved by this idea in my Paypal account.
first of all, stop using all forms of "grok" and revert back to plain English terminology....
If what Windows Update sends me on Patch Tuesday is any judge null pointer dereferences are actually quite rare. Almost all appear to be buffer overflows and things like that (such as accidentally overwriting your stackframe - oops) and as such are caused by erroneously using a perfectly valid pointer. So the lack of range checking, and would, I guess, include the effects null-terminated strings, would probably be the most expensive. I think the reason null pointer issues are rarer is because these usually indicate a predictable fail state which is checked for. You usually only get them when you know that you not only can get them, but that you must necessarily check for them because there would be no other way to implement your algorithm. End of a linked list, for example. A map from which you retrieve items that you might not have put in there is another one. Oh, and of course I don't think all the blame can fall on the language designer even if he were really the cause behind the problem (as is highly debatable in this case) because the programmers implemented their programs, they thought they had enough prowess to use the language, and if they didn't they should have used something else. If you're drunk, you shouldn't be using a chainsaw, and the manufacturer can't be blamed if you saw your leg off.
While Tony Hoare may not have lifted NULL from LISP, LISP 1.5 had its own version, NIL, in 1960 or thereabouts... NIL was even represented as 0, internally, at least in early versions of LISP.
While less likely to cause problems than in a language like Algol or C, I do believe this is the earliest use of "null" in a programming language (at least until some cheeky joker out there finds an earlier one I didn't know about).
-Dave Haynie
Perhaps you should read this article written years ago that explains it very nicely.
It's true. Null terminated strings are slow, and they suck in lots of ways.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
or even a handheld. For those you use a language that implements a string type that doesn't use a string terminator.
Embedded systems are different. Much more constrained.
Best Slashdot Co
null. and void.
Java is a null reference-free language, sort of. Every function in Java just throws a NullArgumentException or whatever they call it, and it's just like you threw an exception instead of returning null.
Right?
That's actually a problem. Null is a piece of data that represents the absence of data. The paradox here should be obvious. If the data doesn't exist, why do we create data about it not existing?
NULL is probably the neatest basic advance in math since the invention of ZERO. Most people don't understand the difference- ZERO means you don't have any of something, but you still have a value, i.e. knowledge that you don't have any. NULL represents that you don't necessarily even have the knowledge, i.e. there isn't even a value.
In standard math a NULL situation simply breaks an equation or formula because computation cannot proceed, or exists as a form of a workaround where multiple formulas must be used depending on the data you have.
The use of NULL should really be integrated into standard math.
The idea of NULL is brilliant, especially when dealing with computer systems where you not only have to refer to data with numbers, but need to also refer to the lack of data with numbers.
Not all references can be valid all the time. There has to be a way to check if a reference is valid or not and NULL is as good a way as any.
The debate should be about:
a) Whether dereferencing null bombs or throws an exception.
b) Whether a language should have dangling pointers (ie. invalid but non-null).
No sig today...
Null is a piece of data that represents the absence of data. The paradox here should be obvious. If the data doesn't exist, why do we create data about it not existing? If I have no apples, do I have an object that represents my lack of apples? No, I simply have no apples. At best, I might have a special container for apples. If it's empty, then I can infer that I have no apples.
I've always thought of it a little differently, but then again maybe that's a Java background. I have a bunch of named cardboard boxes, and a paper list with the names of the boxes written on it.
If the box on the list exists and has something in it, then the pointer is not null and the referenced thingy has a value.
If the box on the list exists and is empty, then the pointer is not null and the referenced thingy has no value.
If the box on the list does not exist, then the pointer is null.
This, for me, was very useful in XML parsing. A zero-length string means an element "foo" exists as thus: <foo/> A NULL reference means that the element does not exist at all in the XML fragment.
"You cannot find out which view is the right one by science in the ordinary sense." - C.S. Lewis on Intelligent Design
C/C++ always allowed a way to get around at least some NULL references: the lifetime instantiation of contained structs/objects. UML even came up with notation to distinguish between these two types of associations (aggregation vs. composition). Java threw composition to the wind, making everything a pointer (or "reference" in Java parlance), thus creating the potential for even more NULL pointer. Microsoft learned from Java's mistake and preserved "value objects" in C#.
That being said, the author is not really responsible for billions of dollars of mistakes, the programmers are.
Null References Don't Kill People... Programmers Kill People.
[Ego]out
A useful way to think about troubles in language design is to ask the question "When do you have to lie to the language?" Most of the major languages have some situations in which you have to lie to the language, and that's usually a cause of bugs.
The classic example is C's "array = pointer" ambiguity. Consider
int read(int fd, char* buf, size_t len);
Think hard about "char* buf". That's not a pointer to a character. It's a pass of an array by reference. The programmer had to lie to the language because the language doesn't have a way to talk about what the programmer needed to say. That should have been
int read(int fd, byte& buf[len], size_t len);
Now the interface is correctly defined. The caller is passing an array of known size by reference. Notice also the distinction between "byte" and "char". C and C++ lack a "byte" type, one that indicates binary data with no interpretation attached to it. Python used to be that way too, but the problem was eventually fixed; Python 3K has "unicode", "str" (ASCII text only, 0..127, no "upper code pages"), and "bytes" (uninterpreted binary data). C and C++ are still stuck with a 1970s approach to the problem.
The problem with NULL is related. Some functions accept NULL pointers, some don't, and many languages don't have syntax for the distinction. C doesn't; C++ has references, but due to backwards compatibility problems with C, they're not well handled. ("this", for example, should have been a reference; Strostrup admits he botched that one.) C++ supposedly disallows null references (as opposed to null pointers), but doesn't check. C++ ought to raise an exception when a null pointer is converted to a reference.
SQL does this right. A field may or may not allow NULL, and you have to specify.
Look for holes like this in language design. Where are you unable to say what you really meant? Those are language design faults and sources of bugs.
One divided by zero should yield "null", meaning, "not a valid computable number for further calculations". Truth tables should all have at least three columns, one, zero and null. Null times anything is null. The ability to use null dates would have avoided the whole millennium bug mess.
So how do you express a null value? Well, apart from the idea of adding separate "certainty" registers, there was an obvious candidate. One of the major design screwups in modern computing was the implementation of asymmetrical integer ranges. That was stupid. Really, really, REALLY stupid. If negative values only go down to -127, then positive values should only go up to +127. That extra integer was a dangerous inconsistency, it meant that, for instance, if you were processing sixteen-bit waveform data, and the audio was clipped, and you wanted to phase-reverse a section of waveform, simply writing "data=(- data)" would crash the system. You'd have to manually check and weed out every appearance of a -32768 value, which shouldn't by rights have been allowed to exist in the first place.
The anomaly with signed integers was that zero exists in both the positive and negative number ranges, giving you a spare value of "minus zero", to play with, and designers figured that since they didn't know what else do do with it, they'd use it to extend one side of the range by one additional value. They shouldn't have done it. That anomalous "minus zero" string value should have been reserved, and later wired into the processor logic as a representation of "null".
If someone gives you a memory pointer, which references an address that is "null" (or which fails), the appropriate response is for the returned value to also be "null". Easy. You shouldn't have to preemptively check everything for bad values, operations on bad values should simply return "null", and the nulls should then propagate through the calculations until they get picked up by a leisurely programmer's check, which can then spot that something's gone wrong in particular calculation and react to the situation in a graceful and appropriate manner.
One of the awful problems with computer design is that people originally wanted computers to give definite answers, and there are situations where definite numerical answers aren't just appropriate. A computer needs to occasionally be able to wail, "But I don't know!", or "This data hasn't been set!", or "This calculation has failed!". But the people who originally devised these systems and languages didn't consider that properly, and to a large extent, the perception of computer software as being often buggy and badly engineered is those people's fault.
Eric Baird
"Because anything a NULL interacts with becomes a NULL. "
Ummmm No.
The results are NULL, nothing becomes NULL*.
In your example (car) (mouse) (fox) don't become NULL, the result of the evaluation is NULL.
* This includes divide by Zero in most larger Databases..but not all.
Important to note because this can really mess up a complex query that you would expect to through an error but instead passes a NULL.
Or so I heard....cough.
Hey, it as my first profession gig, and ti was just about a billion years ago.
The Kruger Dunning explains most post on
Sorry this thread (and the passion in it) is not nerdy enough. Could we please have some nerdy stuff on Slashdot!
16 bit is too small in some cases? Well then rewrite the library for 32 bits.
Seriously.
Thing is, people rewrote the library that did not exist a thousand times anyway, and more often than not used C strings when they shouldn't have, resulting in countless disastrous buffer overflows.
Oh and btw, there is a simple solution to this non-problem:
#define STRING(typ) typ##string
#define DEFINESTRING(typ) typedef struct { \
typ len; \
char c[0]; \
} STRING(typ);
DEFINESTRING(int);
DEFINESTRING(long);
DEFINESTRING(uint128);
int println(STRING(int) a) {
Null is necessary in as much as an empty set is not equivalent to having no set at all. How could you represent "no set" without null? Perhaps an empty set of sets? Possible, but that's a poor solution because the semantic isn't clear. This is a practical problem and Null is the correct solution.
... in Microsoft have been used to check references, and give warnings if there is a risk they may be non-null.
Because non-null references are a no-no at Microsoft. It might lead to working code!
Use it when you know what you do.
Last time when the Debian project has tried to remove uninitialized pointers in ssh it fired back as a disaster for them and all derived distributions. They have reduced the entropy to 15 bits in their encryption routines.
But a reference is not necessarily a pointer. Certainly C# and Python have pointers, but I've never needed to use them. References, yes. Pointers, no.
Best Slashdot Co
Those are references.
Best Slashdot Co
*poof* there goes the second billion in cash, in the form of wasted time by Slashdot. Sorry Tony, you'll need to update the title of your presentation.
[PREfix and PREfast] give warnings if there is a risk they may be non-null
English is not my language, but shouldn't this be the opposite? i.e. "give warnings if there is a risk they may be null"
You A$$H
The other alternative to forced nullable types in your language is to have labeled union types, à la ML/Haskell. This feature's scope takes care of the cases where you genuinely want null, and of enumeration types in general, too.
The Haskell type system allows you to define types that are an "or" of several named subcases. Each subcase can have values of other types as contents, or nothing. So, for example, in Haskell you can define the following type, called Maybe (I hope I get the syntax right!):
This is a parametric type, parametrized over a type variable, 'a'; thus you can use the Maybe type constructor to construct types like Maybe String, Maybe Integer, Maybe Tree, etc. A variable of type Maybe String can take two kinds of value:
What this implements is the idea that a variable whose value is always an object of type t has a different type than a variable whose value is either an object of type t, or some designated, extra value that means "nothing." Then you code can be written so that contexts where it doesn't make sense to have nulls make use of the plain types, contexts that really require nullable types use those, and that to go from a nullable context to a non-nullable one you need to perform some sort of type cast that checks and handles the null case.
This falls out for free from labeled union types, but it would be very easy to get a limited version of this in a language without labeled unions, by nullability as a sort of type annotation, and defaulting all type declarations to not nullable. In this model, a variable cannot be null unless you've declared it to be nullable, and whenever you need to pass a value held in a nullable variable to a function whose arguments aren't nullable, you'd need to convert the variable's value to a non-nullable type, which would perform a null check. You'd have a compilation-time guarantee that the only places in your program where nulls can occur is those places where you've declared they can.
Are you adequate?
Maybe types are wonderful. I first thought they were inconvenient, since you have to pattern match against them any time you want to extract the value, but then I realized that that was something I ought to be doing anyways, and the advantages of never accidentally dereferencing a null pointer vastly outweigh a little extra typing. And then, more recently, I figured out how to use the maybe monad to string together a bunch of things that might fail without having to manually pattern match every time.
The first OS I encountered was tape-based. And it prefilled user memory with a "core constant".
This was a subroutine jump to an abort routine which printed the return location - which in turn told you where you had improperly jumped to and dumped all your registers, followed by the memory itself if that was authorized. (That was all the info that was left by the time the OS got control.)
The walls of the computing center contained posters giving this value as it would appear if printed as various types of values (integer, floating point, complex, ...).
Another machine I dealt with back then was a typesetting device using a Data General Nova and the company's homebrew OS (designed by Mark Weiser of Xerox Parc fame, based on work by Djikstra and Riddle). It had a debugger entry that could be reached by a one-word instruction which we would insert as breakpoints and also use to fill unused memory. The hex form of this was "0c0f". When the machine hit a breakpoint we said it had "coughed".
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
What bothers me is systems like MS Access, which effectively have 3 different types of null, each of which must be tested for separately. Now that is a billion-dollar design mistake!
I've abandoned my search for truth; now I'm just looking for some useful delusions.
Our programming languages professor, Robert Harper, recently talked about this concept in class. Although he argued that there was "no such thing" as a null pointer, what he actually meant to say was either there shouldn't be such a thing, or that a properly designed language would not have such a notion.
Consider SML (which, incidentally, he helped design). There are of course basic types, ints and bools etc, but it also has the notion of an "option" datatype. A foo option can either be NONE, or SOME of foo. For example, if you are doing some calculation that returns an int but may somehow fail to calculate its result, it will return an int option, with either SOME(result) if there was success, or NONE if it failed. Due to SML's strong type system, the function using that result would have to do case analysis on the result -- you can't use an int option as if it were an int; you need to pattern match and grab the int out of the SOME case and otherwise handle the NONE case.
Java (and C and...) doesn't do this properly. Take an ArrayList, for example. When you say "ArrayList foo", what you actually have is an ArrayList option, he argued, since you really either have SOME(an actual ArrayList) or NONE, representing the null pointer. Except Java has no notion of option types. There's no way to actually get an ArrayList -- you always have an ArrayList option. You have to check for NULL every time.
Thus his argument for why Java et al are badly designed, and how you can properly design a programming language without a need for a NULL pointer -- you use a different type altogether, upon which you can properly case analyze.
Omnes stulti sunt.
The problem with NULL/null/None as implemented in C++/Java/C#/Python/whatever is that it's pervasive - it always "adds itself" to the list of valid values of any reference type (= pointer type in C++, = any type in Python), in all contexts. At the same time, it isn't truly a valid value, because you can't do with it what you can normally do with any other value of the type. It's actually a lot like signalling NaN for object references, and is an equally bad idea for the same reasons.
How to handle that? Why, with explicit "nullability markers", and languages which track nullability propagation, and require to check for null everywhere you try to perform an operation that won't work for a null value whenever you have a value that can potentially be null. In FP languages, this is naturally done with ADTs; for example:
Note that OCaml compiler, in the example above, won't let you omit the "None" branch. You have to handle that (well, you can just pass on the "int option" value, but only to another function that is declared as taking one, and not just "int"). Also note how the other branch is guaranteed to get some specific, "non-null" int value for x.
These enforced checks prevent silent null propagation, which is the bane of Java, C#, and other languages in the same league. All too often some code somewhere gets a null value where it shouldn't, stores it somewhere without checking for null, and then another piece of code down the line extracts that value (which is not supposed to be null!), passes it around to methods (which pass it to more methods, etc), and eventually crashes with a NullReferenceException - good luck trying to track down the original point of error!
I can illustrate the concept of a null-free language with examples from Haskell.
With Haskell types, you can specify all the valid values of a particular bounded type (the same is true for non-bounded types, but its more obvious for bounded ones):
data Day = Monday | Tuesday | Wednesday | Thursday | Friday | Saturday | Sunday
Something of type "Day" cannot be NULL. It must be one of the days of the week. It's impossible to construct a value of a "Day" type without "assigning" it one of these values.
But then what if you want to handle a case where it might be none of these? There's another type for that called "Maybe", and you can wrap "Day" (or any type) in "Maybe" to indicate that it might be none of these. So "Just Monday" is a value simultaneously indicating non-null, and providing the Day value. "Nothing" indicates NULL or "none of the above".
For instance, if you write a function which gives the next day of the week, given a day of the week, it should input Day and output Day. It doesn't make sense for either its input or its output to be NULL. That is, it should have type "Day -> Day".
But if you want to handle for instance, a case of user input or parsing, where they might not give a valid day, then you should use the type "Maybe Day" or something similar.
Values of "Nothing" in Haskell roughly correspond to NULL except that the type system differentiates cases where something might be NULL and cases where something promises not to be NULL.
This turns out to be a useful distinction :)
peace,
isaac
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)".
Javascript + Nintendo DSi = DSiCade
If I have no apples, do I have an object that represents my lack of apples? No, I simply have no apples.
Clearly you need to take your common sense particle. Then you could have both.
Very good! I like this explanation. No mod points today, unfortunately :(
The compiler can do anything it damn well pleases, as long as the end result acts like it should.
The compiler certainly can dereference the pointer. It can also throw in a call to sin(42), a write to some memory containing the current line of code, and a system call to check for pending debugger stuff.
None of this would make the high-level view of things be anything other than the required short-circuit evaluation of the given code.
The compiler depends on the OS to set up certain things, including the memory at address 0.
If I remember right, *(int)0==0 on this system.
It's totally legit. The C standard says nothing about how the assembly code behaves, or even that there is any assembly code. (C can be an interpreted language)
Are you adequate?
We do "if (foo && *foo == CONSTANT)" like so...
The programmer wants to access *foo, unless it is NULL. We will thus do so. Additionally, we know that *NULL will not fault (on the AIX operating system) and that it will give us a zero. Thus, we can access *foo in any case.
The code becomes:
tmp=*foo; if(foo && tmp==CONSTANT)
The C standard only places requirements on an abstract machine. Underneath it all, the code could be getting executed by a bunch of monks who chisel computations into blocks of granite. It doesn't matter if one of the monks takes a bathroom break or whatever. The C standard doesn't care.
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)".
What have you gained by substituting one test for another?
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".
Javascript + Nintendo DSi = DSiCade
SearchTerms: opcode C4C4 bop "jim hatfield"
0xC4C4 is an invalid instruction, generates interrupt 6. For one operating system this interrupt is handled by KiTrap06 where C4C4 can be recognized as a BOP and possibley handed to NTVDM.EXE.
http://nedbatchelder.com/text/hexwords.html
nosig today
Coming from the picture of ignorance himself on the internet in End of Days (slashdot's ultimate douchebag).
Go spout your never done this kind of work youself blabberings to yourself because they usually totally lack any technical content whatsoever and most certainly that from you yourself without citing somebody who does know what they are doing which anyone can do. You are technically challenged in this science as well as mentally challenged obviously and the fact that you just do not have the means in this science to do so yourself.
To this reply he'll post as ac next because he was caught in that much this week here already. Talk about stupid and thank goodness End of Days the moron is stupid enough to be a registered user here chasing useless karma points which makes him ridiculously simple to track because of it.
End of Days because you like to screw with others the return screwing is not going to stop being directed your way just to teach you a lesson you dumb shit little not man (more like the deceitful little typical nerdy wanna be bitch you are) and there's not a thing you can do about it. Time to put the other shoe on your foot and laugh at you while doing so, so you can see how it feels. Come on helpless wanna be. Try to stop me. You're not intelligent enough to do so.
I can't wait to see his ac reply too like usual. Who is the idiot End of Days think he is fooling in trying to do that?
I am very happy that I managed to completely ship around having to program in C/C++. And mostly for that horrible pointer and variable mess that it resembles. Try crashing your Haskell program that way. It will only work if you supply it with data via the foreign function interface, from... you guessed it: C.
I think we should brush Haskell a bit up so it plays nice with direct hardware access (interrupts, registers, and so on), optimize its compiler a bit more, and replace C by it.
Of course this will not happen in the next 10 years. But luckily, I can program in whatever I want, and even re-implement software in Haskell, if I absolutely have to.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
That's a neat idea. It kind of blew my mind for a second. Members that don't even exist. I see what you mean by this being a paradox. Not sure how this could be addressed in the typical "C-family" of compiled languages. Maybe in some other programming paradigm. Seems like Perl does stuff like this, being able to dynamically modify the structure of classes and objects at runtime. One one hand you fall back on the crutch of doing the same type of existence checking with "if defined()" instead of "if NULL", but on the other hand if you are using iterators then it falls neatly into place.
"You cannot find out which view is the right one by science in the ordinary sense." - C.S. Lewis on Intelligent Design
But with modern memory management, I suppose it would be no more difficult to have the memory manager set aside that page as invalid, as it does with page zero.
Yeah, chasing karma, that's me.
I don't need to bother. I have more accounts than you'll ever realize.
Your hand is always full. If you don't have an apple, you may have an orange. If you don't have an orange, you might have any of a million other things. When your hand contains air, we say it is empty, even though it is not. Emptiness is only an abstraction, and it is assigned to a specific content.
NULL is the air in your hand.
There you are. End of Days admits to doing replies under multiple usernames here as well as ac to make it appear that he has the backing of others in order to attempt to do so as well and now being caught in it via his own admission of his modus operandi. You are too easy to out think and You only show you are a bitch because you practice that which bitch not men do. How can limp whimps like you even face women when you are women yourselves in being not men? Your continued stupidity continues to manifest itself here and helps prove the points others state about you. I have to thank you for being so stupid and so easy to flush out here as well as showing us all how easily you fold under pressure once someone pushes the right buttons in your limited brain but most of all for the fact you are the only woman on the planet with a penis because how you act and go about things online is not what men do. At least not real men. An ac can do the same easily but then again you are too stupid to know how that is done to beat the ac account limitations. Your kind, worms, do this online because they think there are no repercussions. Well there is now because this account which is only 1 of multiple you admit to using here? Give up on it. I am going to take it from you as will others because your reply here is being rightfully put down because of your skimming and lack of know how in this science. I can see you when you were younger lol when other guys were porking your girlfriend and making you do their yard work and you have not changed at all. Here online your kind thinks they can't get caught but you can and have easily because you are stupid. You make real nerds that know what they are about look bad and they probably don't like your kind either. Have all the fake or multiple accounts you want because I'll just bgp find you again easily if you continue this crap. You can only blame yourself as you only brought this on yourself and deserve every second of it. Think twice before bothering us here with your crap again under your other accounts because it is not a load of work to determine who and where you are on this forums. Until then I will just point everyone to this admission of yours under this account so they can see the real you and ridicule you, not man. Every post you make from now on under this account will point to this admission of yours of using multiple accounts here and ac also to make it seem others agree with your massive crap? This time you grabbed a tiger by its tail and I'm going to take it away from you and you will give up this account because of it out of shame little bitch but that assumes little bitch not men like you even have pride and your kind doesnt as there isnt anything to be proud of. Thanks for being so stupid and admitting to how a not man like you really operates and how low you are. Dont wonder why women wont give you the time of day because youre more of a woman than they are.
How is that "the perspective of comp-sci"? And more importantly: what the hell is that supposed to mean in the first place? What is "absence of data," and how do we distinguish it from "a piece of data"? Isn't it all just coded information and rules for interpreting it, in which case, the "absence of data" and the "presence of data" are just a distinction over coded states?
Your "solution," BTW, is pretty much equivalent to using boolean false as the linked list terminator. Yes, I know it's not exactly the same, but basically, it relies on the negation of end.next evaluating to true. That's not meaningfully different from returning null for a failed lookup; you're basically changing (a) the choice of sigil (return something other than null whenfoo.next is a failed lookup), (b) the semantics of negation (so that the sigil counts as false for boolean negation).
Are you adequate?
By thinking about this in terms of "having objects," you're distorting the whole issue.
Think about it instead in terms of encoding facts about the world. If we want to record the fact that you have an apple, and that I do not, there are several ways we could choose to encode this. Some of them would require you to explicitly have an informational token for each fact, so that you needed one piece of data to encode "Joe has an apple," and another one to encode "Mary doesn't have an apple." Another scheme might have you just encode who has an apple, and specify that if it is not explicitly recorded whether some specific individual has an apple, you should infer that they do not.
One kind of representation is appropriate for some applications, and one for others. Vague generalities about apples and "having" do absolutely nothing to guide how one should encode information in a computer.
Are you adequate?
but aren't most applications, where performance is a consideration, written in C or C++? from what i have read, even C is to high level for many game coders as far as certain loops are concerned, so they will tweak them in assembly. i imagine writing in a more abstract language, would make this process impossible. what would you recommend as an alternative for writing ultra-fast programs? (serious question, i am a bit of a noob)
Almost nobody writes assembly for games anymore. Some game are even done in (*gasp!*) Java or C++.
The bottleneck is not the CPU anymore. It's the GPU. So the language you write most of the code in doesn't matter nearly as much as it used to. The DirectX/OpenGL calls matter. And the Pixel Shader code matters.
Besides, compilers are so good at optimizing code that the vast majority of programmers would be hard pressed to do better by hand.
As you can see by the definition in iluvcapra's response, the C standard is vague enough to make "volatile" nearly worthless.
In the Linux kernel, the normal usage of volatile is only considered legitimate on the clock tick counter called "jiffies". (there is also a gcc-specific meaning for assembly language) The use of volatile for memory mapped IO or thread-related stuff is considered a bug.
Volatile is the wrong concept anyway. It marks a data object, but you really want to mark an access or the boundry between two accesses. The proper concept is a barrier and/or special read/write operations.
The computer system is a virtual simulation or abstract of the real world.
There are many differents between them, and there are no way to sync them.
If we are careful in reason mind, to use the computing system in the way it is designed, and stop trusting it when it is not working in designed condition, then we are safe.
However, we have developed a cultural that we use the computer system without thinking its limit, without reasonable doubt. Too much trust there.
The same abstraction difficulty happens all over the development, there are too many short cuts, clever hacks that make the computer system not represent the real world correctly, but all were not documented, no body even the developer known about it.
All computer systems have such a fatal error waiting. Even you build in a safety device in the computer language will not solve the problem.
Frankly, just on its own, without more context, it's not possible to tell. It all comes down to whether he's saying it to boast of how important he is, or whether he is simply admitting a mistake that was widely copied by others.
Are you adequate?
C and C++ don't have any notion of a "null" pointer. By convention, a pointer of (void*)0/NULL is invalid. However, a NULL pointer can be valid.
BEHOLD! A VALID NULL POINTER ! (Only works on linux. :P )
int *null_ptr = mmap( (void*)0, sizeof(int), PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_FIXED, -1, 0);
if(null_ptr == (void*)-1)
printf("null_ptr = %p\n", null_ptr);
*null_ptr = 42;
printf("*null_ptr = %d\n", *null_ptr);
(You have to tweak /proc/sys/vm/mmap_min_addr for this to work)
I think one thing that's confusing people in this argument is the failure to distinguish between logical aspect of data and the physical representation thereof.
Variant types, as implemented by a language like Haskell, are primarily a logical construct. A variant type is a type whose members are the union of tagged values of other specified types. This kind of definition says nothing about pointers or null references; it's all about which values are members of each type.
Singly linked lists are a variant type, whose members are (a) the empty list, (b) pairs that contain a list element and the rest of the list. This type can be physically represented in many ways, some of which will use nulls to represent the empty list, some of which will use a different primitive sigil value, and some of which will use a pointer to another memory object that signifies the end of the list. These are all equivalent from the logical perspective; the choice between them comes from implementation details, or application requirements that restrict the physical representation (which is why C is good for low-level programming and Haskell is not, since C gives you more and easier control over how your data is physically laid out).
This is probably the wrong kind of definition at the logical level, because it has more subcases than it needs. In pseudo-Haskell, here's one that would be simpler:
In English, a BTree of element type a is either the Empty tree, or a Node that has three fields: a left BTree of a, an a, and a right BTree of a. (This definition treats a "leaf" as a node where both branches are the empty tree.)
Are you adequate?
I think the main issue here is that when you're developing a type system, you generally want the types to classify objects into certain categories that tell you things about them. So if I define some kind of a reference type, what I am saying is that an object of that type is a kind of a pointer to something.
So now, if I allow null references, then my reference type is really saying that "objects of this type are pointers to either something or nothing". That's all well and fine, but it makes the type less precise, in that it conveys less information about the object it is categorizing.
As it turns out, this lack of information is quite important because one of the most common things you have to check when you're given a possibly-null reference is whether or not it is null. You need to insert "if (ptr == NULL)" all over the place. Thus reference types which allow null references ultimately give me less expressive power.
Most of the time null references are created because either an error condition must be reported (e.g. malloc fails), or it is unclear at some point in time whether or not an object exists. Error conditions can be better signalled using exception handling. As for cases where you're not sure if the object exists or not, then one possibility is to use an option type like in Standard ML:
datatype 'a option = SOME of 'a | NONE
This is a polymorphic type that says that either the object exists or it doesn't, and you can find out what the situation is by using a "case" statement on the datatype constructors:
case foo of ... [do something with x] ... ... [the object doesn't exist] ...
SOME(x) ==>
| NONE ==>
Thus by combining a reference type without nulls with an option type, you can create "reference option" types, which have all the flexibility of "with-null" reference types.
But the cool thing is, you only ever need to check the "null-ness" of the object only once; once you do the check, you're handed a reference object which is guaranteed to be non-null. Thus you can easily partition your code into parts that will do the non-null check and those that assume all references handed to it are valid.
This is why a good type system can make programming so much cleaner and easier :)
I tested hundreds of Mac software applications 'Back In The Day'. A bit more than half of all of them banged onto location 0. About 100% of Microsoft Mac apps crashed. This happened to not (immediately) crash the Mac because the Mac just happened to have RAM mapped there, but, since multiple applications were resident in memory, taking turns shooting at 0.Long, "Difficult to debug problems, often not repeatable, soon arose".
[I do love that phrase; it covers so much agony so concisely].
The Mac had a memory heap structure with "handles", which aimed at "pointers", which aimed at "memory blocks". From time to time, just to amuse developers, the Mac would compress memory to get rid of stale stuff. The handles would be updated but, a zero would go into the pointer you were trusting ...
I was busy teaching the Atari ST 68000 computer to be a Mac at the time. The Atari ST had ROM mapped to locations 0-7. It bus-errored every time someone used a Nil pointer. This looked unsolvable unless I wanted to patch two zillion Mac programs.
I finally looked at the problem in a very, very simple manner, and discovered the IW (instruction word) that had caused the crash was on the stack, and the PC (program counter) was a bit past the crash point due to prefetch. A dim flickering flight appeared over my head. What if I "back up" the PC to the Evil Instruction, disassemble it to get its length [I hear you sigh at the thought of writing a disassembler, but I did], advance the PC to the next instruction (so we're just skipping over "the store into 0.Long" here), put all this on the stack, and treat it like a "normal" exception interrupt ... "Return from Exception."
And it worked! The 68000 came back from a crash!
That one thing made all the difference.
To this day I have wondered, though ... if the Atari ST had ROM there ... what happened to all the data written to location 0?
*grin*
David Small
Once I've written a class for arrays, where you could turn range-checking on and off by a compiler-directive (so turning it off kicked the range check out of the binary code, making it fast again). This gives me the Idea of making a wrapper class for pointers - something like
// Might include garbage collection
// writes 5 to stdout // throws an exception
#define nullpointer_safety
template<class T> class Pointer {
private:
T* pointer;
public:
Pointer(T* p) { pointer=p; }
Pointer(const Pointer<T>& p) { pointer=p.pointer; }
Pointer() { pointer=NULL; }
bool operator=(const T* p) {return pointer=p;}
bool operator=(const Pointer& p) { return pointer=p.pointer; }
bool operator==(const T* p) {return pointer==p;}
bool operator==(const Pointer& p) { return pointer==p.pointer; }
bool operator!=(const T* p) {return pointer!=p;}
bool operator!=(const Pointer& p) { return pointer!=p.pointer; }
void new() { pointer = new T; }
void new(T x) { pointer = new T; pointer* = x; }
void delete() { delete pointer; }
T& dereference() {
#ifdef nullpointer_safety
if(p==NULL) {throw "trying to dereference a null-pointer";}
#endif
return *pointer;
}
};
// examples:
// Pointer<int> w; w.new(3);
// Pointer<int> x = new int; x.dereference() = 5;
// Pointer<Pointer<int>> y = &x; std::cout << y.dereference().dereference();
// Pointer<int> z; if(z!=NULL) { z.dereference() = 7;}
// z.dereference() = 3;
Although I'm not sure if this works with function-pointers...
The MAFIAA is a bunch of mindless jerks who will be the first up against the wall when the revolution comes
it's better to crash early than to pass the wrong object.
He proposes using the following format (I believe he uses it in qmtp) instead of ^M terminated lines: first write the number of characters in ASCII digits, followed by a space to indicate the end of the number, followed by that number of character, and a ^M.
In any case, you have to take care of quite a few things when serializing data for writing to disk / transmission.
These two strings walk into a bar and sit down.
The bartender says, So whatll it be?
The first string says, I think Ill have a beer quag fulk boorg jdk^CjfdLk jk3s d#f67howe%^U r89nvy~~owmc63^Dz x.xvcu
Please excuse my friend, the second string says, He isnt null-terminated.
More specifically when designing one of the very first OO languages.
TFA also mentions Spec#.
It should be mandatory for *any* Java programmer to use the @NotNull annotation not only on every single method return value but also on every single method parameter.
If someone think this is impossible then it should be pointed to two things: millions line project doing just this (and having guidelines and "checkstyles" verification enforcing it) and a good OOA/OOD book (OO Analysis / OO Design).
Null, as stated by the almighty Hoare, was a brainfart.
Hello
The OO system of Seed7 works without NULL pointers. See:
http://seed7.sourceforge.net/manual/objects.htm
Seed7 variables always refer to a legal value. This has advantages in many areas. There are no problems with with uninitialized variables and no NULL pointer errors are possible. But it is als not possible to use NULL to describe a missing value. If this feature is needed it must be reached in a different way. In most cases the default value provided by every type can be used as value with the meaning: Not initialized. The default value is just a normal value. You will not get an exception when it is used. IMHO the advantates of not having NULL outweigh the small drawback to describe missing values in a different way.
Greetings Thomas Mertes
Seed7 Homepage: http://seed7.sourceforge.net/
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.
Fuck off, APK.
Fuck off, APK.
How're you enjoying being stalked by APK? This could last for months, you know.
http://slashdot.org/comments.pl?sid=1145195&cid=27058191 Take a peek there, lol (& look @ his reaction here now). Truth hit home, & nothing hurts like the truth, & TOO EASY to push the right buttons in your limited brain... lol! Yes, but it really DOES look like the "end of days", of your using that 1 of many admitted registered accounts you use, to be a self modding loser no less here on this forums, lol, so keep posting as "End of Days" won't you? LOL, caught red-handed in the act of admitting to lameness! So how does it feel taking the same treatment you give others, now that the shoe is on the other foot in someone hassling you as you do others here constantly and are caught in errors due to your skimming as you were also caught in within the url exchanges above? You obviously are a miserable person who likes to spread that to others and the humiliation you brought on yourself was your own doing period. Don't worry: I'll keep pointing out you admit to using multiple accounts here in a bogus manner, so keep posting as End of Days, if you wish (I'll let YOU, take your name from you, as payback - again, you only did this to you, not I). Oh and like usual? Mommy isn't here to respond to one of your fits, so giving orders here is useless boy. Grow up, you do not own this website nor are you a moderator here, get it, "dull skull"?? Apparently not.
http://slashdot.org/comments.pl?sid=1145195&cid=27058191 Take a peek there, lol (& look @ his reaction here now). Truth hit home, & nothing hurts like the truth, & TOO EASY to push the right buttons in your limited brain... lol! Yes, but it really DOES look like the "end of days", of your using that 1 of many admitted registered accounts you use, to be a self modding loser no less here on this forums, lol, so keep posting as "End of Days" won't you? LOL, caught red-handed in the act of admitting to lameness! So how does it feel taking the same treatment you give others, now that the shoe is on the other foot in someone hassling you as you do others here constantly and are caught in errors due to your skimming as you were also caught in within the url exchanges above? You obviously are a miserable person who likes to spread that to others and the humiliation you brought on yourself was your own doing period. Don't worry: I'll keep pointing out you admit to using multiple accounts here in a bogus manner, so keep posting as End of Days, if you wish (I'll let YOU, take your name from you, as payback - again, you only did this to you, not I). Hilarious and get over the fact you have no power or authority here as the site owner or even the admins here. So quit giving orders, this isn't your mama who responds to that form of manipulation here boy.
http://slashdot.org/comments.pl?sid=1145195&cid=27058191 Take a peek there, lol (& look @ his reaction here now). Truth hit home, & nothing hurts like the truth, & TOO EASY to push the right buttons in your limited brain... lol! Yes, but it really DOES look like the "end of days", of your using that 1 of many admitted registered accounts you use, to be a self modding loser no less here on this forums, lol, that was caught red-handed doing so & admitting to it so keep posting as "End of Days" won't you? LOL, caught red-handed in the act of admitting to lameness you 'court jester' clown! So how does it feel taking the same treatment you give others, now that the shoe is on the other foot in someone hassling you as you do others here constantly and are caught in errors due to your skimming as you were also caught in within the url exchanges above? You obviously are a miserable person who likes to spread that to others and the humiliation you brought on yourself was your own doing period simply because you are stupid. Don't worry: I'll keep pointing out you admit to using multiple accounts here in a bogus manner, so keep posting as End of Days, if you wish (I'll let YOU, take your name from you, as payback - again, you only did this to you, not I). What is it like being not only a psycho stalker on the internet, but also one stupid enough to get caught in using multiple accounts to "mod himself up" & 'self-support his points'? Hilarious - a moment of TRULY HIGH COMEDY! Some people never learn... and, apparently, you can dish it out, but you cannot take it! like a typical online punk.
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.
The result from a map.get("key") call often isn't dereferenced. Often the whole reason to make a get() call is to check the existence of a value. Some other times we simply want to put whatever we get into another collection type without actually using it.
In my mind, NULL to programming languages is like 0 to numbers. The conceptual breakthrough in the invention of 0 lies in that we realized we could use a symbol to denote the case of "nothing", and thus save ourselves a lot of trouble. For example, some early civilization used a space to represent "no value" in their _hand-written_ numbers. Imagine all the confusion that would have caused - "is that one space or two?"
Tyranny isn't the worst enemy of a democracy. Cynicism is.
what else would you terminate it with without using something the string may contain?
terminate every string with "HAHAHA DISREGARD THAT I SUCK COCKS"
in that program of mine, writing an array of floating-point numbers.
You were correct. A flood of ac posts came right afterwards. Nice job flushing this multiple registered account loser 'The End of Days' right out of the camoflage thicket he likes to create using ac replies as well as his using multiple registered accounts to 'support himself' and mod himself up with. I saw that here, where he slipped and did the reverse of what he did here (replying only as himself after you said he would reply ac (which he has now, a flurry of them, lol, you got to him with his own words apparently)). Here, he was harassing others as he is wont to do by doing a load of ac posts -> http://slashdot.org/comments.pl?sid=1144517&cid=27027131 and then he posted miles deep into that exchange which gave him away I felt. Nobody would be reading that deep into that posting by that point and it appears to me that 'The End of Days' slipped and forgot to post as ac as others noted there also. It looks like it really is 'The End of Days' of The End of Days, using this 1 of his admittedly many registered accounts here. He's as easy to read as a book and guessing 1 of 2 numbers (easier) given to guess on (which is 50/50, but you have higher odds on The End of Days, and the proof came right after in you being correct he would flood us with ac posts).
Your kind are the lowest kind of scumbag available online in being imposters and impersonating others as well as your using multiple accounts here to try to make yourself look good. Why don't you just give up, leave, or something that is not here around us because you make this entire website look bad The End of Days. It looks like it may be the * End of Days * of you using The End of Days as 1 of your admitted many registered accounts you post with here and use to mod yourself up with, and that sir, makes you a scumbag loser. I am sure others agree because just judging by your other posts on this website this week that seems to be the case. He is going to paranoically say "apk etc. etc." and sorry to disappoint you I am not this apk you told to fuck off. That's part of what gives you away by tossing names around. I looked at the trouble you caused over at windows it pro and now you are starting the same thing here Jeremy Reimer by keeping your multiple accounts here that you used over there to try to make yourself look good and you and your fatboy friend Jay Little were laughed out of there. Keep it up, because it is funny to watch you squirm now that you've been caught admitting to posting here under multiple accounts to mod yourself up, and I predict you are heading for another fall again Jeremy Reimer or Jay Little.
http://slashdot.org/comments.pl?sid=1147437&cid=27056793 - Especially with all those multiple registered accounts you must have to juggle as you use those here to mod yourself up with and to make it appear as if others support you. Looking at your history here in your username shows me quite otherwise, and that people despise you here, especially this apk guy. I don't blame him.
Why dont you instead of ruining threads with good information in them?
Why don't you instead of ruining threads with good information in them?
One person's problems is another person's fortune.
I see you are now impersonating me at the forums @ 4chan.org, by registering as myself there & posting excerpts of my posts here @ slashdot (some in their original form and altered ones as well from other sites also) as well as your admitting to using multiple registered accounts here (to mod yourself up and to make it appear as if you have supporters (not)).
Bad move: That is just going to make me go to 4chan.org's hosting provider and have them remove it, & if that fails, I will employ the local law enforcement in their area to do so and to prosecute you as well, & strangely I think it's going to go FEDERAL pal.
(Oh, & by the way - I've had to do this before to a Mr. Jeremy Reimer and Mr. Jay Little of arstechnica, who had their websites @ CrystalTech.com & petitiononline.com removed in their entirety or in large portions & was completely successful in exposing those 2 for the same type of garbage you are pulling here on this site and over @ 4chan.org):
http://dis.4chan.org/read/prog/1235936964/1-40
I came across this impersonation of myself online (via cuts & pastes of my posts here & from other websites, some original, some altered) right after I posted about Windows VISTA, Server 2008, & Windows 7 removing port filtering and also making it impossible to use a 0 inside of a HOSTS file to block out bad IP addresses. -> http://tech.slashdot.org/comments.pl?sid=1143349&threshold=-1&commentsort=0&mode=thread&pid=27012231
This impersonation of myself "oddly" seems to have happened only after when I also caught one of your own here @ slashdot, "The End of Days" -> http://slashdot.org/comments.pl?sid=1147437&cid=27056793 caught admitting to using multiple registered accounts to "mod himself up" here and to use those same registered accounts to mod down others (on top of his use of ac submissions as well to also make it appear he has further supporters).
The "The End of Days": I would be a bit worried now were I you, because now it's going to go out of my hands @ this point, & you're the only person who might have any reason to do so. Now, I will just go to the hosting provider involved for that website to take care of it, & if I get resistance of any kind, I will prosecute yourself, and any others involved, to the fullest extent of the law.
Heh, it looks like this is truly "the end of days" of you being online, period, much less you constantly bothering others here or elsewhere online via your bogus methods of impersonating others or posting under diff. account names here & at other forums in order to do so. You only bring this on yourself, & it only takes me minutes to take care of.
APK
P.S.=> It's one thing to shame yourself here being caught admitting to using multiple registered accounts to mod yourself up with (something us ac's can never be accused of) ,b>but, to go & impersonate me there has legal implications, and that is just plain dumb... I have no pity for you here, this is a lesson you will have to learn just as Jeremy Reimer &/or Jay Little of arstechnica had to before (my friends & family suspect it is they once more, but I'll reserve judgement on that until the law & hosting providers do their end of it)... apk
Why don't you instead The End of Days? You have been caught admitting to using multiple registered accounts here and I cannot see any reason for that myself, other than you using them to mod yourself up and to make it appear as if you have supporters here, which at this point you clearly do not.