Bertrand Meyer

Just in case it is not obvious: These rejection letters are fictional[1], created as collage of negative reviews Santini received. But it's hilarious to read, I agree. Since the original site where Santini commented on it is gone, probably it's only a question of time until this document becomes internet "truth". Brave new world. [1]http://bertrandmeyer.com/2009/08/14/rejection-letter-classic/

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/

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-facult… 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.

B. Meyer made an attempt to formulate many concepts in programming using simple, set theory. It might help in discussions like this. I say might since I'm not mathematically-inclined enough to know for sure. https://bertrandmeyer.com/2015/07/06/new-paper-theory-of-programs/

View types make me think of the modifies clause introduced by some verification tools and in an earlier specification of Eiffel [1]. Basically the clause allows you to list the fields that are affected by a function with mutations. [1] https://bertrandmeyer.com/2011/07/04/if-im-not-pure-at-least-my-functi…

https://bertrandmeyer.com/OOSC2/ - The book being quoted is now available for free, the quote you're referencing comes from page 108. (PDF page 138)

The only language I can think off that does the right thing is Eiffel (https://bertrandmeyer.com/2010/02/06/reflexivity-and-other-pillars-of-…

Consider having a look at Object-Oriented Software Construction by Bertrand Meyer https://bertrandmeyer.com/OOSC2/

Link to the book: https://bertrandmeyer.com/wp-content/upLoads/introduction_to_the_theor…

"Software is Terrible and Getting Worse" Reminds me of this satirical post: https://bertrandmeyer.com/2013/03/12/apocalypse-no-part-1/

There has been a conference by Bertrand Meyer on the topic but I don't know if there is a video of it : https://bertrandmeyer.com/2015/10/12/danke-sehr/

> 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…