For better or worse, I do in fact get paid to do these experiments. One of my employers has this huuuge mess of MFC C++(98) code, with a lot of redundancy and r

For better or worse, I do in fact get paid to do these experiments. One of my employers has this huuuge mess of MFC C++(98) code, with a lot of redundancy and repetition in the code. It's unmaintainable and we are in fact in need for better architecture. And while much of the problem is due to historical accidents and lack of experience from some former team members, a lot of the problem I ascribe actually to MFC itself and more generally to the traditional GUI approach - Widgets in classes, code sharing using inheritance / method overriding and using other approaches as well. The main issue lies in the premature objectification (compartmentalization) of things, which prevents sharing data => it's hard to share handlers, which means there will always be a huge overhead from communication and bureaucracy and duplicated implementation efforts. So here you have it, one example where a "feature" (OOP syntax) leads to bad choices (making up "messages" unnecessarily, using methods to implement per-message handlers), leads to an excess of "fibers" and in general of badly aligned structure in the application, and that leads to long term pain. While with the write-from-scratch approach and mindset, there is a certain upfront cost, but an actual chance to acquire a deep understanding of the problem domain and to avoid the long term pain from ill-suited structure. In the end, to get the architecture right, the syntax doesn't matter almost at all. Once a problem is thoroughly understood and a suitable data architecture devised, computer programming is only a question of simple data copies and adds and multiplies. For example, in my code, there is basically no dynamic memory allocation, and there are no messages and no callbacks. C is a good language to program simply, it provides a lot of incentive to do so. The issue described above is more general, it doesn't only apply to OOP syntax. Many language features are just canned solutions to do memory allocation, ownership tracking, message passing, threads organization, polymorphic dispatch... The problem is always, eventually, that one size does not fit all. And in fact, most language features seem to be optimized not for the most common situations but for small tutorial examples. The particular code I linked above cost me 2-3 days of work (I had prior experience in the domain), which is miniscule compared to the time that is otherwise spent in a project on business logic / features.