Timeline for If null is bad, why do modern languages implement it?
Current License: CC BY-SA 3.0
22 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 22 at 15:06 | comment | added | Anomaly | The best option here Is a union/enum/struct with potential values of Alive, Dead<deathDate: DeathDate>, and then DeathDate is another union/enum/struct which can be DeathDate<Unknown> , where Unknown is a unit type akin to null/None, or DeathDate<date: Date>. Depending on the application - say, genealogy - you might even want to get even more detailed and add the possibility of approximate dates or date ranges, when there is uncertainty, but it is important to convey some information, as well as range and degree of confidence for that information. | |
| May 22, 2019 at 8:28 | comment | added | Deduplicator | @jon-hanson Yes, you painted it green. Big deal. | |
| May 22, 2019 at 7:24 | comment | added | jon hanson | @Deduplicator No, that's self-evidently not what I said. | |
| May 22, 2019 at 0:28 | comment | added | Jim Balter | "As others said, the null was just shifted around" -- as I noted, this completely lacks understanding. std::option is a monad. There is no null in the semantics of the language. | |
| May 21, 2019 at 20:11 | comment | added | Deduplicator | @jon-hanson So, either a date OfDeath or Null? | |
| May 21, 2019 at 20:09 | comment | added | Deduplicator | @JimBalter As others said, the null was just shifted around, in case of rust to std::option. Of course, now having the default be non-nullable is extremely useful. | |
| Aug 17, 2017 at 20:47 | comment | added | Adam Hughes | Great answer, have been thinking about a practical purpose to having null all day... | |
| Apr 10, 2016 at 18:45 | comment | added | sara | in the case of relational databases, any column with a nullable field can have that column extracted to another table with a foreign key constraint on the original table. in other words: a 0..1 relation does not imply a need for neither null nor default values. | |
| Nov 14, 2015 at 16:55 | comment | added | jon hanson | Wouldn't it make more sense to separate out a person's state? I.e. A Person type has a state field of type State, which is a discriminated union of Alive and Dead(dateOfDeath : Date). | |
| Apr 27, 2015 at 1:31 | comment | added | Jim Balter | None of these answers show any understanding of the state of the art. Null has been completely removed from the programming model of Rust. Ceylon has null but it is always safe; there is no NullPointerException or equivalent because it isn't possible for it to occur. This is without any loss of power. | |
| May 11, 2014 at 3:02 | review | First posts | |||
| May 11, 2014 at 4:51 | |||||
| May 5, 2014 at 6:57 | comment | added | Perseids | the programmer using the reference judges wrong. The advantage of a Maybe type with non-null references is that the programmer responsible for the reference can (and has to) explicitly tell you whether you need to consider the none-value case or not. | |
| May 5, 2014 at 6:54 | comment | added | Perseids | @RualStorge The argument is more convincing if you look at it from the other direction. We sure need Nulls or Maybes for some functions, but the real advantage of having a non-null reference type by-default lies in all the other functions that don't need null values. As it is now (with null references) I have to ask myself with every reference "could the author of the function I got the reference from or the callee under reasonable circumstances put a null in there" (reasonable is in there to exclude unrecoverable error situations). Most of the time the answer is "no", but sometimes | |
| May 2, 2014 at 20:57 | comment | added | David | +1 for distinguishing between "no value" and "unknown value" | |
| May 2, 2014 at 20:45 | comment | added | leftaroundabout | @RualStorge: no matter what you call it you'll need to handle it – to some degree, sure. But if you make it explicit it becomes way more obvious how to correctly handle it. And indeed easier if the language is powerful enough, since option types form a monad, so it can basically be as simple as just changing the signatures to mention there's a lack-of-value possibility; the handling itself is taken care for by the compiler (with the help of some mighty mathematical proofs). | |
| May 2, 2014 at 20:23 | comment | added | Eric J Fisher | We're not talking a specific language here. C# and Java were provided as examples, but I am answering considering other languages like PHP, TSQL, etc. and Mpyro is correct I was using TSQL as my example point because it's probably the least accommodating here, but the problem does extend to many other languages. I do believe you could get around nulls entirely with a language as modern as C# or Java, but I think that's more fighting around the problem than fixing it. We can handle nulls, Empty, Options, Maybes, etc. End of the day no matter what you call it you'll need to handle it. | |
| May 2, 2014 at 20:13 | comment | added | zduny | I guess RualStorge was talking in relation to SQL, because there are camps that state every column should be marked as NOT NULL. My question wasn't related to RDBMS though... | |
| May 2, 2014 at 20:05 | comment | added | user7043 | Nobody is arguing that there shouldn't be an lack-of-value value, they are arguing that values that may be missing should explicitly be marked as such, rather than every value being potentially missing. | |
| May 2, 2014 at 19:58 | comment | added | Doval | I'm not clear on what you mean by "it's not null, it's a data type. Buf if you like into your int type it's value property is null." | |
| May 2, 2014 at 19:51 | comment | added | Eric J Fisher | Correct, so in a case lets say we have an int variable that we've make clear was an int type, so technically it's not null, it's a data type. But if you look into your int type it's value property is null. So while type is how it should be, it's really just shifting the null. | |
| May 2, 2014 at 19:45 | comment | added | Doval | Null serves a very valid purpose of representing a lack of value. An Option or Maybe type serves this very valid purpose without bypassing the type system. | |
| May 2, 2014 at 19:42 | history | answered | Eric J Fisher | CC BY-SA 3.0 |