Welcome to Programmer Humor!
This is a place where you can post jokes, memes, humor, etc. related to programming!
For sharing awful code theres also Programming Horror.
Meme transcription:
Panel 1: Bilbo Baggins ponders, “After all… why should I care about the difference between int and String?
Panel 2: Bilbo Baggins is revealed to be an API developer. He continues, “JSON is always String, anyways…”
json doesn't have ints, it has Numbers, which are ieee754 floats. if you want to precisely store the full range of a 64 bit int (anything larger than 2^53 -1) then string is indeed the correct type
This is String - you’ve seen it before haven’t you, Gollum?
Protocol Buffers are hated, but they are needed.
Do you actually use them?
I'm a student so, yes and no?
The comment section proves that xml is far superior to json
XML is all round better than Json.
I'll have you know all of my code is stringly typed.
All my binary code is stringy too.
It's the API's job to validate it either way. As it does that job, it may as well parse the string as an integer.
Pass in 04401…sorry 4401 is not a valid zip code. Rage.
Or even funnier: It gets parsed in octal, which does yield a valid zip code. Good luck finding that.
Who tf decided that a 0 prefix means base 8 in the first place? If a time machine was invented somehow I'm going to cap that man, after the guy that created JavaScript.
Should be like 0o777 to mimic hex 0xFF
Oof.
I guess this is one of the reasons that some linters now scream if you don't provide base when parsing numbers. But then again good luck finding it if it happens internally. Still, I feel like a ZIP should be treated as a string even if it looks like a number.
Yep. Much like we don't treat phone numbers like a number. The rule of thumb is that if you don't do any arithmetic with it, it is not a "number" but numeric.
Well shit, my zip code starts with a 9.
I’m not sure if you’re getting it, so I’ll explain just in case.
In computer science a few conventions have emerged on how numbers should be interpreted, depending on how they start:
0b, so 0b10011100, so 01160x, so 0x8EIf your zip code starts with 9, it won’t be interpreted as octal. You’re fine.
Well, you're right. I wasn't getting it, but I've also never seen any piece of software that would treat a single leading zero as octal. That's just a recipe for disaster, and it should use 0o116 to be unambiguous
(I am a software engineer, but was assuming you meant it was hardcoded to parse as octal, not some weird auto-detect)
I’ve also never seen any piece of software that would treat a single leading zero as octal
I thought JavaScript did that, but it turns out it doesn’t. I thought Java did that, but it turns out it doesn’t. Python did it until version 2.7: https://docs.python.org/2.7/library/functions.html#int. C still does it: https://en.cppreference.com/w/c/string/byte/strtol
Interesting that strtol in C does that. I've always explicitly passed in base 10 or 16, but I didn't know it would auto-detect if you passed 0. TIL.
I refuse to validate data that comes from the backend I specifically develop against.
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.
Sincerely, a frustrated Rust dev
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?
I got nothing against other types. Just numbers/misleading types.
Although, enum variants shall have a label field for identification if they aren't automatically inferable.
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.