3 ms·

I think you are missing the point. The problem is that for the most part needing to check whether an object is null/"valid" should be an exceptional case, not

I think you are missing the point. The problem is that for the most part needing to check whether an object is null/"valid" should be an exceptional case, not a common one. Most object variables do not need to have the optional/null state. For languages that allow every object to be null you create a situation where you need to have null checks for every object you encounter unless you come up with some error prone convention outside the language itself. Every method/function has to handle the nulls, it's not clear whether an object will be null when passed into a method or not, and if you are writing APIs for people to use, you must check for nulls because you cannot expect much from the user of the apis. TLDR; Having non null objects by default reduces the amount of code, which in turn increases the correctness of the code.

barrkel 14y ago
needing to check whether an object is null/"valid" should be an exceptional case Handily enough, C#, Java and similar languages actually throw an exception when you try to work with a null reference as if it wasn't null. These exceptions are generally only cryptic when the null references are stored somewhere other than the stack before being manipulated. That is, so long as foo(null) throws an exception before foo() returns, it's no big deal to diagnose, and mostly unnecessary to check the value of the parameter as it passes through the graph of method calls. (To a degree I'm arguing a devil's advocate position, as I have a lot of sympathy for encoding not-null-by-default into the type system.)
- anonnona 14y ago
  In that world you have bugs lying in wait inside the code ready to rear their head at inopportune times, better to not allow their existence at all. Also in terms of difficulty of fixing bugs its a lot easier to fix bugs at compile time on your machine then it is later on in the release cycle. I think this kind of attitude is the reason why maintenance is the most expensive part of software development. It's also the work involving the most drudgery.
  - barrkel 14y ago
    In my experience, the two biggest reasons for expensive maintenance are (a) not all the code is understood by the people maintaining the system because past maintainers have moved on, and (b) assumptions have been made for performance or simplicity reasons that remove abstraction boundaries and embed assumptions about how the whole works inside different parts of the system, such that when one part needs major change, many other parts also need careful change; this is made worse by (a), because later maintainers usually only understand a subset of the individual parts. This isn't something easily fixed by a compiler or language feature. There's no magic bullet. Bugs "lying in wait" are a minor problem; if they lie in wait long enough, they are almost by definition not a problem at all.
cube13 14y ago
>The problem is that for the most part needing to check whether an object is null/"valid" should be an exceptional case, not a common one. It's possible to code around it if you're presenting a packaged executable or product, but if you're creating an API of any sort, or dealing with user input, it should be a standard case. Blank inputs or null cases should always be checked in that case.
- anonnona 14y ago
  I don't think you understand. If you don't allow null by default in your type system then you don't have to check for it when you don't need it. Dealing with user input is a separate issue, yes you need to validate it. The problem with every type allowing null is that it infects EVERY object for a situation that isn't always needed or wanted.

barrkel 14y ago

needing to check whether an object is null/"valid" should be an exceptional case Handily enough, C#, Java and similar languages actually throw an exception when you try to work with a null reference as if it wasn't null. These exceptions are generally only cryptic when the null references are stored somewhere other than the stack before being manipulated. That is, so long as foo(null) throws an exception before foo() returns, it's no big deal to diagnose, and mostly unnecessary to check the value of the parameter as it passes through the graph of method calls. (To a degree I'm arguing a devil's advocate position, as I have a lot of sympathy for encoding not-null-by-default into the type system.)

anonnona 14y ago
In that world you have bugs lying in wait inside the code ready to rear their head at inopportune times, better to not allow their existence at all. Also in terms of difficulty of fixing bugs its a lot easier to fix bugs at compile time on your machine then it is later on in the release cycle. I think this kind of attitude is the reason why maintenance is the most expensive part of software development. It's also the work involving the most drudgery.
- barrkel 14y ago
  In my experience, the two biggest reasons for expensive maintenance are (a) not all the code is understood by the people maintaining the system because past maintainers have moved on, and (b) assumptions have been made for performance or simplicity reasons that remove abstraction boundaries and embed assumptions about how the whole works inside different parts of the system, such that when one part needs major change, many other parts also need careful change; this is made worse by (a), because later maintainers usually only understand a subset of the individual parts. This isn't something easily fixed by a compiler or language feature. There's no magic bullet. Bugs "lying in wait" are a minor problem; if they lie in wait long enough, they are almost by definition not a problem at all.

cube13 14y ago

>The problem is that for the most part needing to check whether an object is null/"valid" should be an exceptional case, not a common one. It's possible to code around it if you're presenting a packaged executable or product, but if you're creating an API of any sort, or dealing with user input, it should be a standard case. Blank inputs or null cases should always be checked in that case.

anonnona 14y ago
I don't think you understand. If you don't allow null by default in your type system then you don't have to check for it when you don't need it. Dealing with user input is a separate issue, yes you need to validate it. The problem with every type allowing null is that it infects EVERY object for a situation that isn't always needed or wanted.