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

Gross
But considering the current state of Google search, not as gross as it was.

IMO there are two underrated benefits:

1. It enforces separation of concerns
2. It provides options to OPS.

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.

Right. Like I said.

What are you hoping to accomplish by only reading control flow and not the contents of the blocks? You keep raising concerns like not properly releasing resources, but if you don’t read the blocks you don’t know what resources we’re allocated.

I think your argument depends on both having your cake and eating it.

You said yourself they’re equivalent. You either have to read the blocks in both cases or neither case.

You need to read the blocks to know what gets returned (either early or in a single return). You need to read the blocks to see what resources get created but not released. What are you hoping to achieve by only reading control flow?

At least with an early return you can stop reading.

If your function is so long that keeping track of returns becomes burdensome, the function is too long.

I’m not a fan of returning status codes, but that’s a pretty clear example of early return validation where you can’t just replace it with a single condition check. Having a return value that you set in various places and then return at the end is worse than early return.

Cost is the only one you can change quickly.

Deleted this

It was the other company CEO with dubious ties.

Wait… Who is “it” in “it’s CEO”??? Which CEO has ties?

I guess I’ll have to actually read the article.

But on the plus side, it’s nice to learn those skills and have examples of them running to put on your resumé.

-vvvvv --verbosester