Bertrand Meyer

I'm not particularly sure what the autor's claim has to do with Wirth, but there is a quote which he could have added to the article: "To hell with AI" (see https://inf.ethz.ch/people/faculty/emeriti/niklaus-wirth-quotes-faculty.html). Wirth distrusted AI mostly because of the "grandiose promises" its proponents made at the time (see https://bertrandmeyer.com/2024/01/16/niklaus-wirth-importance-simple/).

Besides that, I don't think that the "appeal to authority" the author makes in his article works. Wirth was a pragmatist, not a luddite. His "Lean Software" philosophy was about determinism and understandability, i.e. building systems where the engineer comprehends every instruction cycle. He criticized software that was written poorly (from his very own perspective).

The author implies that because we ignored Wirth’s warnings about OS bloat in the 90s, we were culturally primed to accept the "ultimate bloat" of LLMs in the 2020s; that's pretty wild logic. The author essentially criticizes that using LLMs for simple tasks is overkill. This is another concern than writing bloated software.

LLMs have demonstrated that they are able to generate both, lean and bloated software. When I use an LLM to review my code, it often finds logic reductions and possibilities for minimization which were not obvious. Ultimately, it once again comes down to the question of how tools are used. In the case of LLMs, they can obviously be used in line with or contrary to Wirt's recommendations.

> not the result of the concept itself being fundamentally different, it's a result of object lifetimes being different between GC'd and non-GC'd languages.

This is the fundamental misunderstanding. The RAII ctor/dtor pattern is a very general mechanism not limited to just managing object (in the OO sense) lifetimes. That is why you don't need finally/defer etc. in C++. You can get all of these policies using just this one mechanism.

The correct way to think about it is as scoped entry and exit function calls i.e. a scoped guard. For example, every C++ programmer writes a LogTrace class to log function (or other scope) entry and exit messages. This is purely exploiting the feature to make function calls with nothing whatever to do with objects (in the sense of managing state) at all. Raymond gives a good example when he points to how wil::scope_exit takes a user-defined lambda function to be run by a dummy object's dtor when it goes out of scope.

> I don't view RAII/scoped destructors as being equivalent or alternatives to things like `finally` blocks or `defer` statements. In C++ you basically use scope guards for everything because they are the only option, but I think C++ would still ultimately benefit from at least having `finally`.

Scope guards using ctor/dtor mechanism is enough to implement all the policies like finally/defer etc. That was the point of the article.

> You can kind of emulate it, but not 100%: `finally` blocks are outside of the scope of the…

The link is the text of an article [1] by Simone Santini that appeared in:
Computer, Volume 38 Issue 12, December 2005

It's a parody piece, although the author declared that "Many of the
sentences that I use in the article are from actual reviews." (quoted
by B. Meyer review in [2])

[1]: http://dl.acm.org/citation.cfm?id=1106763
[2]: http://bertrandmeyer.com/2009/08/14/rejection-letter-classic/