HN user

HellzStormer

54 karma
Posts1
Comments29
View on HN

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.
[1] https://maxlap.dev/blog/2022/02/10/what-makes-ruby-blocks-gr...

I don't think that's a fair comparison.

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.

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.

The analogy isn't the same, the lock could copy the actual key to make a replica in the future.

ssh is only flashing the "name" printed on each key and asking if it should try one of them. (not exactly but it's more equivalent)

Small mistake, and maybe that's why this function exists, but it's actually combines `.map(fn).flat(1)`.

I think conceptually, `flatMap` is a `map` where each iteration can return multiple values (or none). So it feels quite more powerful than just `map` and is a quite common convenience function.

My take on the difference (not a physicist):

Take that galaxy that just crossed our "observable universe horizon" so that we can't see it. If there is a civilization halfway between Earth and that galaxy, they can still see that galaxy. The galaxy can see that second civilization and so can we. There isn't a single fixed "observable universe" boundary in space, it's just relative to the observer.

With a black hole, it is different. There is no point that can see both sides while being seen from both sides,. If you are outside the black hole, you see nothing from within. If you are inside, then you can see the inside (this is speculation) and you also see the outside. It's a very clear boundary.

There is still a lot of work that has to be done before the ball is given to LLVM. If that gets optimized, it can improve the results.

Also, I would expect a more recent language to have a lot more low-hanging fruits than much older and highly used languages. The more you optimize, the harder it gets to optimize more.