![](/static/66c60d9f/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.
You work a job that uses PowerShell and you refuse to learn or use it. You are creating problems for yourself.
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 it wouldn’t. You’d have git beginners committing IDE configs and secrets left and right if -A was the default behavior.
No, you wouldn’t because no one is a git beginner, they’re a software developer beginner who need to use git. In that scenario, you are almost always using repos that are created by someone else or by some framework with precreated git ignores.
You know what else it could do? Say “hey, youve said add with no files selected, press enter to add all changed files”
Esc, :, q. Sure it’s a funny internet meme to say vim is impossible to quit out of, but any self-respecting software developer should know how, and if you don’t, you have google. If you think this is hard, no wonder you struggle with git.
Dumping people into an archaic cli program that doesn’t follow the universal conventions for exiting a cli program, all for the the goal of entering 150 characters of text that can be captured through the CLI with one prompt, is bad CLI design.
There is no reason to ever dump the user to an external editor unless they specifically request it, yet git does, knowing full well that that means VIM in many cases.
And no, a self respecting software developer wouldn’t tolerate standards breaking, user unfriendly software and would change their default away from VIM.
Git’s authors were the first users. The team that started the linux kernel project created it and used it because no other version control tool in existence at that time suited their needs. The subtle implication that you, as a user of git, know better than the authors, who were the original users, is laughable.
Lmao, the idea that we should hero worship every decision Linus Torvalds ever made is the only thing laughable here.
No, it should prompt you to enter your one sentence description in the CLI itself, and kick you out to an editor only if you provide a flag saying you like writing paragraph long commit descriptions.
Command line tools can be, git’s interface is not. There would not be million memes about exiting vim if it was.
Lol if an employer can’t have an intelligent discussion about user friendly interface design I’m happy to not work for them.
Every interview I’ve ever been in there’s been some moment where I say ‘yeah I don’t remember that specific command, but conceptually you need to do this and that, if you want I can look up the command’ and they always say something along the lines of ‘oh no, yeah, that makes conceptual sense don’t worry about it, this isn’t a memory test’.
Lmao, no.
Go work a job in a different industry before thinking you have it so tough.
Programmers make more money, have more vacation and free time, and consequently typically have stabler lives, than literally every single other professional industry.
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.