Waaah, I don't get paid to use new shiny languages
-
@topspin In this case, the "block adblock" script wasn't separated in any meaningful way (apart from the actual "show popup" method that was helpfully sitting right in the global namespace) from the script that made the rest of the site work
-
@Gąska I'm not confusing anything at all. The assumption that null == null is going to byte you in the ass.
This all goes back to the Haskell-Curry isomorphism theorem. On the side of logic, you have:
- proofs
- universal quantification
- existential quantification
On the side of computation, you have:
- programs
- value initialization
- value searching, where you enumerate or otherwise search through all possible values in a type
1, 2, and 3, all correspond to each other, under the Haskell-Curry isomorphism.
The math is an idealization of what a real language does. I'd go as far as to say that the math is a better language, but there's always going to be a mismatch between it and a "real" language like C++ which "has nulls" and it's treated like just another "value".
If you take the POV that C++ has nulls and they're real values, then the math is going to sound like confused nonsense. But if you take the POV that the math is describing an abstract notion that about nothing-ness that happens in every language and aspect of reality, then you might be more impressed.
-
This post is deleted!
-
@hungrier said in Waaah, I don't get paid to use new shiny languages:
@topspin In this case, the "block adblock" script wasn't separated in any meaningful way (apart from the actual "show popup" method that was helpfully sitting right in the global namespace) from the script that made the rest of the site work
-
@topspin said in Waaah, I don't get paid to use new shiny languages:
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
@error said in Waaah, I don't get paid to use new shiny languages:
For one site, I actually used an AST parser and rewrote significant chunks of their JS before it ran.
That's... horrifying.
Pretty cool if you ask me.
I don't know much about GreaseMonkey scripts (there seem to be surprisingly few good introductions) but the one or two sites I cobbled something together that needed to change existing things instead of just adding more, I did something pretty fragile with string replacing. Should probably ask how to do it better, but that's for a different thread (and time when I actually care).I did it by writing custom Babel plugins. Which are easy to start with but somehow completely absorb me in the sense of "what, it's been six hours and it's 3am now?"
This is very useful for visualizing/previewing (use
@babel/parser
for the correct AST):
-
@Captain said in Waaah, I don't get paid to use new shiny languages:
@Gąska I'm not confusing anything at all. The assumption that null == null is going to byte you in the ass.
Sorry, I'm just not seeing it. Maybe I've spent too little time in academia to notice "the obvious", but I'm completely lost on what you're going about. Could you give a specific example of when math works better when you assume null != null instead of null == null?
-
@Captain said in Waaah, I don't get paid to use new shiny languages:
The assumption that null == null is going to byte you in the ass.
For sure if you're writing SQL.
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@Captain isn't the mathematical bottom type always empty, though? It certainly doesn't make sense for a contradiction type to be non-empty. On the other hand, it wouldn't be the first time a mathematical term doesn't make sense.
Sounds like quite the contradiction!
-
@sloosecannon said in Waaah, I don't get paid to use new shiny languages:
@error said in Waaah, I don't get paid to use new shiny languages:
For one site, I actually used an AST parser and rewrote significant chunks of their JS before it ran.
That's... horrifying.
-
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Captain said in Waaah, I don't get paid to use new shiny languages:
The assumption that null == null is going to byte you in the ass.
For sure if you're writing SQL.
Wait, @Captain has upvoted your post. Does it mean his point wasn't about the maths after all, but only about SQL?
Goddamn it's so hard to get a straight answer from people here sometimes.
-
@Gąska Why would an upvote mean that?
Null is how computer languages handle nothingness. OK.
Different languages do that in different ways, "all" of them are called null.
Nothingness has semantics that some languages break or expand upon. I wouldn't rely on semantics for a concept that are implemented differently in different environments.
For example, consider the mismatch between SQL and C++ nulls. Because in one language null = null, and in another, null is never equal to null, it matters where you do your null checks (and how) on the same data. This would not be an issue at all if null = null in the first order logic. But it's not. Contradiction does not equal contradiction. It's not a value-kinded type of thing. It's a symbol kind of thing.
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Captain said in Waaah, I don't get paid to use new shiny languages:
The assumption that null == null is going to byte you in the ass.
For sure if you're writing SQL.
Wait, @Captain has upvoted your post. Does it mean his point wasn't about the maths after all, but only about SQL?
Goddamn it's so hard to get a straight answer from people here sometimes.
Huh? I was pointing out a real world example of where your assumption about
null == null
will bite you in the ass. I'm not sure what's confusing about that.
-
@Captain said in Waaah, I don't get paid to use new shiny languages:
@Gąska Why would an upvote mean that?
I'm trying to find any possible explanation for why you, an otherwise reasonable person, said something that makes no fucking sense. Usually such things are caused by misunderstanding what the subject of the conversation is.
But now I have a better theory on where the misunderstanding is.
Null is how computer languages handle nothingness. OK.
No, not OK. There are many different kinds of nothingness. For example, zero is also a kind of nothingness. But it's absolutely a real number. An integer, even. You can add to it and subtract it and multiply it and many other things. You absolutely can quantify it. You absolutely can have it inside a set. You absolutely can have a tuple of two zeroes, and it's a meaningful value. Same with null. It might be "nothing" in some narrow sense, but that doesn't prevent it from being an actual, full-fledged, first-class value. And being equal to itself absolutely makes sense.
Different languages do that in different ways, "all" of them are called null.
This part, we agree upon. What we disagree about is what this statement implies. For you (I assume), the obvious conclusion is that null is weird and can't be treated as a real value. For me, the obvious conclusions is that different languages use the same name for different things.
For example, consider the mismatch between SQL and C++ nulls.
Exactly. Consider this mismatch. They behave so differently that you cannot say that they are the same thing at all. They're two separate concepts that should be analyzed separately. There is no one null. There are many different concepts all called by the same word. Null is a homonym.
I was talking about null as in the one you see in Java. Nothing you say about SQL or first order logic is relevant to anything I said about null as in the one in Java. The null I'm talking about is always, always, ALWAYS equal to itself, and that's absolutely fine and there's nothing wrong with relying on this behavior, even in pure mathematics. As long as you don't confuse this null with other, very different things that are also called null.
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
For you (I assume), the obvious conclusion is that null is weird and can't be treated as a real value.
I'd say that his point was, "Don't assume that you can treat it as a value." And I pointed out SQL as an example where that gets you into trouble.
-
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
I get it, and so does he. You only want to talk about it in terms of those languages but he was generalizing.
-
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
I get it, and so does he. You only want to talk about it in terms of those languages but he was generalizing.
To be honest I've never understood why SQL treats null the way it does. Especially if the majority of the time you wrap nullable columns with something like ISNULL(the_column, '<NULL>') to enable comparisons instead of an equality + null check which is really clunky.
-
@mikehurley said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
I get it, and so does he. You only want to talk about it in terms of those languages but he was generalizing.
To be honest I've never understood why SQL treats null the way it does. Especially if the majority of the time you wrap nullable columns with something like ISNULL(the_column, '<NULL>') to enable comparisons instead of an equality + null check which is really clunky.
Probably to prevent insane joins when the columns being joined on in each table can be null.
-
@mikehurley Semantics, I think. Suppose you have two people in your table with the same first name, but both have NULL as their last name. Then you can’t do a dumb comparison and conclude they are the same person. This holds in particular for normalised databases schemas, where there shouldn’t be NULL values for N/A fields but only for unknown fields.
-
@mikehurley said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
I get it, and so does he. You only want to talk about it in terms of those languages but he was generalizing.
To be honest I've never understood why SQL treats null the way it does. Especially if the majority of the time you wrap nullable columns with something like ISNULL(the_column, '<NULL>') to enable comparisons instead of an equality + null check which is really clunky.
It's used to represent that a field has no value assigned (nothing) .. but yeah, null checks get kind of annoying. Setting default values on fields instead of allowing nulls helps alleviate that...if you realistically can.
-
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
I get it, and so does he. You only want to talk about it in terms of those languages but he was generalizing.
No, you don't get it. The second sentence shows that you don't get it. Taking one concept and applying knowledge about it to a different concept isn't generalization - it's mixing up the concepts. That the two concepts are named the same is irrelevant. You don't generalize a Logitech speaker and the speaker of the House into the general notion of a speaker. It just doesn't work that way. Same with nulls. You can't generalize the null in Java with the null in SQL because they're completely different concepts. And that they behave very differently in comparisons is the proof that they're different concepts.
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
I get it, and so does he. You only want to talk about it in terms of those languages but he was generalizing.
No, you don't get it. The second sentence shows that you don't get it. Taking one concept and applying knowledge about it to a different concept isn't generalization - it's mixing up the concepts. That the two concepts are named the same is irrelevant. You don't generalize a Logitech speaker and the speaker of the House into the general notion of a speaker. It just doesn't work that way. Same with nulls. You can't generalize the null in Java with the null in SQL because they're completely different concepts. And that they behave very differently in comparisons is the proof that they're different concepts.
They are not completely different. I guess we'll have to agree to think each other retards. But at least you've agreed with the previous point, so thanks for that.
-
@Grunnen said in Waaah, I don't get paid to use new shiny languages:
Suppose you have two people in your table with the same first name, but both have NULL as their last name. Then you can’t do a dumb comparison and conclude they are the same person.
There was a long argument ages ago about whether SQL Server or Oracle's semantics made more sense. SQL Server holds that empty string and null are completely different. Oracle thinks that they're the same (but not the same since
null
is not=
tonull
).IMHO it's useful to distinguish between "this field is known to be empty" (similar to zero) and "this field is not known" (null).
-
I think of SQL null as the "I don't know" type. Is "I don't know" equal to "I don't know"? The answer is I don't know [same for any comparison containing I don't know].
-
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
I get it, and so does he. You only want to talk about it in terms of those languages but he was generalizing.
No, you don't get it. The second sentence shows that you don't get it. Taking one concept and applying knowledge about it to a different concept isn't generalization - it's mixing up the concepts. That the two concepts are named the same is irrelevant. You don't generalize a Logitech speaker and the speaker of the House into the general notion of a speaker. It just doesn't work that way. Same with nulls. You can't generalize the null in Java with the null in SQL because they're completely different concepts. And that they behave very differently in comparisons is the proof that they're different concepts.
They are not completely different. I guess we'll have to agree to think each other retards. But at least you've agreed with the previous point, so thanks for that.
I don't know what previous point you think I agreed with, but I'm pretty sure I didn't. I'm completely fine with you thinking I'm retarded IF IT MEANS YOU NEVER SPEAK TO ME AGAIN AND NEVER REPLY TO ANY OF MY POSTS EVER AGAIN.
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
I get it, and so does he. You only want to talk about it in terms of those languages but he was generalizing.
No, you don't get it. The second sentence shows that you don't get it. Taking one concept and applying knowledge about it to a different concept isn't generalization - it's mixing up the concepts. That the two concepts are named the same is irrelevant. You don't generalize a Logitech speaker and the speaker of the House into the general notion of a speaker. It just doesn't work that way. Same with nulls. You can't generalize the null in Java with the null in SQL because they're completely different concepts. And that they behave very differently in comparisons is the proof that they're different concepts.
They are not completely different. I guess we'll have to agree to think each other retards. But at least you've agreed with the previous point, so thanks for that.
I don't know what previous point you think I agreed with, but I'm pretty sure I didn't. I'm completely fine with you thinking I'm retarded IF IT MEANS YOU NEVER SPEAK TO ME AGAIN AND NEVER REPLY TO ANY OF MY POSTS EVER AGAIN.
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
I get it, and so does he. You only want to talk about it in terms of those languages but he was generalizing.
No, you don't get it. The second sentence shows that you don't get it. Taking one concept and applying knowledge about it to a different concept isn't generalization - it's mixing up the concepts. That the two concepts are named the same is irrelevant. You don't generalize a Logitech speaker and the speaker of the House into the general notion of a speaker. It just doesn't work that way. Same with nulls. You can't generalize the null in Java with the null in SQL because they're completely different concepts. And that they behave very differently in comparisons is the proof that they're different concepts.
They are not completely different. I guess we'll have to agree to think each other retards. But at least you've agreed with the previous point, so thanks for that.
I don't know what previous point you think I agreed with, but I'm pretty sure I didn't. I'm completely fine with you thinking I'm retarded IF IT MEANS YOU NEVER SPEAK TO ME AGAIN AND NEVER REPLY TO ANY OF MY POSTS EVER AGAIN.
Too bad. It was this, "You can't generalize the null in Java with the null in SQL."
-
@error very appropriate. I tried completely ignoring his existence once. It didn't work well. Made interactions with the rest of the forum members very hard.
-
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
I get it, and so does he. You only want to talk about it in terms of those languages but he was generalizing.
No, you don't get it. The second sentence shows that you don't get it. Taking one concept and applying knowledge about it to a different concept isn't generalization - it's mixing up the concepts. That the two concepts are named the same is irrelevant. You don't generalize a Logitech speaker and the speaker of the House into the general notion of a speaker. It just doesn't work that way. Same with nulls. You can't generalize the null in Java with the null in SQL because they're completely different concepts. And that they behave very differently in comparisons is the proof that they're different concepts.
They are not completely different. I guess we'll have to agree to think each other retards. But at least you've agreed with the previous point, so thanks for that.
I don't know what previous point you think I agreed with, but I'm pretty sure I didn't. I'm completely fine with you thinking I'm retarded IF IT MEANS YOU NEVER SPEAK TO ME AGAIN AND NEVER REPLY TO ANY OF MY POSTS EVER AGAIN.
Too bad. It was this, "You can't generalize the null in Java with the null in SQL."
Homonyms again. I was using general you. As in, nobody can generalize it. It just doesn't make any sense. Not just to me, but to anyone or anything.
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
I get it, and so does he. You only want to talk about it in terms of those languages but he was generalizing.
No, you don't get it. The second sentence shows that you don't get it. Taking one concept and applying knowledge about it to a different concept isn't generalization - it's mixing up the concepts. That the two concepts are named the same is irrelevant. You don't generalize a Logitech speaker and the speaker of the House into the general notion of a speaker. It just doesn't work that way. Same with nulls. You can't generalize the null in Java with the null in SQL because they're completely different concepts. And that they behave very differently in comparisons is the proof that they're different concepts.
They are not completely different. I guess we'll have to agree to think each other retards. But at least you've agreed with the previous point, so thanks for that.
I don't know what previous point you think I agreed with, but I'm pretty sure I didn't. I'm completely fine with you thinking I'm retarded IF IT MEANS YOU NEVER SPEAK TO ME AGAIN AND NEVER REPLY TO ANY OF MY POSTS EVER AGAIN.
Too bad. It was this, "You can't generalize the null in Java with the null in SQL."
Homonyms again. I was using general you. As in, nobody can generalize it. It just doesn't make any sense. Not just to me, but to anyone or anything.
Yes, I got that. Why would you bring that up?
-
@boomzilla because it looked like you meant the exact opposite, that it does make sense to generalize this, it's just I can't understand it. But yeah, if you also think @Captain was wrong to try to generalize the concept of null over both the SQL variant and the Java variant, I guess we're in agreement.
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla because it looked like you meant the exact opposite, that it does make sense to generalize this, it's just I can't understand it.
If we can't even agree on what "agree" means...
But yeah, if you also think @Captain was wrong to try to generalize the concept of null over both the SQL variant and the Java variant, I guess we're in agreement.
You can generalize over it. Just not that
null == null
.
-
-
FWIW, I agree completely that SQL "null" and C# "null" and JS "null" are each totally different beasts with the same name.
I think the comes out whether you're talking about the term null or the concept of null.
-
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
But yeah, if you also think @Captain was wrong to try to generalize the concept of null over both the SQL variant and the Java variant, I guess we're in agreement.
You can generalize over it. Just not that
null == null
.And also any other part that relies on either
null == null
ornull != null
. In other words, the entirety of @Captain's post doesn't apply to the null in Java because his entire post assumes thatnull != null
.
-
@error said in Waaah, I don't get paid to use new shiny languages:
I think the comes out whether you're talking about the term null or the concept of null.
No, not even that. It's about there being multiple separate concepts all being called null. There's no such thing as "the" concept of null.
-
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@error said in Waaah, I don't get paid to use new shiny languages:
I think the comes out whether you're talking about the term null or the concept of null.
No, not even that. It's about there being multiple separate concepts all being called null. There's no such thing as "the" concept of null.
That's what I'm saying. There are multiple concepts mapped to a single term.
-
@error fair enough.
-
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@mikehurley said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
I get it, and so does he. You only want to talk about it in terms of those languages but he was generalizing.
To be honest I've never understood why SQL treats null the way it does. Especially if the majority of the time you wrap nullable columns with something like ISNULL(the_column, '<NULL>') to enable comparisons instead of an equality + null check which is really clunky.
Probably to prevent insane joins when the columns being joined on in each table can be null.
Huh, that makes more sense than I expected.
-
This thread went downhill when we stopped yelling at the OP article and started yelling at each other.
-
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@mikehurley said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
I get it, and so does he. You only want to talk about it in terms of those languages but he was generalizing.
To be honest I've never understood why SQL treats null the way it does. Especially if the majority of the time you wrap nullable columns with something like ISNULL(the_column, '<NULL>') to enable comparisons instead of an equality + null check which is really clunky.
Probably to prevent insane joins when the columns being joined on in each table can be null.
Would that really be a bad thing when considered in context, though?
A join is about mapping related data and joining it together. One side of the join is supposed to be a foreign key, and the other the corresponding primary key. Primary keys are supposed to be unique. If you have a
null
as a primary key, or if you're joining two non-unique columns against each other... that's insane already, with or without bizarrely broken nullability logic.
-
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla because it looked like you meant the exact opposite, that it does make sense to generalize this, it's just I can't understand it.
If we can't even agree on what "agree" means...
-
@Mason_Wheeler said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla because it looked like you meant the exact opposite, that it does make sense to generalize this, it's just I can't understand it.
If we can't even agree on what "agree" means...
-
@CodeJunkie
"If you realistically can" is the biggy. If you pick a potentially in-band value as your "default" then you make life difficult dealing with records which have that value deliberately; and if it's out-of-band then you've broken the type domain for the field and its validation rules, and you've created a synonym for null that the dbms doesn't recognise as such, clearing the way for the insane joins @boomzilla mentioned.
-
@Mason_Wheeler said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@mikehurley said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla and my point is, he was talking about different null. Yes, you cannot treat null like an ordinary value in SQL. But the same isn't true at all in Java or C++. Null is an ordinary value that you can do everything with that you'd do with an ordinary value.
I get it, and so does he. You only want to talk about it in terms of those languages but he was generalizing.
To be honest I've never understood why SQL treats null the way it does. Especially if the majority of the time you wrap nullable columns with something like ISNULL(the_column, '<NULL>') to enable comparisons instead of an equality + null check which is really clunky.
Probably to prevent insane joins when the columns being joined on in each table can be null.
Would that really be a bad thing when considered in context, though?
Yes.
-
@Mason_Wheeler said in Waaah, I don't get paid to use new shiny languages:
Would that really be a bad thing when considered in context, though?
In relational algebra of the kind that SQL uses,
null
is an explicit “I don't have that information”. In particular, you can't tell if two nulls talk about information that is the same or not; to err on the side of safety, you say that they don't compare equal, even though that's potentially incorrect.This is related to intuitionistic logic and open world information models. The rabbit hole is very deep!
-
@dkf said in Waaah, I don't get paid to use new shiny languages:
@Mason_Wheeler said in Waaah, I don't get paid to use new shiny languages:
Would that really be a bad thing when considered in context, though?
In relational algebra of the kind that SQL uses,
null
is an explicit “I don't have that information”. In particular, you can't tell if two nulls talk about information that is the same or not; to err on the side of safety, you say that they don't compare equal, even though that's potentially incorrect.This is related to intuitionistic logic and open world information models. The rabbit hole is very deep!
Actually, a boolean operator applied to
null
hasnull
as the result.null = null
evaluates asnull
, notfalse
, and so do bothnull <> null
andnot(null = null)
. The only exceptions arenull or true
andnull and false
. Only at the point where the expression is finally tested (EG the outer level of the where clause) null is coerced to false.So you don't err on the side of safety when comparing; instead when the final verdict is given on a record you only return the ones which definitely match, not the ones on which you're uncertain.
-
@topspin said in Waaah, I don't get paid to use new shiny languages:
This thread went downhill when we stopped yelling at the OP article and started yelling at each other.
Welcome to TDWTF.
-
@topspin said in Waaah, I don't get paid to use new shiny languages:
@Mason_Wheeler said in Waaah, I don't get paid to use new shiny languages:
@boomzilla said in Waaah, I don't get paid to use new shiny languages:
@Gąska said in Waaah, I don't get paid to use new shiny languages:
@boomzilla because it looked like you meant the exact opposite, that it does make sense to generalize this, it's just I can't understand it.
If we can't even agree on what "agree" means...
-
@error said in Waaah, I don't get paid to use new shiny languages:
@Grunnen said in Waaah, I don't get paid to use new shiny languages:
Suppose you have two people in your table with the same first name, but both have NULL as their last name. Then you can’t do a dumb comparison and conclude they are the same person.
There was a long argument ages ago about whether SQL Server or Oracle's semantics made more sense. SQL Server holds that empty string and null are completely different. Oracle thinks that they're the same (but not the same since
null
is not=
tonull
).IMHO it's useful to distinguish between "this field is known to be empty" (similar to zero) and "this field is not known" (null).
Am I the only one triggered by the notion that every relation database other than Oracle is "SQL Server" and that it apparently means "Microsoft SQL Server"?
Edit: Of course, the Oracle handling of empty strings is definitely insane