If you’re branching logic due to the existence or non-existence of a field rather than the value of a field (or treating undefined different from null), I’m going to say you’re the one doing something wrong, not the Java dev.
These two things SHOULD be treated the same by anybody in most cases, with the possible exception of rejecting the later due to schema mismatch (i.e. when a “name” field should never be defined, regardless of the value).
It gets more fun if we're talking SQL data via C API: is that 0 a field with 0 value or an actual NULL? Oracle's Pro*C actually has an entirely different structure or indicator variables just to flag actual NULLs.
Zalando explicitly forbids it in their RESTful API Guidelines, and I would say their argument is a very good one.
Basically, if you want to provide more fine-grained semantics, use dedicated types for that purpose, rather than hoping every API consumer is going to faithfully adhere to the subtle distinctions you've created.
There's a huge difference between checking whether a field is present and checking whether it's value is null.
If you use lazy loading, doing the wrong thing can trigger a whole network request and ruin performance.
Similarly when making a partial change to an object it is often flat out infeasible to return the whole object if you were never provided it in the first place, which will generally happen if you have a performance focused API since you don't want to be wasting huge amounts of bandwidth on unneeded data.
The semantics of the API contract is distinct from its implementation details (lazy loading).
Treating null and undefined as distinct is never a requirement for general-purpose API design. That is, there is always an alternative design that doesn't rely on that misfeature.
As for patches, while it might be true that JSON Merge Patch assigns different semantics to null and undefined values, JSON Merge Patch is a worse version of JSON Patch, which doesn't have that problem, because like I originally described, the semantics are explicit in the data structure itself. This is a transformation that you can always apply.
Tell me how you change the name without knowing the age. You fundamentally cannot, meaning that you either have to shuttle useless information back and forth constantly so that you can always patch the whole object, or you have to create a useless and unscalable number of endpoints, one for every possible field change.
As others have roundly pointed out, it is asinine to generally assume that undefined and null are the same thing, and no, it flat out it is not possible to design around that, because at a fundamental level those are different statements.
Good practice in API design is to permissively accept either undefined or null to represent optionality with same semantics (except when using JSON Merge Patch, but JSON Patch linked above should be preferred anyway).
I.e. waste a ton of bandwidth sending a ridiculous amount of useless data in every request, all because your backend engineers don't know how to program for shit.
It's about making APIs more flexible, permissive, and harder to misuse by clients. It's a user-centric approach to API design. It's not done to make it easier on backend. If anything, it can take extra effort by backend developers.
But you'd clearly prefer vitriol to civil discourse and have no interest in actually learning anything, so I think my time would be better spent elsewhere.
Except, if you use any library for deserialization of JSONs there is a chance that it will not distinguish between null and absent, and that will be absolutely standard compliant. This is also an issue with protobuf that inserts default values for plain types and enums. Those standards are just not fit too well for patching
Bruh, there's a difference between the one or two serializing packages used in each language, and the thousands and thousands and thousands of developers who miscode contracts after that point.
Only if using JSON merge patch, and that's the only time it's acceptable. But JSON patch should be preferred over JSON merge patch anyway.
Servers should accept both null and undefined for normal request bodies, and clients should treat both as the same in responses. API designers should not give each bespoke semantics.
'The wind keeps blowing my wifi signal away ' is more than enough information to diagnose the problem, and 'the computer forgot my password' is now a real thing since password managers started coming baked into browsers.
We are so far beyond parody of ourselves that i have no idea how the onion stays in business.
How could you be simpler than keepass? Like, there's more advanced features, but for basic function, its just a password to access a list of passwords.
...its just a password to access a list of passwords.
Unless you never thought of, implemented, regularly did and regularly tested your backup of the database. Or... try to use it on more than one device - maybe even at the same time.
That's the main problem with KeePass. It's nice to have it offline, fully under your control and out of the cloud, but that comes with some responsibilities on your end. And now think of how the average user solves this. If you're tech savvy enough, KeePass is great!
You technically only need it on one device if you don't want to be able to copy/paste or use the autotype feature. Which works fine until you lose or break that one device or upgrade to a new one and forgot you needed to transfer your passwords or delete your database because you didn't remember what it was and wanted to free up space.
And Bitwarden has scary things like "self-hosting".
Setup syncthing between the computers. If the person is not tech savy enough, they can always force the tech savy enough person they know to set it up for them. The are no problems with the tech, people just dont know it exists. Even if you don't or can't use syncthing (iOS users), you can just be stupid and put it in the cloud.
"What do you tell someone to type when you want them to send you an email?" should work if the person has irl or phone social connections, which is still the case for a lot of older folks
Yes no clearly clearly. I never would have tried that. Thank you for your insight. I don't know how I would have missed that. No clue just pure flabbergasted over here
To whoever does that, I hope that there is a special place in hell where they force you to do type safe API bindings for a JSON API, and every time you use the wrong type for a value, they cave your skull in.
Sadly it doesn't fix the bad documentation problem. I often don't care that a field is special and either give a string or number. This is fine.
What is not fine, and which should sentence you to eternal punishment, is to not clearly document it.
Don't you love when you publish a crate, have tested it on thousands of returned objects, only for the first issue be "field is sometimes null/other type?". You really start questioning everything about the API, and sometimes you'd rather parse it as serde::Value and call it a day.
The worst thing is: you can't even put an int in a json file. Only doubles. For most people that is fine, since a double can function as a 32 bit int. But not when you are using 64 bit identifiers or timestamps.
That’s an artifact of JavaScript, not JSON. The JSON spec states that numbers are a sequence of digits with up to one decimal point. Implementations are not obligated to decode numbers as floating point. Go will happily decode into a 64-bit int, or into an arbitrary precision number.
As if I had a choice. Most of the time I'm only on the receiving end, not the sending end. I can't just magically use something else when that something else doesn't exist.
Heck, even when I'm on the sending end, I'd use JSON. Just not bullshit ones. It's not complicated to only have static types, or having discriminant fields
You HAVE to. I am a Rust dev too and I'm telling you, if you don't convert numbers to strings in json, browsers are going to overflow them and you will have incomprehensible bugs. Json can only be trusted when serde is used on both ends
This is understandable in that use case. But it's not everyday that you deal with values in the range of overflows. So I mostly assumed this is fine in that use case.
Well, apart from float numbers and booleans, all other types can only be represented by a string in JSON. Date with timezone? String. BigNumber/Decimal? String. Enum? String. Everything is a string in JSON, so why bother?
Well, the issue is that JSON is based on JS types, but other languages can interpret the values in different ways. For example, Rust can interpret a number as a 64 bit int, but JS will always interpret a number as a double. So you cannot rely on numbers to represent data correctly between systems you don't control or systems written in different languages.
And also, it's actually a complicated question. A one-man boycott doesn't do anything. If you work at a FAANG, work for a better world when you're off, and go whistleblower when they do something really evil, I find no fault in that at all.
The other consideration is that pretty much every company you could work for as a software developer is going to try to take advantage of your work. Most companies are morally bad at best and morally terrible at worst. If you discourage any good person from working there, the problem will only snowball from there.
If working at FAANG gives you the resources to support things you're passionate about, and you're willing to stand up for your values when they do something bad, there isn't a problem with that IMO.
My point wasn't that FAANG isn't exploitative (my bad if it came off that way, I didn't mean for that), it's that everywhere else is also exploitative to some degree (most probably less so than FAANG, there are definitely a few that are worse though), and that it could still be reasonable to work there for some people.
Bioinformatics isn't used only for medical research or within big companies.
Sub-topics like metagenomics, that are helpful in many areas of research, require high level of technical knowledge, that the life science people don't have.
Agreed. Just working for somebody bad doesn't necessarily mean you've given up, though. I mean, they made a movie about Schindler, and we all know who he worked for.
Why not? Unlike Schindler you don't have to worry about how many beatings are necessary to keep up appearances, and you might have a specific role that exposes you to very little evil at all. Meanwhile, you can donate some of that big wage to people like EFF, or volunteer using the flexible schedule.
You can do all those things while also not supporting FAANG
Depends. If you can find another employer that's more ethical (which is not guaranteed just because they're smaller) and pays as much with as flexible a work schedule, yeah, you should probably do that. Otherwise it might indeed be necessary.
I don't know, are we doing concequentialist ethics here, or deontological? I feel like we've reached the level of splitting hairs where we need to decide. For the purpose of actual advice people reading might follow, I'd say just try and be a good person, and don't let perfect be the enemy of better.
And go bankrupt when something happens on the way to work because they slipped and fell on the ankle.
Thanks, but I'll take lower pay over financial bankruptcy.
Yeah, that's true. It amazes me how some of my team in NYC will make double what I make, but live like I lived when I was a student, and be amazed that I own a car.
I was kind of assuming that, since FAANG are American, but I'd guess they probably have foreign employees as well.
Canadians make pretty much the same as Europeans, I think. The Americans have a bunch of monopolies, and are characteristically weird and nationalist about who they share the spoils with. (I know, it's not all of you guys, but it's definitely some)
Speaking at a software conference in 2009, Tony Hoare hyperbolically apologized for "inventing" the null reference:[26] [27]
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
Huh, so Tony Hoare invented null and then Graydon Hoare invented Rust, immediately terminating the existence of null which does not have a traditional null value.
Man Nvidia users are going to be stoked when the get explicit sync in they're desktop environments in two years. 😂 They're have been so many small improvements in the Nvidia drivers up until that point I hope they actually update Nvidia drivers on Debian. I understand some of those improvements are not going to work because of the kernel version and the desktop versions.
I'm using mxlinux "ahs" version, it comes with kde at their "ahs" repos for supporting latest hardware and graphics cards. You may also check for the non-ahs, there might be a meta-package for kde plasma and that's it..
I constantly call out juniors who do things like ignore warnings, completely unaware that the warning is going to cause serious tech debt in a few months.
But Ive also unfortunately shrugged after seeing hundreds of warnings because to update this requires me to go through 3 layers of departments and we're still waiting on these six other blockers.
Sure, Java can tell the difference. But that doesn’t mean that the guy writing the API cares whether or not he adds a key to the dictionary before yeeting it to the client.
That’s the thing though, isn’t it? The devs on either side are entering into a contract (the API) that addresses this issue, even if by omission. Whoever breaks the contract must rightfully be ejected into the stratosphere.
That's exactly not the thing, because nobody broke the contract, they simply interpret it differently in details.
Having a null reference is perfectly valid json, as long as it's not explicitly prohibited. Null just says "nothing in here" and that's exactly what an omission also communicates.
The difference is just whether you treat implicit and explicit non-existence differently. And neither interpretation is wrong per contract.
Omission means it's not there and I'm not telling you anything about it.
There is a world of difference between those two statements. It's the difference between telling someone you're single or just sitting there and saying nothing.
If there's a clear definition that there can be something, implicit and explicit omission are equivalent. And that's exactly the case we're talking about here.
At the (SQL) database level, if you are using null in any sane way, it means "this value exists but is unknown". Conflating that with "this value does not exist" is very dangerous. JavaScript, the closest thing there is to a reference implementation for json serialization, drops attributes set to undefined, but preserves null. You seem to be insisting that null only means "explicit omission", but that isn't the case. Null means a variety of subtly different things in different contexts. It's perfectly fine to explicitly define null and missing as equivalent in any given protocol, but assuming it is not.
Is SQL an API contract using JSON? I hardly think so.
Java does not distinguish between null and non-existence within an API contract. Neither does Python. JS is the weird one here for having two different identifiers.
Why are you so hellbent on proving something universal that doesn't apply for the case specified above? Seriously, you're the "well, ackshually" meme in person. You are unable or unwilling to distinguish between abstract and concrete. And that makes you pretty bad engineers.
If your SQL model has nulls, and you don't have some clear way to conserve them throughout the data chain, including to the json schema in your API contract, you have a bug. That way to preserve them doesn't have to be keeping nulls distinct from missing values in the json schema, but it's certainly the most straightforward way.
The world has more than three languages, and the way Java and Python do things is not universally correct. I'm not up to date on either of them, but I'm also guessing that they both have multiple libraries for (de) serialization and for API contract validation, so I am not really convinced your claims are universal even within those languages.
I am not the other person you were talking to, I've only made one comment on this, so not really "hellbent", friend.
Yes, I am pretty sure I read the comments, although you're making me wonder if I'm missing one. What specific comment, what "case specified above" are you referring to? As far as I can see, you are the one trying to say that if a distinction between null and a non-existent attribute is not specified, it should universally be assumed to be meaningless and fine to drop null values. I don't see any context that changes that. If you can point it out, specifically, I'll be glad to reassess.
Kinda, I guess we all can agree it’s more typical to deserialize into POJO where theres is no such thing as missing field. Otherwise why would you choose Java if you don’t use types. This great precondition for various stupid hacks to achieve „patching” resources, like blank strings or negative numbers for positive-only fields or even Optional as a field.
Speaking of rate limits: Github recently blocked me because I went over a ‘secondary rate limit’ by visiting the site for the first time in a month. Has anybody experienced this?
Programmer Humor
Newest
This magazine is not receiving updates (last activity 1 day(s) ago).