This is much cheaper than actually going through the labor intensive process of psychoanalysis, so insurance companies like it.

I wonder when we'll see the Ritalin lawsuits.

Just put it in context: Today Russia struck the Pechenihy Reservoir dam in Kharkiv.
Russia launched the war because they thought it would be a quick and easy win, a step towards reestablishing a Russian empire and sphere of influence, because Putin thinks in 19th century terms. Russia is continuing the war, not because it's good for Russia. I'd argue that winning and then having to rebuild and pacify Ukraine would be a catastrophe. Russia is continuing the war because *losing* the war would be catastrophic for the *regime*. It's not that they want to win a smoldering ruin, it's that winning a smoldering ruin is more favorable to them and losing an intact country.

Your post demonstrates that you understand what the author meant, but then you continue to criticize him for failing to be inefficiently and unnecessarily pedantic with his words.

Think about that.

Have you ever actually tried using Numpy in C?

You can tell how serious someone is about performance based on whether or not they bring out a profiler. If they don't use a profiler, they aren't serious about performance (or maybe they're just clueless).

What do you want to program?

Modern C++ didn't get rid of the gotchas, it just added more of them. It's fine if you're working by yourself, but you can't prescribe what features other people will use (including the writers of libraries you want to use). But old C++ was fine when working by yourself too.

You can add types to your variables in Python. You can use typescript with Javascript.

You can also introspect your types in Ruby, so his point is moot.

There is also the question of why you would add type checking to a dynamic language: if you don't want a dynamic language, why did you choose one? But the reality is most of us don't choose languages anymore, we choose libraries and have to accept whatever language they are attached to.

The author is claiming that Python is readable.

A lot of lawyers prefer checks because a signed check is proof of intention. Not only is it signed, it often has a "reason" memo written.

This can also work in behalf of the person writing the check (in court). For example, if you pay your rent by check, the landlord shows the intent to accept it when they deposit the check. Whereas if you pay with direct deposit, the landlord can claim they had no intention to accept the money.

A lot of times you can have the bank write the check and mail it for you free. Usually it's in the "bill pay" section of the UI.

It comes with nice, official (intimidating) printing. That's what I do on the rare times I need to write a check.

One major difference, assuming you've got full platform support(should be the case on any server or workstation that isn't an utter joke; but can be a problem with some desktop boards that 'support' ECC in the sense that AMD didn't laser it off the way Intel does; but don't really care); is that ECC RAM can (and should) report even correctable errors; so you get considerably more warning than you do with non-ECC RAM.

If you pay no attention to error reports ECC or non-ECC are both rolling the dice; though ECC has better odds; but 'proper' ECC and Linux-EDAC support will allow you to keep an eye on worrisome events(normally with something like rasdaemon, not sure what other options and preferences there are in terms of aggregating the kernel-provided data) and, unless the RAM fails particularly dramatically and thoroughly, will give you much better odds of knowing that you have a hardware problem while that problem is still at correctable levels; so you can take appropriate action(either replacement, or on the really fancy server systems, some 'chipkill'-like arrangement where the specific piece of DRAM that is failing gets cut out of use when deeemed unreliable without having to bring the system down.

Sometimes you'd get a BSOD that was a fairly clear call to action; when the error called out something recognizable as the name of part of a driver; but that is mostly just a special case of the "did you change any hardware or update any drivers recently?" troubleshooting steps that people have been doing more or less blind since forever; admittedly slightly more helpful in cases where as far as you know the answer to those questions is 'no'; but windows update did slip you a driver update; or a change in OS behavior means that a driver that used to work is now troublesome.

Realistically, as long as the OS provides suitable support for being configured to collect actual crash dump material if you want it; it's hard to object too strongly to the idea that just rebooting fairly quickly is probably the better choice vs. trying to make the BSOD a genuinely useful debugging resource; especially given how rare it is for the person with useful debugging ability to happen to be at the console at the time of crash(rather than just an end user who is ill equipped to make sense of it; or a system that mostly does server stuff, quite likely not on actual physical hardware, where nobody has even touched the physical console in months or years; and it's more or less entirely useless to display a message there; rather than rebooting and hoping that things come up enough that management software can grab the dump files; or giving up and leaving the system in EMS so that someone can attach to that console.

Win9x and Win2k (and the other NT descendants) are fundamentally different operating systems. In general, NT had a much more robust kernel, so system panics were and remain mainly hardware issues, or, particularly in the old days, dodgy drivers (which is just another form of hardware issue). I've seen plenty of panics on *nix systems and Windows systems, and I'd say probably 90-95% were all hardware failures, mainly RAM, but on a few occasions something wrong with the CPU itself or with other critical hardware like storage device hardware. There were quite a few very iffy IDE cards back in the day.

The other category of failure, various kinds of memory overruns, have all but disappeared now as memory management, both on the silicon and in kernels, have radically improved. So I'd say these are pretty much extinct, except maybe in some very edge cases, where I'd argue someone is disabling protections or breaking rules to eke out some imagined extra benefit.