The point is not the difference between a fake memory and a real one (let’s grant for now that they are undistinguishable) but the fact that positive experiences are worth a lot more than just the memories they leave you with.

I may not know the difference between a memory of an event that I experienced and a memory of an event I didn’t experience. Looking back on the past, they’re the same.
But each moment of pleasure that I only remember, without having experienced it, was essentially stolen from me. Pleasure is a state of consciousness and only exists in the present.

This works as a general guideline, but sometimes you aren’t able to write the code in a way that truly self-documents.
If you come back to a function after a month and need half an hour to understand it, you should probably add some comments explaining what was done and why it was done that way (in addition to considering if you should perhaps rewrite it entirely).
If your code is going to be used by third parties, you almost always need more documentation than the raw code.

Yes documentation can become obsolete. So constrain its use to cases where it actually adds clarity and commit to keeping it up to date with the evolving code.

Extra steps that guarantee you don’t accidentally treat an integer as if it were a string or an array and get a runtime exception.
With generics, the compiler can prove that the thing you’re passing to that function is actually something the function can use.

Really what you’re doing if you’re honest, is doing the compiler’s work: hmm inside this function I access this field on this parameter. Can I pass an argument of such and such type here? Lemme check if it has that field. Forgot to check? Or were mistaken? Runtime error! If you’re lucky, you caught it before production.

Not to mention that types communicate intent. It’s no fun trying to figure out how to use a library that has bad/missing documentation. But it’s a hell of a lot easier if you don’t need to guess what type of arguments its functions can handle.

The point is that you’re not fixing the problem, you’re just masking it (and one could even argue enabling it).

The same way adding another 4 lane highway doesn’t fix traffic long term (increasing highway throughput leads to more people leads to more cars leads to congestion all over again) simply adding more RAM is only a temporary solution.

Developers use the excuse of people having access to more RAM as justification to produce more and more bloated software. In 5 years you’ll likely struggle even with 32GiB, because everything uses more.
That’s not sustainable, and it’s not necessary.

I think they meant the only language we transpile to for the express reason that working with it directly is so unpleasant.

Java is not transpiled to another language intended for human use, it’s compiled to JVM bytecode.

People don’t usually develop software directly in the IR of LLVM. They do develop software using vanilla JavaScript.

I’d say generally speaking it’s more likely that issues stem from extensions than from Firefox itself, so maybe try looking into that.

Btw tab reordering is only missing for private tabs on the latest ff on Android.
Unfortunately there is still no acceleration when reordering so the ux is not great when you have many tabs.

Many of the programming languages that are regularly the butt of everyone’s jokes don’t just allow you to use them badly, they make it easy to do so, sometimes easier than using them well.
This is not a good thing. A good language should

• be well suited to the task at hand
• be easy to use correctly
• be hard to use incorrectly

The reality is that the average software developer barely knows best practices, much less how to apply them effectively.
This fact, combined with languages that make it easy to shoot yourself in the foot leads to lots of bad code in the wild.