I've always thought of Hyrum's Law more as a Murphy-style warning than as actionable advice.

Yea hyrum's law is like an observation of what happens when you personally try to make 200,000+ distinct commits to google3 to fix things that are broken (as hyrum did, mind you this is before LLMs), and people come climbing out of the woodwork to yell at you with fistfuls of xkcd/1172

Yep, that's a good one.

If my experience with beginning programmers generalizes to "the real world" (and I strongly suspect that it does, because the mindset non-programmers bring when they start programming has to come from somewhere) then I can also propose: "What needs to happen? What has been tried so far? What happened when that was tried, and how is that different?"

> listening to the use case, looking for the pain, and finding a way to solve the pain points. As opposed to trying to understand what feature the user wants to request.

... What is the distinction you're drawing here? How is "the feature the user wants to request" (note: not necessarily the feature the user actually requests) different from "the solution to the pain point"? Why would the user want a feature that doesn't alleviate the pain?

> We've entered... (we never entered

?

This is what gradual typing (such as TypeScript, or the use of Python annotations for type-checking) accomplishes. The issue is that it basically always is bolted on after the fact. I have faith that we aren't at the end of PL history, and won't be surprised if the next generation of languages integrate gradual typing more thoughtfully.

The problem with these two languages is that the runtime type system is completely different (and much weaker) than the compile time one; so that the only way to be safe is to statically type the whole program.

CL has a pretty anemic type system, but at least it does gradual without having to resort to this.

JavaScript caught on because it was the best casual language. They've been trying to weigh it down ever since with their endless workgroup functionality and build processes. If we get a next generation casual language, it'll have to come from some individual who wants it to happen.

No, JavaScript caught on because at the time it was the only game in town for writing web front-ends, and then people wanted it to run on the server side so that they could share code and training between front end and back end.

It's not enough to just be first. It would have been replaced by now if it wasn't fit for purpose. Otherwise we might as well not bother to critique anything.

To "realize" that it would have to be true. The longer I've stuck with untyped Python the more I've preferred it, and the more I've seen people tie themselves in knots trying to make the annotations do impossible (or at least difficult) things. (It also takes away bandwidth for metaprogramming with the annotations.)

Am I the only one who gets annoyed at "design" being used to mean specifically UI design without qualification or warning?

This, too, is covered in TFA.

This is covered in TFA.

> A meta question is why this persists. It has the right qualities for a "party trick"

This is discussed in a section near the end. But I feel like the discussion of why people care about using XOR to swap two values is missing an underlying discussion of why people would care about swapping values. As shown earlier in the division example, at the point where you would do the swap, typically you can just write the rest of the code with the roles of the values swapped.

Usually it's used like:

   if max < min:
       min, max = max, min

   [... algorithm that requires min < max]

So your suggestion would be to have two versions of the algorithm in the two branches of the 'if'. This is significantly more complicated and may even be slower depending on lots of factors.

> typically you can just write the rest of the code with the roles of the values swapped

Today, yes; most modern instruction sets are pretty orthogonal, and you can use a value in any register symmetrically -- although even today, division instructions (if they exist!) are among the most likely to violate that expectation, along with instructions that work with the stack pointer. But in the XOR heyday, this was less true -- instruction sets were less orthogonal, and registers were more scarced. It's not unreasonable for an OS scheduler tick to do some work to figure out the newly-scheduled task's stack pointer in one register, and need to swap it into an SPR or similar so that the return from interrupt returns to the new location, for example; and this is the exact type of place where the XOR trick occasionally has value.