avidamoeba

Me too, I subbed for monthly.

The one thing I can see FUTO can do is provide capital up front for developers to work which could be recouped over time as more users begin to use and pay for the software. That makes sense and in a competent, not neoliberal economy, the government might have a fund doing something like that. What I'm a bit worried about is that this might not be all Eron's up to. But again, we'll take his money when he gives it, so long as the work is open source. And we'll see where we end up in a few years. 😅

Again, if you can write it with conditionals and returns, you can write it with equivalent number of conditionals and a single nested scope. No further scopes are needed. The conditional will even look nearly identically.

I never said longer functions are not less clear. I said my argument is valid irrespective of the length of the function which shows that the problems I claim multiple returns bring are independent of function length. 😊

Any validation you can write with a few early returns you can write with an equivalent conditional/s followed by a single nested block under it, followed by a single return. The reader is free to leave if the validation fails nearly the same, they have to glance that the scope ends at the end of the function. Looks at conditional - that's validation, looks at the nested block - everything here runs only after validation, looks after the block - a return. As I mentioned in another comment, validation is a trivial case to do either way. Returns inside business logic past validation is where the problematic bugs of this class show up which requires more thorough reading to avoid.

If you gave me a PR with early returns only during validation, I probably won't ask you to rewrite it. If I see them further down, it's not going in.

I'm sure you are capable of rewriting that in 3 lines and a single nested scope followed by a single return. In fact in languages that use exceptions you have to use at least one subscope.

Notice that in my example I didn't even broach the example with error conditions, cause it's trivial to write cleanly either way. Instead I talked about returns inside business logic. You can't unfuck that. 🐞

Early returns are very similar to gotos. One level of nesting to take care of validation is trivial in comparison. You're replacing logical clarity for minimal visual clarity. This is true regardless of the size of the function which shows that the size of the function isn't the determinant. You're not alone in your opinion, clearly, and I'm not going to convince you it's a bad practice but I'll just say what I think about it. 😅 This practice doesn't make it my team's codebase.

Is this going to be the mule produced by breeding OpenAI with the Bing team?

• Time Troll

Weird feeling about this. $5-$20 flat fee sounds like a lower price than what I'd imagine donations would bring. I imagine most who would donate would give at least $5-20, and then some would subscribe monthly. The dev team is obviously gonna get funding from Eron for now which would likely be higher today than what they get in donations.

Maintainability.

You can't read a block of code and as quickly and understand its control flow without reading every line, especially in regards to resource cleanup.

For example say you have:

...
if this:
    something
    or other
    and many more...
    ...
else:
    yet another thing 
    and some more
    ...

do some cleanup
return
...

Say you aren't exactly interested in what happens inside each branch. If you can assume that there's one return at the end of the block, you can see the if and else, you can reason about what values would trigger each branch, you can also see that no matter which branch is executed, the cleanup step will be executed before returning. Straightforward. I don't have to read all the lines of the branches to ensure the cleanup will be executed. If I can't assume a single return, I have to read all those lines too to ensure none of them jumps out of the function skipping the cleanup. Not having to think about such cases reduces the amount of reading needed and it makes reasoning about the block simpler. The bigger the blocks, the more the branches, the stronger the effect. You have one less foot-shotgun to think about. The easier you make it for your brain, the fewer mistakes it's gonna make. For all those days when you haven't slept enough.

E: Oh also refactoring blocks of code out into functions is trivial when you don't have multiple returns. Extracting a block with a return in it breaks the parent control flow and requires changes in the implementation.

E2: Shorter blocks do not obviate this argument. They just make things less bad. But they make almost everything less bad. Shorter blocks and single returns make things even better.

Fuck.

Jerboa. Because it works alright, it's open source and it's the Lemmy team's app.