Hacker News Reader

Comment by techiferous | Hacker News Reader

It's the difference between "this value is unknown" and "this value is known and empty". It's similar to why JavaScript has both null and undefined.

Here's an example. Let's say a user is taking a survey and the last question is: "Please share any additional thoughts if you have them." A null could mean the user did not answer this question, probably because they haven't gotten to it yet. An empty string could mean the user was asked this question and actually didn't have anything to say.

View on HN

That's basically the only example I could think of: tracking if someone filled out a form field.

But in that case how can you tell the difference? I mean if they never clicked in the field or tabbed into it and submitted the form is that meaningfully different from they clicked into it and didn't type anything?

I can think of ways to work around it (keep a boolean for 'was filled out', a number that means 'they got up to field 17', etc.) but I'm still not sure you can draw a conclusion of 'they skipped it' vs 'they didn't enter anything'.

You're assuming all the questions are being presented to the user at once. Imagine a UI that presents questions to a user one-by-one. If the user bails out of the survey early, the rest of the survey answers can be null.

In that case you can easily keep track of what step they got up to in the wizard. It's a different way to store the data, but would work just as well.

I think the null vs empty argument works better when there are 40 boxes on screen at once. But again I'm not sure what semantic difference you'd find between 'they left it empty' and 'they never clicked into it'.

Keeping track of the step works until you move a field onto a different step in the wizard.

First, it's a document store so you can store the way the form is constructed with it (i.e. order of elements, etc).

Second, in Dynamo you could chose the absence of a key to represent "never got here" and a key with a null value to represent "they left this blank". You don't need an empty string.

So using null to mean the opposite of what it normally means? I would recommend against anyone using that workaround.

That depends on whether you see null as a marker of not having data or a marker of not knowing if there is data.

Both of those are data unknown, and both would normally be null. You don't distinguish between known unknowns and unknown unknowns at the database level.

When you say "The user submitted an empty form field as their answer", you do have data. It's weird to use null for that.

Since you can leave a key absent in DynamoDB, it basically has two ways to say "data unknown" and no way to say "knowingly left blank".

You can repurpose null as you suggested, and it will work fine in isolation, but it will massively violate the principle of least surprise and could lead to painful bugs.

To be fair, this would often be modeled by omitting the field completely. The lack of the field suggests the user hasn't gotten that far. The presence of the field with a NULL value means they didn't provide anything.

Reply on news.ycombinator.com