Imagine you’re writing a CRUD API, which is pretty common.
If null attributes aren’t included in the payload, and someone does an update (typically a PATCH), how do you know which fields should be nulled out and which should be ignored?
I agree for many cases the two are semantically equivalent, but it’s common enough to not have them be equivalent that I’m surprised that it causes arguments
For many uses it is semantically the same.
But for cases where you need to know if something was intentionally set to null or was simply not set, the difference is enormous.
Ah yes the difference between “unset” and “intentionally set to null”, the bane of API devs who work in languages that don’t inherently distinguish between the two.
I love when an API takes a json payload, and one of the json fields is a string that contains json, so I have to serialize/deserialze in stages 😭
It seems like our socialized healthcare doesn’t cover our sarcasm detector organ 😅
I don’t necessarily agree that decentralized is fractured by design, nor that “working as intended” means that it’s the best solution for this/every situation.
I’m saying that as we decentralize, we get both advantages and disadvantages. I’m saying that this is a situation where we can’t both have our cake and eat it too.
For example:
We could decentralize communities themselves, preventing them from fracturing. Instead of having communities hosted on a single instance, communities could be feeds aggregating all posts tagged as belonging to that community. Then if you defederate an instance you simply stop seeing posts from users in that instance.
But then good-faith mods are defanged and can no longer protect vulnerable community members from antagonistic actors.
I think my straw example tradeoff is a bad one, that’s too much decentralization of power.
I actually already discussed that if you go back and read the comment that you’re replying to
But again that fractures the community.
You lose all the community history, and not everyone migrates to the new community. You end up with a bunch of new splinter communities, none of which have critical mass to survive.
I’m talking about systemic solutions for the general problem of bad-actor mods.
Defederating an instance is fracturing the community which difficult for a community to withstand with our current user numbers.
Giving mods less power, such as making communities themselves defederated, makes problems for good-faith mods who are trying to protect vulnerable community members.
It’d be neat if the community itself could vote to migrate to a new instance, but that’d be so fraught with abuse that I can’t see it actually working.
I don’t think there is a solution.
Effective moderation to protect vulnerable people needs more centralization. Avoiding the influence of bad-actor mods needs more decentralization. The two seem fairly mutually exclusive. Or rather, they trade off against each other.
With more users, having a fractured community wouldn’t be a huge problem, because they could all have critical mass. But with the current user base that is generally not feasible, even for really popular topics.
Owners:
Now that we have generative AI, we can finally get rid of all those expensive employees
There are common traps and employer don’t spend money/time to train their devs to avoid them.
SOLID principles are pretty decent but a surprising number of people don’t do any of them
I wonder how hard it’d be to make a PWA and host it on GitHub 🤔 Maybe this would be a good yet-another-hobby-project-ill-never-complete to pick up
I kind of agree. I’m not a pro but I’ve been using gimp to do little bits of editing (mostly to make slack emojis and memes) for a few years, and I constantly encounter little things that seem like they should be simple and intuitive, but are not.
I haven’t used Photoshop in over a decade, but I feel like I rarely felt the same frustration regarding basic tasks.
Gross
But considering the current state of Google search, not as gross as it was.
IMO there are two underrated benefits:
Designing for micro services doesn’t mean you need to deploy it as micro services. You can deploy it as a monolith and configure it too skip the network stack
Now that’s the pot calling the kettle black.
What work have you even invested? You’ve just repeatedly restarted your original stance. But sure, whatever.
Have you stopped to consider why you can’t explain it better? Perhaps the reason is because you’re wrong.
Your toy example does not show the issue you think it shows. You’ve moved your cleanup block away from the context of what it’s cleaning up, meaning that you’ve got variables leaking out of their scopes. Your cleanup code is now much more complex and fragile to changes in each of the blocks its cleaning up after.
You tried to use your toy example to show A is better, but then we showed that actually B is just as good. So fix your toy example to show what you actually want to say, because everything you said so far depends on you setting different standards for each scenario.
If you’re reading the control flow, and the control flow tells you the first block isn’t being entered, then it doesn’t matter if the first block contains an early return or not, because it wasn’t being entered. If it was being entered then you have to read it anyway to make sure it’s not manipulating state or leaking resources.
To use your example: in subsequent reads, when I’m interested in the second block out of n, say during defect analysis, I can head straight to the second block in either case since control flow shows the first block was skipped - but in the case of early return from the second block I can stop reading, but in the case of a single return I need to read the flow for all subsequent n blocks and the business logic of any subsequent blocks that get entered. The early return is a guarantee that all subsequent blocks may be ignored.
To me this is also obvious. I’ve been doing this for quite a while and 95% of the time, reviewing and debugging code with a single return is far more tedious.
I wasn’t taking about new fields. I was talking about resource partial updates (eg PATCH, or commonly the U in CRUD).
If you just want to update a single field on a resource with 100 fields, rather than GETting the entire resource, updating the single field, and PUTting whole thing back, just do a PATCH with the single field.
Likewise if you’re POSTing a resource that has nullable fields, but the default value isn’t null, how do you indicate that you want the default value for a given field? Do you have to first query some metadata API? That doesn’t seem ideal, when this existing pattern exists