CTO: We'll use epochs for any time related fields in our services.

After service integration...

Dev from producer team: Hey the time field is showing up as 1970 and not null in your table. That seems to be a bug.

Me: Code looks fine. We are converting epochs to timestamps here. Null is taken care by the library function itself.

The same dev: Actually we are sending zero instead of null values in that time field. But we'd want the end table to treat that as null.

Me: Why can't you send null then?

The dev: Actually avro doesn't support nulls. Hence the zero.

Me: WTF??????

Manager to me: Actually you need to convert them as null. Anyways, this is not a blocker and we can live with it for now.

END OF RANT

Why can't they fucking send it as null? And when I asked about the details, that particular event type doesn't require that field. Still the manager insists on sending that field for it.

https://stackoverflow.com/questions...

Related?

Why support sanity - madness makes just so much more fun.

I guess many people are afraid of nulls because they cause so much trouble in many languages.

@Lensflare cause trouble in so many languages...

Might be nitpicky.... But the language isn't the problem.

It's the dev.

Tri value logic isn't hard. It just requires a certain diligence.

@IntrusionCM practically it is the problem. Of course you can avoid any problem in any language.
But some languages just require the dev to be extremely cautious and verbose while others make it nearly impossible to make mistakes that cause certain problems.
Dealing with nulls is such a problem.

@Demolishun That dev could have googled his error which would then land him to this question. But no. It seems all of the services inside the org don't have a single nullable field. Instead they are sending 0 and empty string inplace of nulls.

@kaipulla Problem with null is that it often can be ambiguous, to often null is an error but sometimes it mean unknown.

And with any date/time handling, null is very often not supported and epoch min is the default/not set value.

The real problem is that they did not clearly define exactly what should have been used at each border from the start.

Personally I do avoid null when dealing with date and time if I can since so many libraries have a problem with it.

@Lensflare Clearly the solution to null problems is to have a sentinel value that is specific to the data type and represents a valid, though unlikely data point.

@lorentz and for epoch, epoch min is such an unlikely value that is more or less never use except as “not set”.

@lorentz no. Complete disagree. Null is perfectly fine to represent a missing value. We don’t want to go back to magic numbers, do we?
And using a modern language that handles null correctly, it’s practically a solved problem.

@Lensflare imho there are no modern languages i can think of who have not a solution for null values.

Wether they get applied or not is up to the dev imho.

... Unless we're talking about "we've JDK 8 / PHP 5.3 / ...". Where null values are the least of the problems.

Back to the topic.

The "idea" to avoid null and just define a magic value instead of null is brain damaged.

Not gonna sugar coat that one.

That's how we end up with a quadro logic plus possible typing issues as we now redefine the original data type and create our own.

That's more than just dangerous.

Just to give a few examples of why this is not funny, easiest example is in databases.

Boolean e.g. . Look at Postgres boolean type - it supports on, off, true, false, 0, 1, yes, no.

The funny thing is now that we have a mixture of data types: union of string, integer, boolean to be specific.
Integer could be seen as string, too.

Thus the SQL allows no determination wether you actually query an boolean column or not - unless you explicitly check the DDL.

That's nasty.

Same goes for the reinvention of an data type for null.

E.g. taking 0 - this could be a bug, especially in duck typing / weak typing languages, a bug regarding SQL (e.g. inserting invalid value), intended behaviour as replacement for null, or it could mean the real date.

You will never know - the data is written and the only sane approach is to leave it, as you will not be able to figure it out.

Avoiding null is basically redefining every data type, creating an endless myriad of bugs and obfuscating intended vs non intended behaviour.

Even worse - it's irreparable. You cannot revert it.

Just don't do it.

Forgot sth.

In databases, NULL can also be used for optimizations.

Redefining NULL could be a serious performance issue.

@Lensflare it was sarcasm

@Voxera it has all negative properties of null, and more.

@IntrusionCM agree. Just to clarify: I’m not advocating for avoiding null. On the contrary.
I just tried to come up with a reason why someone could think that avoiding null is a good idea.

@lorentz not quite, it cannot cause a null ref error for one :)

But other than that yes, a monad maybe pattern is better if the language supports it.

@Voxera No, it can cause totally meaningless values and accordingly completely arbitrary assertion failures and alerts instead. Much better.

@lorentz Sure but if you do not use something like maybe you will always have such a problem and my experience after 40+ years in the field is that null is worse.

@Voxera Do you think null would be more useful if it was silent and infectious like nan?

null.foo == null
null() == null

This way it would be possible to detect it, but it wouldn't crash programs.

For the sake of argument, consider just JS where everything is nullable

@lorentz No, I think you should use monad or similar to make the intent obvious and more or less remove null altogether.

I have used both null and something min and at best it requires you to know about it but null usually provides less helpful errors which is why I prefer to use min value or similar.

But both lack the intent of maybe where you have a very clear distinction between have value or not.

Objective C has a unique way of handling nulls:

It doesn’t crash or produce errors or exceptions. Any expression with a null just evaluates to null. Statements with nulls just do nothing.

I hate Objective C but I found this particular feature quite good actually. At least better than what Java and C# does with nulls. But the inability to make something not nullable makes it inferior to Swift, Kotlin and Rust.

Now I have flashbacks of the following values:

- 1970-01-01 (naturally)
- 0000-00-00 (clever, but pls don't)
- null (no surprise)
- "" (empty string)
- 0 (zero)
- false (bool)

---
Legacy PHP with MySQL at my old job in case you are wondering. And yes, I made a function to handle the above and either return DateTime or null. And no, a one-time DB migration was no option due to the plethora of APIs and external systems. But yes, it is still in production today! 🙃

@Voxera that is not a data problem but a OO/reference problem. I would be fine with the omission of NULL in any language as long as there is a way to represent "empty" fields/data.