I'll defer to your judgement re optical properties, but I want to offer a counter-anecdote about practicality.

I've had myopia and have been wearing negative diopter glasses for over half my life. I've never needed vision correction for reading. This is not an unusual combination, and if you want a celebrity example, watch some old Apple keynote videos with the late Steve Jobs, who would repeatedly lift his glasses to read something on the phone in his hand. This "works", but can be inconvenient in some situations.

A while ago, I started thinking about progressive bifocals. Cursory web searches told me that my particular combo was impractical. My optician didn't see a problem, so I decided to trust him and got a pair made. The TLDR is that they work for me much better than the old ones. There was a period of adaptation. Going downstairs and looking at the floor/ground were a bit disorienting for a while, but i don't notice it any more. Switching between the monitor and the phone or paper in front of me works, which is why I wanted the bifocals in the first place. I only use the old glasses for watching TV, probably meaning that my TV-watching posture sucks, but fortunately I don't watch a lot of TV. I still take off the glasses for sustained book reading.

Build quality deteriorated (from impressive heights) more than 25 years ago, when HP's calculator manufacturing moved to China. Not on account of China itself, but it was definitely a cost-cutting measure, and higher-end calculators were becoming an endangered species even then. For example, keycaps used to be double-shot injection molded, so the legends could never wear out; no more, now they're silkscreened like with everyone else. The new key mechanism could never reach the robustness and reliability of the old one, which is a problem if you're used to every keypress felt in your fingertips being correctly registered.

(Not everything was premium quality. On my late 15C, the faceplate logo wore out and the soft sleeve crumbled to dust after a couple of years. But the machine itself continued to work flawlessly until an unfortunate accident with a space heater.)

Additionally, the new Voyagers (1x series) are not running on the original, custom HP "Nut" CPUs, but on ARM microcontrollers, presumably via firmware emulation. It's impressive that the whole things works so transparently, but as I dimly recall, there were problems with that emulation in the first 15C Collector Edition runs, supposedly fixed now.

So, if you buy a new Voyager these days, you're getting a convincing replica of the originals from the '80s, nothing more. Caveat emptor.

Who, then, understands the code? If the answer is "no one really", entropy will overwhelm your codebase sooner or later. Otherwise, you need to read the code, and for that the knowledge of language is still relevant.

It's a bit more varied, even in the Indo-European family. What does tend to happen is that the words for handedness get positive (right) or negative (left) associations in idioms, but additional meanings are not universal. In French, "droit" additionally means right (as human right), but not "correct" (yes it does have a bunch of adjacent meanings). In German, "recht" gets to mean "law" or "justice", shared by some Slavic languages ("pravo") -- but not all of them, which have the word "desno", without any association with rights/justice/correctness. The Latin "dexter" gave us "dexterity" and "dexterous", but also nothing alluding to justice. Et cetera.

As an aside, "left" originating from "left over" sounds like folk ethymology to me. Dictionaries point to "weak" as the original meaning.

They just need to exclude the shops in a 150 m radius from Terminal D in the Tallinn harbor to get accurate statistics, the Finns rarely go beyond that ;)

Secure as defined by a duo of monopolists. It's a contractual concept and doesn't have a firm relation to security-related characteristics. I'd trust GrapheneOS to be as secure as anything Google is capable of releasing, but that doesn't help them if Google refuses to vouch for a device running their OS. Which is also why your check/credit card analogy falls flat.

What else do you expect, given the economic incentives on one side, and the immaturity of the discipline on the other? Writing robust software requires time, money and competence, in a purely empirical approach, since we have no fundamental theory of software. The pressure is for quantity and features in minimum time. The approaches are incompatible, and economics win every time.

Apparently I belong to the same club -- when I'm writing AWK scripts. (Arrays are hashmaps in a trenchcoat there.) Using hashmaps is not necessarily an indictment you apparently think it is, if the access pattern fits the problem and other constraints are not in play.

> It's amazing how much we've brainwashed folks to focus on algorithms and lose sight of how to actually properly optimize code. Being aware of how your code interacts with cache is incredibly important.

By the time you start worrying about cache locality you have left general algorithmic concerns far behind. Yes, it's important to recognize the problem, but for most programs, most of the time, that kind of problem simply doesn't appear.

It also doesn't pay to be dogmatic about rules, which is probably the core of your complaint, although unstated. You need to know them, and then you need to know when to break them.

They usually do. (The considerate and/or non-confrontational ones. There are always idiots, and people have the tendency to remember negative outliers and project their behavior on the group as a whole, which is unfortunate.) However, slowing down isn't the whole story. Riding a non-motorized bicycle is much easier if the rider can keep moving, however slowly, so it would be considerate in turn for the pedestrian to step aside and let the cyclist pass, if possible. A distracted pedestrian can be warned by a bell.

Separately, delivery riders as a category have an incentive to ride as quickly as possible, which is a recipe for conflict. Removing that incentive means removing or completely reimagining the service. I don't think that anybody has a solution or mitigation at present.

Depends. If one is aware of the meaning of section numbers, that "(5)" is very obviously suggesting that there is a file format named "crontab" which is documented. It's also pretty reasonable to suppose that the command and the file format of the same name are related.

A novice might miss the convention and the connection. Man pages are not quite novice material.

It would certainly help, but no economically feasible amount of auditing and best practices could lead to having a warranty on that software. My thesis is that our current understanding of software is fundamentally weaker than that of practical applications of electricity, so it makes no sense to present analogies between the two.

For an analogy to work, its underlying elements should have a relation to the target. Your analogy is not in the same universe. For electrical work, there is a baseline of materials and practices which is known to produce acceptable results if adhered to. For software, there isn't. (Don't tell me about the Space Shuttle. Consumer software doesn't cost tens of millions and isn't written with dedicated teams over the decades.)

It looks neat when you illustrate it with stacked boxes or concentric circles, but real-world problems quickly show the ugly seams. For example, how do you handle encryption? There are arguments (and solutions!) for every layer, each with its own tradeoffs. But it can't be neatly slotted into the layered structure once and for all. Then you have things like session persistence, network mobility, you name it.

Data formats have other sets of tradeoffs pulling them in different directions, but I don't think that layered design would come near to solving any of them.

Well, if you look up the histories of the time zones in the respective countries ("Time in Poland" and "Time in Spain" on Wikipedia, I have no reason to doubt their accuracy) you'll see that both settled on CET, with or without daylight savings, long before the EU was even an idea.