That is all there is to it.

For example, the Windows MFC framework had classes whose data members were all public. Some of reasons were;

1) MFC was a wrapper over lower-level Windows API/structs and therefore unnecessary getter/setter methods were avoided. The C++ class could be a simple wrapper over the underlying C-style POD.

2) The framework classes were supposed to be used by implementation inheritance to build one's skeleton application which led to tight coupling between base and derived classes. Hence the designers decided to make all members public which meant that users were not limited by any omissions in the basic design.

I actually used these ideas in a project where i implemented a C++ api over C state machines for H.323 protocols.

Dietary Supplements for Older Adults - https://www.nia.nih.gov/health/vitamins-and-supplements/diet...

Vitamins and Minerals for Older Adults - https://www.nia.nih.gov/health/vitamins-and-supplements/vita...

Vitamins and Minerals - https://www.nhs.uk/conditions/vitamins-and-minerals/

Essential Daily Supplements by Age Group: A Doctor's Guide for Indian Families - https://drnegi.com/blog/essential-daily-supplements-age-guid...

Leveraging LD_AUDIT to Beat the Traditional Linux Library Preloading Technique - https://www.sentinelone.com/labs/leveraging-ld_audit-to-beat...

rtld-audit and LD_AUDIT - https://vsoch.github.io/2021/ldaudit/

Yeah, i was looking for little known/undocumented environment variables (eg. i didn't know of LD_AUDIT).

Due to various reasons (eg. age/bad diet/lack of exercise/etc.), i was suffering from brain fog, gut problems, low motivation/energy/fatigue, sleep problems etc. for the last couple of years. Finally, did some research, regularized my diet, disciplined my exercise and added the following supplements which solved all my problems.

  1) Methylcobalamin (Vitamin B12) sublingual tablet. Important for vegetarians. 
  2) Multivitamins and Multiminerals (with optional ginseng etc.)
  3) Omega 3, 6 and 9 (with optional gingko etc.)
  4) Vitamin B complex with Zinc
  5) Vitamin D with Calcium (500IU/500mg)
  6) Vitamin C chewable tablet

  7) Have a Pre and Probiotic capsule with lunch everyday to solve gut problems.

Win16 programming was an important formative phase in my career. There is a lot of wisdom in old solutions to thorny problems and knowing them often clues you to how one may adapt them to today's problem. For example, when CPU+GPU programming appeared i immediately imagined CPU memory accessed with "near" pointers and GPU memory accessed with "far" pointers with a switch to a pseudo-segment register.

It also conditioned a programmer to learn about various complexities involved and be careful in their programming i.e. it taught you discipline. You understood your compiler, OS and hardware better and how to write code keeping them all in mind. For example, i often say my study of embedded programming started with Win16!

Another bit of cleverness was "Thunking" between 16-bit and 32-bit code. Here is Raymond Chen on how it worked there and Why can’t you thunk between 32-bit and 64-bit Windows? - https://devblogs.microsoft.com/oldnewthing/20081020-00/?p=20...

“Barbarism is the natural state of mankind. Civilization is unnatural. It is a whim of circumstance. And barbarism must always ultimately triumph.”

Here by "Civilzation" i mean explicitly; philosophical ideas/frameworks, societal beliefs/structures/traditions etc. far beyond what is needed for mere survival. For example, Buddhism took the idea of Ahimsa from Hinduism (where its limitations were known) and turned it into the utopian idea of complete non-violence which was then made state policy in kingdoms of North India and current-day Pakistam/Afghanistan. The result was that they fell easily to the islamic barbarians who played by a different set of rules.

What we need is Civilization but with the necessary Barbaric tendencies assuring survival (i.e. procreation and societal self-defense) still maintained.

Note here that this idea has been corrupted by western countries during their colonial rule time period. So you have to be careful to disambiguate legitimate ideas from overt/covert racism.

> The ideal way to do runtime-checked DbC is not with simple asserts, it's with proper first-class preconditions and postconditions at the language level.

Not quite. DbC should be taught using only simple runtime asserts so that programmers can grasp the essence instead of confusing it with syntactic sugar which is irrelevant to the overall concepts/ideas. Once they grok this they can exercise DbC in any language eg. minimal C language. Furthermore they can now be led to the idea of doing it statically by mapping asserts to verification conditions and thence solved. This can lead to Frama-C and finally to a full-blown verification aware language like Dafny with all the bells-and-whistles.

> It wouldn't be nice to have to manually ensure that both old and new states of variables are in-scope for postcondition checking. I can imagine that being not just tedious, but error-prone.

Dijkstra has already given mechanical transformation rules for this in his wp-calculus. Tedious/error-prone is subjective since for something like a embedded health-monitor it is necessary.

> Some aspect of the program's state, yes, and hopefully that's all it does.

> Interesting to think about the edge-cases here though. Depending on the language, it could accidentally side-effect, or even invoke undefined behaviour, and so actively derail the program. Can't blame DbC for that though, that's a question of language safety.

This is solely the programmer's responsibility and his knowledge of his implementation language. We have already discussed this in our previous discussion.

> I'm not sure I follow here. You don't use asserts to steer flow-control, you use them to check aspects of program state.

An assert is a predicate and therefore an implicit conditional. When true, only a subset of the input state space is allowed in. When false, the program is halted. This is what i mean by "steering" i.e. the running program is a trajectory through a state space which we enforce by the usage of our asserts.

> That doesn't constitute a proof of correctness, no more than last time you and I discussed this. [0] Depending on the language, it wouldn't even necessarily prove the correctness of that particular trace, as you haven't proven that you haven't accidentally invoked undefined behaviour.

> You hold a minority opinion on this, please stop presenting it as settled fact.

We had already discussed this and i had already pointed out that is how "correct-by-construction" approach works whether done informally or formally by a programmer. It is your opinion which is narrow and in certain aspects wrong. Your examples of UB is simply a red herring since i have already pointed out that the programmer needs to be aware of this (and his language's optimizer).

Dijkstra for example invented his GCL and taught his class to use wp-calculus to derive preconditions from postconditions for every executable statement by hand to demonstrate proof of correctness.

> I'm not sure why you'd think I don't already know that.

That was aimed more at the OP article than you. However, when i see your comments w.r.t. UB, i wonder. One needs to know one's language's types and their bounds, sequence points and how it relates to expressions/statements to avoid UB.

A user raised some confusion with the wording about Contracts in your documentation which was not answered and is still there. I think it should be fixed since there are lots of people who are confused about contracts and how it differs from error handling. Add to this people's confusion about asserts at runtime and how the optimizer may mess it up and you have a veritable rat's nest of confused thoughts/opinions.

Is your approach to static analysis/verification something like what Frama-C does? I had always wished somebody would wrap C/C++ with a full blown static analysis/verification plus runtime framework and make everything into a single integrated whole like for example the Dafny language. Everything should be doable in a single implementation language with annotations as needed.

Understand first what Axiom Math does (https://www.youtube.com/watch?v=abYcV5LHMG4). It is only after he realized the possibilities of AI that he started Axiom Math with a student he mentored.