You might as well argue that covering your ears during a TV advertisement is piracy. That's a strange definition of the word if I ever saw one.

It's unrealistic to expect just anyone to start up a new fab. But if not one person among billions will start up a new fab it points to intrinsic difficulty or unpleasantness or lack of prestige in the task. A correctively high price has all kinds of advantages for the society.

I haven't seen any argument that difficult tasks shouldn't be priced high. Only name calling.

It sounds as if you did skip C++ and moved to Java instead. If so you serendipedously avoided the one language that's likely to cause problems. C++ doesn't work like the rest of the languages on your list, and it really is as full of land mines as people say - even though, with a good process, evidently it can be managed.

This may be a big factor in rejecting unfamiliar languages. Over time the brain trains itself to grok a specific syntax, and understanding becomes partly automatic: we look at a Java program and our brain injects meaning into our consciousness. If we then look at APL or Lisp, however, that training on Java doesn't apply and the automatic injection doesn't function. We're left having to read the symbols directly, and it's unsettling not having the auto-assist. It makes us feel we "can't" understand the language, when it would likely take a couple weeks of immersion to change that impression.

I find that sometimes typedecls aid understanding, but they get in the way if they're the least bit complicated. I'm better off reading the program. I never had problems understanding Lisp programs for some reason.

Yes, this is a good system. It'll work particularly well at filtering spam because people largely agree what it is. One thing that will happen with your system is people will separate into cliques. But that's not the end of the world. Has anyone implemented Anthony's idea of using followees' likes to rank posts?

Most (not all) APL code I've seen uses very short names, often one letter names, for function names. And APL programmers are famous for cataloging "idiom" which are short phrases for common subroutines. In other words, it's best practice to repeat 3- or 4- symbol phrases instead of defining a subroutine.

Of course, there's nothing about an array language that requires using symbols; but for some reason most do.

Then came the software. The amount of complexity and jargon and issues and roadblocks that come out of nowhere is extraordinary. You have to dive several layers deep in a menu system to do step 1, then get hung up on opening a "gateway", then dive down the same menu to do step 2 of a 2-step process. He had another problem that kept him busy but what impressed me is the amount of time and complexity to do the simplest things. He wasn't performing many steps, but just getting to the step required rebooting, waiting, pressing the brake pedal to see when it was time to move the right turn signal stalk, didn't work, go back, do something else for 10 minutes, try again, it seemed endless.

German automotive companies have historically been terrible at software. Just because Tesla hasn't simplified or integrated their various software components yet, doesn't mean others can't do it nicer. But any company that doesn't value software like the Americans do is going to have a real tough time with the EV software problem.

It seems like decades-old giant code bases are precisely the ones hardest to migrate to memory safety. That's where coercion and enforcement is needed most. You and I don't need to be told to start a new project in not-C++ do we? Nearly every trained programmer has been brainwashed (in a good way) with formal methods, type systems, bounds checking, and security concerns. Now those same people who champion this stuff say it isn't enough, and therefore we need to do more of the same but with coercion. That's a failure to understand the problem.

What's preventing Microsoft, or Apple, or the coagulate Linux kernel team, or any other kernel team, from adopting memsafe technology or practice by themselves for themselves?

The last thing we need are what are evidently incompetent organizations that can't take care of their own products making standards, or useless academics making standards to try to force other people to follow rules because they know better than everyone else.

If the team that designed and implemented KeyKos, or that designed Erlang, were pushing for standardized definitions or levels of memory safety, it would be less ridiculous.

At the same time, consciousness of security issues and memory safety has been growing quickly, and memory safety in programming languages has literally exploded in importance. It's treated in every new PL I've seen.

Putting pressure on big companies to fix their awful products is fine. No pressure needs to be applied to the rest of the industry, because it's already outpacing all of the producing entities that are calling for standards.

But if you can prove it wasn't, I'm interested

So the misinformation didn't affect your decision making. Instead, the misinformation you were exposed to was corrected by your exposure to more, better information.