[WalterBright]

> What is your source on this?

See "Trust the programmer" https://beza1e1.tuxen.de/articles/spirit_of_c.html

Also, a general belief among C++ programmers that better training is the answer to programming bugs. This belief is slowly fading, but it's got a long way to go. Scott Meyers' books on Effective C++ represent a lot of effort to educate programmers out of making mistakes. For example, from the table of contents: "Prefer consts, enums, and inlines to #defines". If C++ was an airplane, #define would simply be removed.

> I don’t even know what you might mean by punishment?

There are several calls for punishment in the comments on the article.

[buran77]

I think the work of the people operating a system is just as important as the one of the programmer. You can build the very solid plane or software and then have it fail due to being operated in the wrong fashion.

The question is whether both sides are doing their best, within reason, to mitigate issues. The programmer doing everything right while the admins forget to patch for years won't change a thing. The opposite is true, patching or configuring correctly won't do a thing if the system is full of "built-in" holes.

It's not a stretch to think of a setup where specific conditions that define this "within reason" are established for software developers and administrators. It's what an audit should normally uncover: weaknesses in the process, points for improvement, etc. Only this time it would be in the form of general and specific guidelines that get progressively stronger as time passes. It's not a sure thing but it raises the bar enough for most ransomware attacks to become cost prohibitive for the attacker.

[grawprog]

>If C++ was an airplane, #define would simply be removed.

So would that make D the airplane version of C++?

[WalterBright]

In my paper "The Origins of the D Programming Language" I enumerate many direct influences aircraft design has had on D.

https://dl.acm.org/doi/abs/10.1145/3386323#:~:text=The%20D%2....

BTW, I practice dual path in my personal life. If I'm doing something risky, I have a backup. For example, when I work under my car, I put the car on two sets of jackstands, even though I use stands that are rated for trucks. I'd never rely on a single rope/piton if rock climbing. I cringe when I see climbers doing that. I carry an extra coat in the car in winter, and water when driving in the desert.

[grawprog]

Thanks for sharing. I knew some of D's history, but there was stuff in there I hadn't read before.

I like much of the way D's designed. It doesn't try to be flashy, gimicky or different for the sake of being different. It gives you a set of practical tools and doesn't try to be too opinionated on the way they should be used. It mostly makes it hard to shoot yourself in the foot. But if you really want to you can. You gotta really try though.

[salawat]

That's defense in depth as applied to system design. Think of it like cleaning out a cat box, and only having bags with holes. You only need a couple bags whose holes don't line up, and you're good to go.

The simpler they are, the easier they are to learn. The easier they are to learn, and less "opinionated", the less resistance they tend to build up against adoption.

D is interesting, because it seems, from my experience, D, like Ada, has been a hypeless language. Though I haven't checked on licensing encumber meets that might be behind that.