Mozilla have lost their mind - Part 2
-
@C-Octothorpe said:
@Mason Wheeler said:
There's still no difference in meaning between a string which contains no information and no string at all.
FTFY
Not that I want to rehash an argument, but I disagree. You can look at this was (a bit of a stretch, but nonetheless): does 0[zero] == NULL?
It muddles the database and changes the meaning of your data, IMO.
Personally, I think this is a matter of you've been using Oracle for so damn long that you're just used to it's warts, and that's fine. We'll just have to agree to disagree.
Yes, it's pretty clear to differentiate between: "The answer is nothing" and "I don't know...maybe I haven't even asked the question." Sometimes that's very important. In most applications, I don't think it is, though. Either way, it's relying on an implementation detail for the distinction, and can be done in a portable manner (though the portability of RDBMSes is...less than ideal?).
Either way, it's a stupid thing to argue about. Which makes it perfect for this site!
-
@Mason Wheeler said:
@C-Octothorpe said:
@Mason Wheeler said:
There's still no difference in meaning between a string which contains no information and no string at all.
FTFY
Not that I want to rehash an argument, but I disagree. You can look at this was (a bit of a stretch, but nonetheless): does 0[zero] == NULL?
What exactly is 0[zero]? If I read that as parenthesis instead of square brackets, (as an explanation instead of some bizarre array subscript?) then yes, it's commonly accepted that a pointer with a value of 0 is the definition of a null pointer. What does that have to do with strings? (Or did you mean something different and I'm misreading it? That's entirely possible.)
Well, you managed to figure out that [zero] was just saying that 0 is a zero, and not an O... it's a start. But then you started talking about pointers. Who was talking about pointers?
-
@Sutherlands said:
@Mason Wheeler said:
@C-Octothorpe said:
Well, you managed to figure out that [zero] was just saying that 0 is a zero, and not an O... it's a start. But then you started talking about pointers. Who was talking about pointers?@Mason Wheeler said:
There's still no difference in meaning between a string which contains no information and no string at all.
FTFY
Not that I want to rehash an argument, but I disagree. You can look at this was (a bit of a stretch, but nonetheless): does 0[zero] == NULL?
What exactly is 0[zero]? If I read that as parenthesis instead of square brackets, (as an explanation instead of some bizarre array subscript?) then yes, it's commonly accepted that a pointer with a value of 0 is the definition of a null pointer. What does that have to do with strings? (Or did you mean something different and I'm misreading it? That's entirely possible.)
Umm... everyone? That's what null is: a pointer (as to a reference type such as a string) with a value of 0.
-
@Mason Wheeler said:
Umm... everyone? That's what null is: a pointer (as to a reference type such as a string) with a value of 0.
True, ok, I'll forgive you this one. But he's referring to the difference between the integer 0 and null (why does 0 != null but string.empty == null)?
-
@Mason Wheeler said:
If there's a real difference in the meaning (to the user, not the programmer) between a null string and a non-null empty string, then what is that difference?
You were arguing originally about the implementation that allows strings to be null, not what the user sees. What the user sees is presented by an application. How, or even if- that application maps nulls to other values will be that difference. Generally in the form of database nullable strings, it usually means either "this data has not been entered" or "this field is inapplicable"; in the former case, without null you couldn't otherwise check if the data had already been entered, since it might have been purposely set to the default value.
If a table- for whatever reason, needs to have a explicit field be nullable, how would you represent that without a Nullable string type? You would have to do the same stuff that everybody grew tired of in VB, where you constantly check values to see if they are null, and set the value you are working with to some default. But then if you save it, you are saving that default value rather than the null; if the database field was designed to have that default value, it would have that default value set, and wouldn't allow nulls to begin with. The fact is there is a good reason to have nullable fields of any type, including strings/varchars/ whatever. In the case of a language like VB6 (Delphi may have a nullable string of some sort, no clue) if you wanted the data to stay consistent, you would have to sprinkle isNull() checks when you read the data, set some flag to say "this field is null but I can't actually represent it as null but remember to not reassign it later" and then check that flag when you update the database. If String is nullable- you just read it to a string, and you write that string. You still have to check whether the string itself is null before dealing with the data, but you would need to perform those checks from the database anyway (assuming the language implementation doesn't automatically give you a default string value rather than null when the string field is null). I already explained the semantic reasons why a string ought to be nullable; (a array of char in Delphi can be set to nil, can it not? And is a array of char not exactly the same concept to a string? There is no difference to a user whether something is represented by a array of char or a string, so why should they have different semantics?
what you've done here is "moved the goalposts"- you make no mention of users and their experience with Null and String types until just now; previously it was about language implementations of specific features- and how programmers use them. I could just as easily pull the same argument out for your issues against mutable string types; what difference is there to a user whether the language uses mutable or immutable strings"? Same for damn near any language feature. Users simply have no reason to care if an application uses managed memory, a garbage collector, reference counted immutable synchronized strings, unicode strings, ASCII strings, or what have you, as long as it works.
On-topic somewhat: Anybody notice FF5's Redo button never seems to be enabled, and yet Control+Y still performs the Redo operation?
-
@Sutherlands said:
@Mason Wheeler said:
Umm... everyone? That's what null is: a pointer (as to a reference type such as a string) with a value of 0.
True, ok, I'll forgive you this one. But he's referring to the difference between the integer 0 and null (why does 0 != null but string.empty == null)?Because a reference type is a pointer, but an integer is not one.
-
@boomzilla said:
Yes, it's pretty clear to differentiate between: "The answer is nothing" and "I don't know...maybe I haven't even asked the question." Sometimes that's very important. In most applications, I don't think it is, though.
I'm trying really hard, honestly, but I simply can't think of any application where this distinction matters. Let me see if I can explain in a way that will make sense to the people on this thread.
First off, forget the word "string." Let's set it aside for a moment. "String" carries all sorts of technical baggage and implementation details with it, which can get really messy. Instead, let's talk about what strings are supposed to represent: text.
We're dealing with text. Text means nothing to a computer; it's just a str-- err, a sequence of bytes. It only has significance to an end-user who knows how to read. Ultimately, if you trace things back far enough, text gets entered into a computer by typing it into some sort of text prompt, such as a command prompt or a GUI text box. (Yes, I know there's also OCR, voice recognition, and a bunch of other edge cases. Ignore them for the moment. Same basic principle. Text originates from the user.)
If you have some interface, such as a form on an application or webpage, asking the user to enter some text into one or more prompts before giving it to the system to work with, (let's use the word "submit" for this process,) the possibility exists that the user will not enter anything into the text prompt(s). The business rules of the system will either accept this, in which case there is no text available to the system, or reject it and prompt the user to actually enter something here and re-submit the data. What the system ends up with is either some text or no text. There is no intermediate state.
The variable representing this text is submitted to the system and is processed. It will frequenly end up being saved to some storage mechanism. (Let's call that a "database," which does not necessarily imply any specific brand or type of database or even an RDBMS at all.) The text is saved to the database, and then at some later point it gets retrieved to display to the user. The user will either see text, if there is text, or see a blank field if there is no text. (And yes, various processing tasks could take place here, including concatenating multiple strings together before producing the final output. In this case, a blank value will simply insert nothing into the final value. The end result is the same.) There is either text or there is no text; there is no intermediate state.
Therefore, since there is no valid intermediate state when text is input from the user, and no valid intermediate state when text is output to the user, and text is meaningless to a computer except in the context of interaction with the user, there is no valid reason to have an intermediate state. There is no need to make a distinction between a null string and an empty string, because it does not model any meaningful distinction in the interaction with the user.
Does that make sense?
-
OK. Let's say we've collected some basic personal data from a few dozen users, say first and last name. Now the requirements change, and we want to collect middle name, so we add in a column for that; the business rules say we solicit this information from everybody. The records we've collected up to this point now have a middle name value of "null": we haven't asked for this datum yet, and don't know if it exists or if it's applicable. The next time the user logs in, we see this null value, and know that we still need to ask Bob Bobberson for his middle name. Bob, as it would happen, doesn't have a middle name, so he leaves this field blank, hits submit, and the null value in his profile record is replaced by the empty string, telling us that this value is now defined, and it is defined as nothing.
-
@joe.edwards said:
OK. Let's say we've collected some basic personal data from a few dozen users, say first and last name. Now the requirements change, and we want to collect middle name, so we add in a column for that; the business rules say we solicit this information from everybody. The records we've collected up to this point now have a middle name value of "null": we haven't asked for this datum yet, and don't know if it exists or if it's applicable. The next time the user logs in, we see this null value, and know that we still need to ask Bob Bobberson for his middle name. Bob, as it would happen, doesn't have a middle name, so he leaves this field blank, hits submit, and the null value in his profile record is replaced by the empty string, telling us that this value is now defined, and it is defined as nothing.
That's a decent question. But I'd actually design the system in a different way.
If the table/data structure representing user's profile is being updated once, it's reasonable to assume that it will be updated again at some point in the future. Not all of these updates will necessarily involve textual data, and (depending on the nature of your system) it's quite possible that more than one update will be coded between the time that Bob Bobberson logs out one day and the next time he logs in.
So how do you handle all this? Do you have some code that runs each time every user logs in that goes over a big long list of IFs (if MiddleName = NULL then AskForMiddleName; if birthdate = NULL then AskForBirthdate; if FavoriteColor = NULL then AskForFavoriteColor; etc...) or do you try to find a simpler way to handle the workflow?
What I would do is put a ProfileVersion column in the user's profile. When he logs in, it would do something like "if user.ProfileVersion < APPLICATION_PROFILE_VERSION then UpdateProfile(user);" The UpdateProfile method would take care of prompting the user for all necessary information, based on the difference between the user's profile version and the current version, (...holy crap, I think I just came up with a valid use for C's fall-through CASE semantics!), validating it, and then resetting the ProfileVersion column to the current value of APPLICATION_PROFILE_VERSION. This way, the big long list of checks doesn't have to be run multiple times, and you haven't introduced the need for a non-null empty string type. :)
-
@Mason Wheeler said:
@joe.edwards said:
OK. Let's say we've collected some basic personal data from a few dozen users, say first and last name. Now the requirements change, and we want to collect middle name, so we add in a column for that; the business rules say we solicit this information from everybody. The records we've collected up to this point now have a middle name value of "null": we haven't asked for this datum yet, and don't know if it exists or if it's applicable. The next time the user logs in, we see this null value, and know that we still need to ask Bob Bobberson for his middle name. Bob, as it would happen, doesn't have a middle name, so he leaves this field blank, hits submit, and the null value in his profile record is replaced by the empty string, telling us that this value is now defined, and it is defined as nothing.
That's a decent question. But I'd actually design the system in a different way.
If the table/data structure representing user's profile is being updated once, it's reasonable to assume that it will be updated again at some point in the future. Not all of these updates will necessarily involve textual data, and (depending on the nature of your system) it's quite possible that more than one update will be coded between the time that Bob Bobberson logs out one day and the next time he logs in.
So how do you handle all this? Do you have some code that runs each time every user logs in that goes over a big long list of IFs (if MiddleName = NULL then AskForMiddleName; if birthdate = NULL then AskForBirthdate; if FavoriteColor = NULL then AskForFavoriteColor; etc...) or do you try to find a simpler way to handle the workflow?
What I would do is put a ProfileVersion column in the user's profile. When he logs in, it would do something like "if user.ProfileVersion < APPLICATION_PROFILE_VERSION then UpdateProfile(user);" The UpdateProfile method would take care of prompting the user for all necessary information, based on the difference between the user's profile version and the current version, (...holy crap, I think I just came up with a valid use for C's fall-through CASE semantics!), validating it, and then resetting the ProfileVersion column to the current value of APPLICATION_PROFILE_VERSION. This way, the big long list of checks doesn't have to be run multiple times, and you haven't introduced the need for a non-null empty string type. :)
- Put all those "pesky" if-checks in a single method that gets called every time the user logs in. Contrary to what you probably believe, if statements really aren't that costly.
- Adding an additional column to avoid using a feature that should exist in any decent programming language, yet you refuse to use? "Logic" like that is the reason that this site exists.
-
@Mason Wheeler said:
That's a decent question. But I'd actually design the system in a different way.
No shit! That's not the point.
-
@Mason Wheeler said:
Not in the database.@Sutherlands said:
@Mason Wheeler said:
Umm... everyone? That's what null is: a pointer (as to a reference type such as a string) with a value of 0.
True, ok, I'll forgive you this one. But he's referring to the difference between the integer 0 and null (why does 0 != null but string.empty == null)?Because a reference type is a pointer, but an integer is not one.
-
@Mason Wheeler said:
Genealogy database with 3 fields for (say) forenames, middle names, surnames. Any/all are NULLable since you might not yet know whether the person has them.@boomzilla said:
Yes, it's pretty clear to differentiate between: "The answer is nothing" and "I don't know...maybe I haven't even asked the question." Sometimes that's very important. In most applications, I don't think it is, though.
I'm trying really hard, honestly, but I simply can't think of any application where this distinction matters.
Middle names in particular - some documents will only have fore/surnames so you leave the middle name NULL since you don't know, yet, if there are any; once the birth certificate/christening data turns up, you're in a better position to determine whether or not it should be blank (no middle names) or fill it in.
Alternatively you may know the name of Γεώργιος Βασιλείου's father but not his mother; you still have something there to represent the person; you simply don't know the name.
-
@The_Assimilator said:
- Put all those "pesky" if-checks in a single method that gets called every time the user logs in. Contrary to what you probably believe, if statements really aren't that costly.
- Adding an additional column to avoid using a feature that should exist in any decent programming language, yet you refuse to use? "Logic" like that is the reason that this site exists.
- The if logic itself isn't really all that costly, but the thing being checked can be arbitrarily complex. And even if it isn't, keeping the amount of code that needs to run down has other benefits besides execution speed, especially when you need to debug it.
- I didn't say I'd do it this way to avoid using that "feature". I said I'd do it this way because it's a better design, and oh-by-the-way when you design your app right, the need for this "feature" as described in the example goes away.
-
@Mason Wheeler said:
oh-by-the-way when you design your app right, the need for this "feature" as described in the example goes away.
Sort of like mutable strings and metaclasses?
-
@PJH said:
@Mason Wheeler said:
Genealogy database with 3 fields for (say) forenames, middle names, surnames. Any/all are NULLable since you might not yet know whether the person has them.@boomzilla said:
Yes, it's pretty clear to differentiate between: "The answer is nothing" and "I don't know...maybe I haven't even asked the question." Sometimes that's very important. In most applications, I don't think it is, though.
I'm trying really hard, honestly, but I simply can't think of any application where this distinction matters.
Middle names in particular - some documents will only have fore/surnames so you leave the middle name NULL since you don't know, yet, if there are any; once the birth certificate/christening data turns up, you're in a better position to determine whether or not it should be blank (no middle names) or fill it in.
Alternatively you may know the name of Γεώργιος Βασιλείου's father but not his mother; you still have something there to represent the person; you simply don't know the name.This is probably the first example I've seen that has a shred of validity to it. I've got some personal experience with genealogical research, and what you're saying rings true.
I have to ask, though. How does your program represent a missing name in the UI? I'm pretty sure it doesn't display something like "John NULL Smith" to the user...
-
@Mason Wheeler said:
I have to ask, though. How does your program represent a missing name in the UI? I'm pretty sure it doesn't display something like "John NULL Smith" to the user...
WHO CARES? THAT'S UP TO THE PROGRAM, NOT THE LANGUAGE!
This is also the exact same thing that everyone has been saying... you need to know whether the data simply doesn't exist, or whether you don't know anything about it.
-
@Mason Wheeler said:
I've got some personal experience with genealogical research, and what you're saying rings true.
I've no idea - it was a theoretical application. Maybe have the entry box a different colour. Or if just displaying it have it in a different font, or colourI have to ask, though. How does your program represent a missing name in the UI?
John <font color="lightgrey"><unknown></font> Smith
How does your personal experience with genealogical research suggest it should be handled?
-
@Sutherlands said:
@Mason Wheeler said:
I have to ask, though. How does your program represent a missing name in the UI? I'm pretty sure it doesn't display something like "John NULL Smith" to the user...
WHO CARES? THAT'S UP TO THE PROGRAM, NOT THE LANGUAGE!
This is also the exact same thing that everyone has been saying... you need to know whether the data simply doesn't exist, or whether you don't know anything about it.
The vast majority of the time, though, you don't. It's kind of telling that it took this long to come up with a valid example, and that example is only valid in the context of one very specific type of program.
In a case like this, I'd probably represent it as something like a Nullable<string>. That's what Nullable<whatever> is for: to give you the option to add support for nullable types in the (rare) cases where they're needed, without burdening the basic type system and your program logic with all the extra overhead that's required to work with nullable types in the rest of your code, where it's not needed. I still don't think that in the common case, a string type needs to make a distinction between a null and an empty string.
-
@Mason Wheeler said:
The UpdateProfile method would take care of prompting the user for all necessary information, based on the difference between the user's profile version and the current version
And how would you determine the difference between a non-specified middle name and a middle name specified as empty?@Mason Wheeler said:
I have to ask, though. How does your program represent a missing name in the UI? I'm pretty sure it doesn't display something like "John NULL Smith" to the user...
...
-
@PJH said:
@Mason Wheeler said:
I've got some personal experience with genealogical research, and what you're saying rings true.
I've no idea - it was a theoretical application. Maybe have the entry box a different colour. Or if just displaying it have it in a different font, or colourI have to ask, though. How does your program represent a missing name in the UI?
John <font color="lightgrey"><unknown></font> Smith
How does your personal experience with genealogical research suggest it should be handled?Oh, all right. I thought you had a specific application in mind. The simplest solution to something like this would probably be a checkbox that enables/disables the edit fields. (Which suggests a similar representation of this data in a database. Except that most genealogy programs don't use relational databases, since standardized file formats such as GEDCOM have been around and in wide use since before SQL became popular and widespread.)
-
@Zecc said:
@Mason Wheeler said:
The UpdateProfile method would take care of prompting the user for all necessary information, based on the difference between the user's profile version and the current version
And how would you determine the difference between a non-specified middle name and a middle name specified as empty?
If, for some reason, which I'm certain is not the least bit contrived, you really had to know, it would be as simple as checking the version number. If the user has updated past the point where this question gets asked, and it's blank, then there's no middle name. If the user has not updated past this point, then the question has not been asked.
-
@Mason Wheeler said:
@Zecc said:
@Mason Wheeler said:
If, for some reason, which I'm certain is not the least bit contrived, you really had to know, it would be as simple as checking the version number. If the user has updated past the point where this question gets asked, and it's blank, then there's no middle name. If the user has not updated past this point, then the question has not been asked.The UpdateProfile method would take care of prompting the user for all necessary information, based on the difference between the user's profile version and the current version
And how would you determine the difference between a non-specified middle name and a middle name specified as empty?Ok this whole version number thing is bugging me. Let's say you have a table of customer information that looks like this:
FirstName
LastName
Email
PasswordHash
DateOfBirth
SSN
HomePhone
MobilePhone
HomeAddress
WorkAddress
ShippingPreferenceAnd let's say the only fields you *require* to be filled-in to have an account are FirstName, LastName, Email and PasswordHash. All the other fields you don't bother asking until you need to know, as is good, sensible GUI design. With me so far?
Now how do you do this using your "version string" method? Do you have version 0 that means "only First/Last/Email/Pass", then version 1 means "First/Last/Email/Pass/Birthdate", version 2 means "First/Last/Email/Pass/SSN", etc etc? So for this relatively simple customer table, you have (if I remember my statistics, and disclaimer: I probably do not) 7! or over 5000 different version numbers? Is that honestly what you're suggesting?
-
@Mason Wheeler said:
@Sutherlands said:
Funny you should mention that, because once again, it's not true.This is also the exact same thing that everyone has been saying... you need to know whether the data simply doesn't exist, or whether you don't know anything about it.
The vast majority of the time, though, you don't. It's kind of telling that it took this long to come up with a valid example
Mozilla have lost their mind - Part 2
@Mason Wheeler said:So what do you mean by short-circuiting vs. non short-circuiting, then? Because as I pointed out, (non) short-circuiting is meaningless when applied to non-boolean operations, and I've never seen an example of where you would want a n...
@Sutherlands said:
Also, First Name = "Jim", Middle Name = NULL, Last Name = "Bob"
Does he have a middle name, or was it just not entered yet? With your craptastic way, we don't know.
-
You know, I'm going to give you the benefit of a doubt and sleep on this.
I'm still leaning towards having to distinguish between null and empty string, but who knows, maybe you have a point.
-
@blakeyrat said:
Now how do you do this using your "version string" method? Do you have version 0 that means "only First/Last/Email/Pass", then version 1 means "First/Last/Email/Pass/Birthdate", version 2 means "First/Last/Email/Pass/SSN", etc etc? So for this relatively simple customer table, you have (if I've done the math right) 7! or over 5000 different version numbers? Is that honestly what you're suggesting?
Of course not blakey, you just add the following fields:SSNSpecified
HomePhoneSpecified
MobilePhoneSpecified
HomeAddressSpecified
WorkAddressSpecified
ShippingPreferenceSpecified
-
@Sutherlands said:
@blakeyrat said:
Now how do you do this using your "version string" method? Do you have version 0 that means "only First/Last/Email/Pass", then version 1 means "First/Last/Email/Pass/Birthdate", version 2 means "First/Last/Email/Pass/SSN", etc etc? So for this relatively simple customer table, you have (if I've done the math right) 7! or over 5000 different version numbers? Is that honestly what you're suggesting?
Of course not blakey, you just add the following fields:SSNSpecified
HomePhoneSpecified
MobilePhoneSpecified
HomeAddressSpecified
WorkAddressSpecified
ShippingPreferenceSpecified
That's not what Wheeler's proposing, though. I could understand just having a bit field for every single piece of optional data, although it clutters the shit out of your database. (And 7 optional fields is tiny for a CRM database, normally you'd have closer to 30.)
But he's proposing keeping that info in a single version number, which is where the WTF lies. Either I'm misunderstanding his idea, or it's the dumbest idea I've ever heard.
-
@blakeyrat said:
But he's proposing keeping that info in a single version number, which is where the WTF lies. Either I'm misunderstanding his idea, or it's the dumbest idea I've ever heard.
The solution I proposed was supposed to be sarcastic. I think it's a horrible solution.
-
@Sutherlands said:
@Mason Wheeler said:
@Sutherlands said:
Funny you should mention that, because once again, it's not true. @Sutherlands said:This is also the exact same thing that everyone has been saying... you need to know whether the data simply doesn't exist, or whether you don't know anything about it.
The vast majority of the time, though, you don't. It's kind of telling that it took this long to come up with a valid example
Also, First Name = "Jim", Middle Name = NULL, Last Name = "Bob"
Does he have a middle name, or was it just not entered yet? With your craptastic way, we don't know.
But his point here, with which I agree, is that usually we don't care. The valid example was a case where you actually care. I can't recalling ever caring about this. It's always trotted out whenever relational database theory and Oracle are brought up, but that doesn't mean it's important.
Nobody cares about this except pedantic dickweeds and people who like to argue on the internet for the sake of arguing. Which makes it perfect fodder for filling up the CS database until email breaks again.
-
@Sutherlands said:
The solution I proposed was supposed to be sarcastic. I think it's a horrible solution.
Yeah, but if you were using Oracle as your DB, it would either be that ball of shit, or coming up with a "magic string" that meant "hasn't filled it in yet". I don't know which of those sucks more, but then again, that's why I don't use Oracle DB.
In any case, your idea is still 100 times better than what Wheeler's proposing unless, like I said before, I'm completely misunderstanding what he's proposing.
-
@blakeyrat said:
That's not what Wheeler's proposing, though. I could understand just having a bit field for every single piece of optional data, although it clutters the shit out of your database. (And 7 optional fields is tiny for a CRM database, normally you'd have closer to 30.)
But he's proposing keeping that info in a single version number, which is where the WTF lies. Either I'm misunderstanding his idea, or it's the dumbest idea I've ever heard.
You're misunderstanding my idea.
The idea is that the changes to the schema are made sequentially (one day you add a SSN field, then a week later you add the Mobile Phone field, etc...) and that the version number is also sequential to reflect this. Thus the highest possible version number would be 7, not 7!, for this example.
Also, before you start looking for any more contrived ridiculousness that doesn't actually exist in what I said, bear in mind that I never said anything about nulls as they relate to other data types, such as integers or dates.
-
@boomzilla said:
@Sutherlands said:
Exactly. Sutherlands, you may have come up with a theoretical concept, but you did nothing to explain why it's actually significant to any real-world process. You just threw around a bunch of "You're so stupid because you think this isn't important!" noise.@Mason Wheeler said:
@Sutherlands said:
Funny you should mention that, because once again, it's not true. @Sutherlands said:This is also the exact same thing that everyone has been saying... you need to know whether the data simply doesn't exist, or whether you don't know anything about it.
The vast majority of the time, though, you don't. It's kind of telling that it took this long to come up with a valid example
Also, First Name = "Jim", Middle Name = NULL, Last Name = "Bob"
Does he have a middle name, or was it just not entered yet? With your craptastic way, we don't know.
But his point here, with which I agree, is that usually we don't care. The valid example was a case where you actually care. I can't recalling ever caring about this. It's always trotted out whenever relational database theory and Oracle are brought up, but that doesn't mean it's important.
-
@Mason Wheeler said:
The idea is that the changes to the schema are made sequentially (one day you add a SSN field, then a week later you add the Mobile Phone field, etc...)
CRM doesn't work that way.
Since CRM is one of the primary uses of databases, and it doesn't work the way you seem to think it "should", your solution is obviously retarded and you're a bad developer who I hate.
@Mason Wheeler said:
Thus the highest possible version number would be 7, not 7!, for this example.
So if I want to set my shipping preference to "Express Shipping", I have to fill in my home phone number? What if I don't even have a home phone?
@Mason Wheeler said:
Also, before you start looking for any more contrived ridiculousness that doesn't actually exist in what I said, bear in mind that I never said anything about nulls as they relate to other data types, such as integers or dates.
That's not contrived; that's how thousands of HUGE real-life databases work RIGHT NOW. CRM is one of the primary uses for databases. Your "solution" doesn't solve shit.
-
@blakeyrat said:
That's not contrived; that's how thousands of HUGE real-life databases work RIGHT NOW. CRM is one of the primary uses for databases. Your "solution" doesn't solve shit.
I haven't done much in the way of CRM. But why would CRM care about this?
-
@boomzilla said:
But his point here, with which I agree, is that usually we don't care. The valid example was a case where you actually care. I can't recalling ever caring about this. It's always trotted out whenever relational database theory and Oracle are brought up, but that doesn't mean it's important.
No, his point was that we never care, which is a very important difference. If you look back over the thread, you will never see me saying that we care all the time, or even that it's an important distinction most of the time, simply that it's an important distinction some of the time, which means it's an important distinction for a language to have. The same with having a short-circuiting operator and a separate non-short-circuiting operator. He was saying that you should NEVER need the difference, because he hasn't encountered it, whereas I was saying that (while true in most cases) that doesn't invalidate the feature.Nobody cares about this except pedantic dickweeds and people who like to argue on the internet for the sake of arguing. Which makes it perfect fodder for filling up the CS database until email breaks again.
-
@Mason Wheeler said:
There is no need to make a distinction between a null string and an empty string, because it does not model any meaningful distinction in the interaction with the user.
There may be countless cases where the distinction between no/empty string does not matter. But no matter how many examples you bring in, this does not imply there are no cases where it does matter. One counter-example is sufficient.
We already have a few, but I'll add another anyway. Assume you're going to write a test at school. In this particular test, you'll get prepared sheets of paper so you only have to fill in your answers. Obviously, you could leave all fields empty, returning an empty answer/string. But you could also stay at home, returning no answer/string at all. The difference? In the latter case, you can hand in a medical certificate and get another chance.
The difference is significant in this case so your model must take it into account. You certainly could set a flag or store a special "meta" value like "<PERSON WAS ABSENT XXX SHOULD NOT SEE THIS>" (essentially defining your own special purpose "null" object) or model it in some other way. But no matter how you implement it, you have to store that a value is missing. Might as well use null for convenience if that's "natural" in a certain language.
-
@boomzilla said:
@blakeyrat said:
That's not contrived; that's how thousands of HUGE real-life databases work RIGHT NOW. CRM is one of the primary uses for databases. Your "solution" doesn't solve shit.
I haven't done much in the way of CRM. But why would CRM care about this?The goal is to get as much information about your customers as possible without pissing them off.
Asking a user for a piece of information that doesn't apply to them like, say, a home phone they don't own, will piss off your users. Asking your users every bit of information you want to keep on them all at once in a single hugenormous form will piss them off. Asking a user to provide some piece of information that they've already provided will piss off your users.
So the best solution is to only take information when:
1) They volunteer it
2) You require it for some other purpose (for example, shipping)
-
@blakeyrat said:
@Mason Wheeler said:
The idea is that the changes to the schema are made sequentially (one day you add a SSN field, then a week later you add the Mobile Phone field, etc...)
CRM doesn't work that way.
CRM is a massive field. Saying "CRM works like this" or "CRM does not work like that" is like saying "video games don't work that way" or "email clients don't work that way."
But all right, I'll bite. How does "CRM work" that makes this idea invalid?
@Mason Wheeler said:
Thus the highest possible version number would be 7, not 7!, for this example.
So if I want to set my shipping preference to "Express Shipping", I have to fill in my home phone number? What if I don't even have a home phone?
Then you leave it blank. Why do you keep asking questions I have already answered?
-
@Mason Wheeler said:
CRM is a massive field. Saying "CRM works like this" or "CRM does not work like that" is like saying "video games don't work that way" or "email clients don't work that way."
But all right, I'll bite. How does "CRM work" that makes this idea invalid?
Already covered.
@Mason Wheeler said:
Then you leave it blank. Why do you keep asking questions I have already answered?
How do you tell the difference between "this user has no phone number" and "we haven't yet asked for this user's phone number?" And please stop arguing in circles, you could easily have anticipated this question. So next time, do that, and show us all you have an IQ above 75.
-
@blakeyrat said:
@Mason Wheeler said:
CRM is a massive field. Saying "CRM works like this" or "CRM does not work like that" is like saying "video games don't work that way" or "email clients don't work that way."
But all right, I'll bite. How does "CRM work" that makes this idea invalid?
Already covered.
Oh. You're talking about that kind of CRM. I dunno, then; I suppose you'll have to just make everything nullable. Frankly, I've never really thought too much about that kind of software. I prefer to work with programs that people actually want to use; not something whose goals are actively hostile to the customer's interests. (Preemptive explanation before someone with no capacity for inference asks me what I'm talking about: building a HUGE database of as much personal information as possible on as many people as possible--especially if you can't do it openly because you know full well that doing so will piss them off--is hostile to their interests.)
@Mason Wheeler said:
Then you leave it blank. Why do you keep asking questions I have already answered?
How do you tell the difference between "this user has no phone number" and "we haven't yet asked for this user's phone number?" And please stop arguing in circles, you could easily have anticipated this question. So next time, do that, and show us all you have an IQ above 75.
First off, how did this all get focused on databases anyway? I thought we were talking about string implementations in programming languages. Second, as I said earlier, if you do run into a legitimate need for a nullable string, then that's what Nullable<whatever> is for. (Or should be, at least.) You seem to think that strings should always be nullable by default, with all the additional overhead that that implies. Why? Do you think that integers, dates, structs, etc should always be nullable by default? What makes strings special? Or are you just making excuses for Microsoft's bad implemenation of strings in .NET?
-
@Mason Wheeler said:
Oh. You're talking about that kind of CRM. I dunno, then; I suppose you'll have to just make everything nullable. Frankly, I've never really thought too much about that kind of software.
So stop talking out your fucking ass you fucking hack. Fuck.
@Mason Wheeler said:
I prefer to work with programs that people actually want to use; not something whose goals are actively hostile to the customer's interests. (Preemptive explanation before someone with no capacity for inference asks me what I'm talking about: building a HUGE database of as much personal information as possible on as many people as possible--especially if you can't do it openly because you know full well that doing so will piss them off--is hostile to their interests.)
So does it piss you off when Amazon stores your address so you don't have to retype it every time? Because that's the type of activity we're talking about. Honest question.
I didn't say storing the information pisses customers off; in most cases, customers *want* you to store that information. I said you need to get the information from the customer in a way that doesn't piss them off. Presenting customers with giant forms pisses them off.
@Mason Wheeler said:
First off, how did this all get focused on databases anyway?
Because arguing that a computer language doesn't need a nullable string is the same argument that a database doesn't need a nullable string.
@Mason Wheeler said:
Second, as I said earlier, if you do run into a legitimate need for a nullable string, then that's what Nullable<whatever> is for.
Then why the fuck did you spend so much fucking time, you piece of shit, arguing that nobody needs a datatype that your precious God-like programming language Delphi already has? What the fuck is wrong with you? Seriously.
Since Delphi has it, and Delphi is PERFECT AND GODLIKE IN EVERY WAY, then obviously it's necessary. By the logic of your own tiny little warped little Delphi-centric view of the world.
@Mason Wheeler said:
Do you think that integers, dates, structs, etc should always be nullable by default?
Yes I do. SQL Server has a fucking good reason for doing things that way, and honestly? I think it makes sense to do it that way by default. Even for booleans. (C# provides really easy syntactic sugar for this, BTW. "int" is non-nullable; "int?" is.)
@Mason Wheeler said:
What makes strings special?
Nothing.
@Mason Wheeler said:
Or are you just making excuses for Microsoft's bad implemenation of strings in .NET?
You haven't made a case for why it's better in Delphi. On the contrary, so far I've learned:
1) Delphi didn't have Unicode until 2009. Epic WTF there!
2) Delphi strings don't internally store any kind of internationalization hinting, so if you have an app that operates on more than one language at once, you'll have to wrap those strings in a more sensible container anyway.
3) Delphi strings are mutable, meaning they aren't thread-safe (well, not without extra work), they potentially waste memory by storing multiple copies of the same string, and they make string equality comparisons significantly slower.Am I wrong on those points? Since C# strings do not demonstrate the same problems, that makes them superior, yes?
(Of course the answer is: [foaming at the mouth])
-
@blakeyrat said:
@Mason Wheeler said:
First off, how did this all get focused on databases anyway?
Because arguing that a computer language doesn't need a nullable string is the same argument that a database doesn't need a nullable string.
No, my argument was that since nullable strings are not useful far more often than they are useful, that they shouldn't always be nullable by default, as they are in the .NET string class, because that adds needless complexity and overhead.
@Mason Wheeler said:
Second, as I said earlier, if you do run into a legitimate need for a nullable string, then that's what Nullable<whatever> is for.
<abuse snipped>Since Delphi has it, and Delphi is PERFECT AND GODLIKE IN EVERY WAY, then obviously it's necessary. By the logic of your own tiny little warped little Delphi-centric view of the world.
Actually, Delphi doesn't have it, at least not as a core language feature. But it's trivial to implement with Generics if you need it, and at least one widely-used open-source library has a prebuilt implementation that anyone can use. But that's really beside the point. The point is that making everything nullable by default when most of the time you do not need it is the tail wagging the dog, and it makes your code more complicated than it needs to be.
@Mason Wheeler said:
Do you think that integers, dates, structs, etc should always be nullable by default?
Yes I do. SQL Server has a fucking good reason for doing things that way, and honestly? I think it makes sense to do it that way by default. Even for booleans. (C# provides really easy syntactic sugar for this, BTW. "int" is non-nullable; "int?" is.)
You do realize that SQL Server is not a programming language, and that programming languages do not do the same things as databases do, and that this is also for a good reason? If it really makes sense to make everything nullable by default, they why isn't everything nullable by default? Why do you even need to tack the ? onto the types in the first place?
You haven't made a case for why it's better in Delphi. On the contrary, so far I've learned:
1) Delphi didn't have Unicode until 2009. Epic WTF there!
2) Delphi strings don't internally store any kind of internationalization hinting, so if you have an app that operates on more than one language at once, you'll have to wrap those strings in a more sensible container anyway.
3) Delphi strings are mutable, meaning they aren't thread-safe (well, not without extra work), they potentially waste memory by storing multiple copies of the same string, and they make string equality comparisons significantly slower.Am I wrong on those points? Since C# strings do not demonstrate the same problems, that makes them superior, yes?
1) Wrong. Unicode support has been around pretty much forever. It just wasn't the default string type before Delphi 2009. (Which was actually released in 2008. Someone at Embarcadero is apparently a big fan of car-model years.)
2) Wrong. The UnicodeString type is full UTF-16 Unicode and doesn't need language hints, but the data structure for the non-Unicode AnsiString type does have an associated codepage.
3) Wrong. Delphi strings are both mutable and completely threadsafe due to their implementation, with atomic reference counting and copy-on-write semantics guaranteed by the compiler. And yes, they may potentially waste memory by storing multiple copies of the same string, but that doesn't happen very much in practice. (And when was the last time you ran out of memory anyway?) And unless your ratio of string equality comparison checks to string creations is extremely high, there's no real performance boost to be had from string interning. In fact, now that I think about it, wouldn't having to hash all strings upon creation in order to check them against the string table actually degrade performance? Forget performance improvements; the only way you could even break even would be if your program does huge amounts of string comparisons. String interning as a core language feature really smells like premature optimization to me...
-
@zipfruder said:
I like firefox, but this rapid release schedual is bringing back the browser wars, this time being a race to see who finishes implementing HTML5 and friends,
HTML5 and friends? You mean the 'standards' with "DO NOT IMPLEMENT THIS YET, BECAUSE IT ISN'T FUCKING FINISHED" written all over them?
-
@Mason Wheeler said:
1) Wrong. Unicode support has been around pretty much forever. It just wasn't the default string type before Delphi 2009. (Which was actually released in 2008. Someone at Embarcadero is apparently a big fan of car-model years.)
The VCL and RTL didn't fully support Unicode until the 2009 release. That's called "fucking late to the party". So far it has had only three released versions that fully support unicode. Warranted- it's there, and you could probably write software to deal with unicode strings manually in earlier versions... (but that would require a major retrofit of your string usage).
No, my argument was that since nullable strings are not useful far more often than they are useful, that they shouldn't always be nullable by default, as they are in the .NET string class, because that adds needless complexity and overhead.
Strings aren't nullable in the .NET string class. the variables are nullable because String is a reference type. You aren't arguing that strings shouldn't be nullable, you are arguing that they shouldn't be a reference type, and that they should be a value type. The .NET String class cannot represent a "null" string.
If you really want a ValueType String, you can always cook up your own:
public struct MutableString
{
public char[] characters;
public static implicit operator String(MutableString s)
{
return new string(s.characters);
}
}Of course there aren't any actual methods... no all the manipulations should be in completely globally accessible functions... like in Delphi. Nothing like a throwback to old Turbo Pascal. And to think you were arguing about having to use static functions of a class to deal with instances of that class (String.IsNullOrEmpty()) and yet Delphi doesn't even organize your string manipulation functions. Sure, they might be a separate unit- but you can still use the functions without any sort of specifier.
What is annoying is somebody- anybody, saying exclusively that a language feature is stupid. (at least with mainstream languages). I mean, OK, you might be a tad bitter that Delphi has less market share then Slackware linux, but to suggest that "know better" than all the people making these choices- and none of them were taken lightly, I'm sure- is just plain ignorant. You suggest that A:) you understand software engineering principles not only better than everybody on this forum- which might pass, because it's a common attitude- but also the fucking designers of these languages that you're butthurt against. They are smarter than us. They know what they are doing. Whether you like the choices they made is of course your perogative, but to declare one method "shit" because you can come up with a few logistic disadvantages is a bit trite. As long as we're talking about bad designs, though, how about how Delphi treats strings exactly like a special array that get's it's own global functions like concat() and pos()? Surely an Object Oriented language ought to have it's constructs Oriented around objects rather than structures that are modified with functions?
-
@blakeyrat said:
@boomzilla said:
@blakeyrat said:
That's not contrived; that's how thousands of HUGE real-life databases work RIGHT NOW. CRM is one of the primary uses for databases. Your "solution" doesn't solve shit.
I haven't done much in the way of CRM. But why would CRM care about this?The goal is to get as much information about your customers as possible without pissing them off.
Asking a user for a piece of information that doesn't apply to them like, say, a home phone they don't own, will piss off your users. Asking your users every bit of information you want to keep on them all at once in a single hugenormous form will piss them off. Asking a user to provide some piece of information that they've already provided will piss off your users.
So the best solution is to only take information when:
1) They volunteer it
2) You require it for some other purpose (for example, shipping)This totally dodges the question. Let's talk about the actual implementation. How do you tell the difference between a text box that's empty because the question wasn't asked and one that's empty because the real information is that there is no information? What's the UI convention? These are real questions. I've never seen an app that appeared to do this. I mean, in some cases, you might have a button and a popup or something to enter some information, but stuff like home phone is probably right there in the main form or whatever.
So then, when the next customer service drone gets a call from this person, looks up the account, how can he tell that he shouldn't ask about this stuff, because it's already been determined that we've asked this question and the customer doesn't want to answer. The only solution I can think of would be a note from the last drone. At least, that's the only thing I've ever seen that might do the job.
In short, I think you claiming that this is a valued technique for CRM is complete bullshit. Now, where this sort of thing might be important or useful is in tracking a work flow or some process. Something that's not tied to text boxes filled in by users, but something much more structured that's really abstracted when a user views it. Not something like phone numbers or addresses.
-
@Sutherlands said:
@boomzilla said:
But his point here, with which I agree, is that usually we don't care. The valid example was a case where you actually care. I can't recalling ever caring about this. It's always trotted out whenever relational database theory and Oracle are brought up, but that doesn't mean it's important.
No, his point was that we never care, which is a very important difference. If you look back over the thread, you will never see me saying that we care all the time, or even that it's an important distinction most of the time, simply that it's an important distinction some of the time, which means it's an important distinction for a language to have. The same with having a short-circuiting operator and a separate non-short-circuiting operator. He was saying that you should NEVER need the difference, because he hasn't encountered it, whereas I was saying that (while true in most cases) that doesn't invalidate the feature.I don't really care what he's saying. I think you guys are full of shit about how important this feature is. I don't have a horse in the Delphi vs .Net race. But it's obvious that everyone is digging in on stupid ass positions just because they can't back down, and are so invested in calling the other person stupid.
Look, you .Net types had lots of reasonable sounding ways around a lot of the Delphi-centric stuff Mason was talking about. It seemed like he's really stuck in that world, which is OK, I guess, since he's able to live there. But arguing the importance of a nullable string type in a database (implementation WTFs of Oracle aside), you're getting into the same territory.
The genealogy thing was one interesting place where this might have some value. But even then, the UI sounds painful, and as someone said, it's mostly not stored in a DB anyways!
If we're dealing with a formal system (math-wise), this sort of question is important. But in the real world, the other errors you're likely to run into are probably going to swamp the benefits. Like did the user accidentally or on purpose do whatever you do to make it look like an empty, non-null field as opposed to the default null field? For stuff where this is really important, the obvious (RDBMS solution) is to normalize the table and put that information somewhere else. Now, if a record exists, you know it's been asked, and if the string is empty (or, god forbid, null), you still know the situation unambiguously. Unless, of course, someone mistakenly caused this row to come into being.
Like I alluded before, this sounds like an academic answer to a real world system, and YAGNI.
-
@BC_Programmer said:
@Mason Wheeler said:
1) Wrong. Unicode support has been around pretty much forever. It just wasn't the default string type before Delphi 2009. (Which was actually released in 2008. Someone at Embarcadero is apparently a big fan of car-model years.)
The VCL and RTL didn't fully support Unicode until the 2009 release. That's called "fucking late to the party". So far it has had only three released versions that fully support unicode. Warranted- it's there, and you could probably write software to deal with unicode strings manually in earlier versions... (but that would require a major retrofit of your string usage).
...so it's bad for me to talk about how long certain features have been around in .NET, but it's OK for you and Blakeyrat to talk about how long certain features have been around in Delphi? Just wanted to clarify this point, so I know where the goalposts are at the moment.
For the record, though, I agree with you, it took far too long for Unicode support to show up, but that's in the past now. The "dark ages" period when the product was run by decrepit Borland management who had quite different priorities for development and in fact actively put hurdles in place to make it more difficult for their sales staff to sell Delphi (not exaggerating) are over now. Each of the last three releases has represented a significant increase in the quality of the product, and there's every reason to believe that that trend will continue.
No, my argument was that since nullable strings are not useful far more often than they are useful, that they shouldn't always be nullable by default, as they are in the .NET string class, because that adds needless complexity and overhead.
Strings aren't nullable in the .NET string class. the variables are nullable because String is a reference type. You aren't arguing that strings shouldn't be nullable, you are arguing that they shouldn't be a reference type, and that they should be a value type. The .NET String class cannot represent a "null" string.
...only if all reference types must necessarily be objects. (Which is kind of silly.)
Of course there aren't any actual methods... no all the manipulations should be in completely globally accessible functions... like in Delphi. Nothing like a throwback to old Turbo Pascal. And to think you were arguing about having to use static functions of a class to deal with instances of that class (String.IsNullOrEmpty()) and yet Delphi doesn't even organize your string manipulation functions. Sure, they might be a separate unit- but you can still use the functions without any sort of specifier.
Umm... apparently there's some big problem here, but I'm not quite seeing what it is. Are you claiming that everything needs to be part of a class? If so, please lay off the Kool-Aid.
They are smarter than us. They know what they are doing.
Yes, and what they were doing was trying to design a language that would be a good competitor to Java, and they were quite successful at achieving that particular design goal. This is, however, not the same thing as creating a generally good programming language.
Whether you like the choices they made is of course your perogative, but to declare one method "shit" because you can come up with a few logistic disadvantages is a bit trite.
...which I never did. Profanity is the hallmark of a tragically limited vocabulary.
As long as we're talking about bad designs, though, how about how Delphi treats strings exactly like a special array that get's it's own global functions like concat() and pos()? Surely an Object Oriented language ought to have it's constructs Oriented around objects rather than structures that are modified with functions?
Again, only if you're too hopped up on "everything is an object" Kool-Aid to realize that not all concepts map well to the object paradigm. That's a mistake that the Delphi team avoided making, and the language is more powerful for it.
-
@boomzilla said:
This totally dodges the question.
Well I guess I misinterpreted "why would CRM care about this?" which is basically nonsense. I apologize that the answer doesn't match whatever the hell that question was supposed to be.
@boomzilla said:
How do you tell the difference between a text box that's empty because the question wasn't asked and one that's empty because the real information is that there is no information?
That would be the point of using NULL.
@boomzilla said:
What's the UI convention? These are real questions.
The user clicks through to their Profile page (or whatever it's called) and fills in fields. Alternatively, if it's something like a shipping address, the customer fills it in as part of the checkout funnel. Do you not use e-commerce in any way whatsoever?
@boomzilla said:
I've never seen an app that appeared to do this.
I've never seen a CRM application NOT do this. Log in to Amazon.com. Or JC Penney. Or Live.com. Or Facebook. Or Twitter. Keep track of how much information you need to create an account, then look at how much optional information you can fill-in on top of that.
@boomzilla said:
but stuff like home phone is probably right there in the main form or whatever.
It used to be, but people have learned (some companies better than others) that the fewer questions you ask initially, the more signups you get.
@boomzilla said:
So then, when the next customer service drone gets a call from this person, looks up the account, how can he tell that he shouldn't ask about this stuff, because it's already been determined that we've asked this question and the customer doesn't want to answer.
Any information your phone service needs to ask would have to be a required field.
@boomzilla said:
In short, I think you claiming that this is a valued technique for CRM is complete bullshit. Now, where this sort of thing might be important or useful is in tracking a work flow or some process. Something that's not tied to text boxes filled in by users, but something much more structured that's really abstracted when a user views it. Not something like phone numbers or addresses.
If you say so. Like I said above, though, I've never seen a CRM not work that way. (Except ancient, creaky ones from 1997 that like have 2 mile long sign-up forms. Some of those are still around.)
-
@Mason Wheeler said:
...so it's bad for me to talk about how long certain features have been around in .NET, but it's OK for you and Blakeyrat to talk about how long certain features have been around in Delphi? Just wanted to clarify this point, so I know where the goalposts are at the moment.
From me, it's more an expression of astonishment that the product still exists after that level of disconnect with the realities of actual software development. If there were any justice in this world, they'd have been in the soup line around 2005-ish.
@Mason Wheeler said:
For the record, though, I agree with you, it took far too long for Unicode support to show up, but that's in the past now. The "dark ages" period when the product was run by decrepit Borland management who had quite different priorities for development and in fact actively put hurdles in place to make it more difficult for their sales staff to sell Delphi (not exaggerating) are over now. Each of the last three releases has represented a significant increase in the quality of the product, and there's every reason to believe that that trend will continue.
Why did you stick with it?
@Mason Wheeler said:
Yes, and what they were doing was trying to design a language that would be a good competitor to Java, and they were quite successful at achieving that particular design goal. This is, however, not the same thing as creating a generally good programming language.
So what's the part you hate? C# or .net? Considering you can implement your GODLIKE SAVIOR OF ALL HUMANITY programming language in .net, I'd assume you'd be all behind it.
@Mason Wheeler said:
Again, only if you're too hopped up on "everything is an object" Kool-Aid to realize that not all concepts map well to the object paradigm. That's a mistake that the Delphi team avoided making, and the language is more powerful for it.
Yes. Obviously we're the ones on Kool-Ade, and not the person who can't stop sucking Delphi's cock for even one post.
-
Blakey, you're the best Karkat.
