![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://programming.dev/pictrs/image/170721ad-9010-470f-a4a4-ead95f51f13b.png)
Why?
Because Java struggles with basic things?
It’s absurd to send that much data on every patch request, to express no more information, but just to appease the shittiness of Java.
Why?
Because Java struggles with basic things?
It’s absurd to send that much data on every patch request, to express no more information, but just to appease the shittiness of Java.
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.
Gotcha.
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.
No there isn’t.
Tell me how you partially change an object.
Object User :
{ Name: whatever, age: 0}
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.
Sure, in a specific scenario where you decide they’re equivalent they are, congratulations. They’re not generally.
Null means I’m telling you it’s null.
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.
I’ve never once seen a JSON serializer misjudge null and absent fields, I’ve just seen developers do that.
They’re not subtle distinctions.
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.
Because usually if you end up at the API reference in that situation it’s a code / project smell that other stuff is going wrong.
If I want to use a library to do something, you should be able to search for what you want to do + language / framework, find the library’s docs, follow the install instructions and then look through the highest level API / instructions and then just go from there.
If you find yourself confused at unhelpful API references that just means that they have badly written top level API docs, badly written intros, or quite probably just badly written APIs.
I mean, research funding is a huge problem, but half the problem is that journalists and reporters are largely people who went into English or Communications and stopped taking or learning any science past the high school level and thus don’t actually know how to read papers or report on them. Not to mention that critically reading a scientific paper and evaluating in the context of other research takes a significant amount of time, more time than is given to write a normal newspaper article.
And they’re reporting that science to people who on average know the same or less than them, so their mistakes and misreporting is never caught or corrected.
Eh, that’s not the joy you think it is.
That’s how software used to be distributed and that’s where the terms DLL / Dependency Hell come from and why programs used to not uninstall cleanly and break other programs, etc.
It’s more efficient, but it’s also brittler and a lot more complex to manage. Conversely, bundling everything together with all its dependencies is a lot easier to manage, and a lot more robust overall, but comes at the expense of storage capacity and network bandwidth.
Hey now, the three React Native for Windows apps would be very offended if they were stable enough to read text input.
You work a job that uses PowerShell and you refuse to learn or use it. You are creating problems for yourself.
It’s not tho.
deleted by creator
Because an object is good at representing a noun, not a verb, and when expressing logical flows and concepts, despite what Java will tell you, not everything is in fact, a noun.
I.e. in OOP languages that do not support functional programming as first class (like Java), you end up with a ton of overhead and unnecessary complications and objects named like generatorFactoryServiceCreatorFactory
because the language forces you to creat a noun (object) to take an action rather than just create a verb (function) and pass that around.
Go home OP, you’re drunk.
And give us your keys, you’ve had too much minimalism to drive.
Answer: there’d be far less software in the world, it would all be more archaic and less useful, and our phones and laptops would just sit at 2% utilization most of the time.
There’s an opportunity cost to everything, including fussing over whether that value can be stored as an int instead of a double to save 8 bits of space. High level languages let developers express their feature and business logic faster, with fewer bugs, and much lower ongoing maintenance costs.
No, I honestly just started here, and started playing around with the example, and then started turning that into what I wanted and googling when I needed to: https://ochafik.com/openscad2/
Saying things aren’t comparable is just shorthand for saying “I’ve stopped thinking or considering this”.
Literally everything is comparable, especially an antifascist and the person they’re covering as.