I disagree that it's just there to handle edge cases. It's a useful generalization.
I think the "Building an intuition" section of my blog post[1] makes a good case for that.
When dealing with loops, you have 3 nested constructs interacting: a wrapping function, a loop statement and the loop's body; and you have 3 keywords to choose where the flow of the code goes.
return returns from the wrapping function
break leaves the loop statement
next / continue leaves loop's body
When dealing with blocks or anonymous functions, it's instead 3 nested "functions" that are interacting: a wrapping function, a called function and an anonymous functions (or block).
Ruby's blocks, let you use the same 3 keywords to choose where the flow of the code goes.
return returns from the wrapping function (ex: my_func)
break returns from the called function (ex: each, map)
next returns from the block
Quite consistent. But since we are talking about functions instead of statements (loop), return values are also involved. Allowing both break and next to provide a return value fits well in that model and is quite useful. The 3 keywords are basically return, but they have different targets.
Yes you can, you use a finally clause around your call to yield, as you would already do to handle possible exceptions happening in the block. So no extra consideration is needed.
In Ruby, you always use the global name (with caps) that normally matches the library with possibly some nesting. (exceptions exists, but its also possible to add globals in Python)
Unless you are talking about include, but thats for mixins, which are snippets of reusable coee you can add to you class.
It doesn't feel at all as dirty as `from blah import *`.
I'm no expert here.
You mention "either side" as if the light came from both the left and the right. But I think the light would be coming along a circle all around the sun depending on exact position.
So the trick here is that if you are at the focus point, you get all that light in a small area "for free". But if you try to catch the light on the way, you now need to catch eveywhere in a whole massive circle, which is basically impossible, so you only catch a minuscule amount of the light. And then have to deal with interferometry.
The article argues that most source available licenses also provide more freedom than only reading the code, such as using it and modifying with some limits.
But "source available", english-wise, sounds like you can only read it.
This pushes some to avoid the term and say open source since that's much closer to their what the license does, even if they are not exactly open source.
The argument is that "fair source" would be a much clearer term for most of the "source available with extra freedoms" stuff, and I agree.
> You may have noticed that Google Search, Bing, etc. don't require login or captcha to do a search.
Are you saying you want adds in GitHub search's results? Google, Bing, etc. make money showing you adds. Adding barriers of entry is much less in their interest. Their budget to optimize the search engine is likely much bigger than GitHub's one.
Personally, I don't think this is a valid case of enshittifying. Products that you pay for that loses features or break or become more painful to use are enshittifying.
A free feature that stays free but requires you to make a free account (no credit card needed), I can see at least one very valid reason: if the feature heavier than a simple page (which is the case here), then it's an open door for DDOS attacks. Being able to track and ban/block the users that appear to participate in such an attack is totally valid.
The alternative is having to do captchas and the like to use those features anonymously, which is a pain both for user and for the devs/UI, and does feel more like the overall enshittification you are mentionning (even if it's a valid reason)
> Any code calling a function that can return a Null should know that being handed a Null is a possibility and handle it, right?
Well right now, the only way to know is to read comments/docs. The problem is that for many older languages, the signature cannot make it clear that null is a possibility (unless you count "anywhere can be null regardless of the function", which isn't helpful).
The goal is to have a real distinction between can be null and wont be null so that things can be made explicit and the compiler can actually highlight places where the handling is missing.
It's a tool to help do exactly what you describe in a less error-prone way.
I didn't use try Traefik's documentation, but the complains appear to be somewhat structural. Meaning a PR would need to possibly restructure at least part of the documentation, or add a whole section of documentation of a different type.
You can't expect someone not core to a project to just propose to restructure the whole documentation. Which may also mean changing the website.
And in any case, such overhaul coming from a "nobody" would very likely be rejected as being both too large or incomplete or not desirable.
Re-structuring needs to be pushed for by at least one person from the core team.
So yeah "Just submit a PR" in that context is not an answer, it's an excuse to avoid trying to understand the problem and actually improve the situation.
Exactly! If the rules are clear from the start that youcwill offer the switch, then it's useless, so dont bother.
If the rules are not clear that you will do it, then maybe you only offered it because you know I have the right one and want to avoid the loss. So it's worst than useless.
If the value increases, there is this same question, if you can know if I'm right or not, then you offering me a milion is just a trick isn't it? Also, you clearly wouldn't just give out one milion anyways, you dont havr the budget for that.
The only case is seems useufl to switch is when additional information was added in a guaranteed way (monty hall paradox)
When talking about placebo effect, it's the idea that the same thing could have happened taking a fake pill, just because the mind knows you are taking something that should have an effect.
Sure, the vitamin D in his blood may increase, but the anecdote of "it works" is about him getting sick less. And that could be a placebo effect and any sake pill would have had the same effect.
And the placebo effect can happen even when the person knows it's a fake pill.
Unless you are in a very hot path and know with absolute certainty that n will remain very low, I'd say you are doing clear premature optimization by comparing and choosing the O(n^2).
I say very small because to me, n=10_000 sounds like a number that could easily and quickly grow higher since yoy are past a basic enumeration of a few choices.
From what I remember last time I checked on this. % of money goes to a pot. Money is then globally distributed based on time listened globally (nothing is specific to you for the distribution).
So barely any of the money you put in goes to the artists you actually listen to.
Lagrange L1 is basically the only place you can place something between Earth and the Sun without heavy maintenance costs to maintain the position.
L1 is at 1% of the distance from earth to the sun. This means that if you are going to put something reflective there, there is basically no benefit size-wise compared to doing it directly on earth. (Diagrams usually make it look like it's 1/3 of the way, which would have a 77% increase to the covered area).
Feels like it would be easier to put something reflective like that somewhere on earth instead, allowing for a much bigger coverage per $.
Side note about that: people doing amateur porn where their face doesn't show at all still get recognized because of particular marks on their skins. So this might help this very specific case, but maybe not as much as one would think.
Logically (and ideally), the incoming air and outgoing air would exchange heat until they are at the same temp, which would be in the middle. So I would not expect an efficiency higher than 50% unless there is some special tech I'm not aware?
I think the "Building an intuition" section of my blog post[1] makes a good case for that.
[1] https://maxlap.dev/blog/2022/02/10/what-makes-ruby-blocks-gr...