Good question, because from 30 years later, I think you're right. But my recollection of the zeitgeist then was all about progress. The trend of the computer i

Good question, because from 30 years later, I think you're right. But my recollection of the zeitgeist then was all about progress. The trend of the computer industry was always about upgrading, whether that's your hardware, or your OS (this was in the midst of moving from DOS to Windows 3), and there were tons of examples of important languages being left behind, like COBOL or FORTRAN. And prejudicing the decision against C++ were other related but separate technologies that had led to the failure of the project's original inception. The VP in charge of this major project (it was upgrading the company's core customer tooling from DOS to Windows) had us trying to do all kinds of crazy things. CORBA comes to mind, although I don't recall the details, and trying to make the entire architecture being data-driven. So there was a sense - not entirely unfounded - that C++ pulled in too much complexity, and we needed to shift gears to something much more straightforward. But I do recall realizing even as the decision was being made that the kind of simplifying abstractions that these 4GLs gave us may be great so long as what we want to do is "inside the box", but stepping out of the box leads to greater pain than if we'd been trying to accomplish it with conventional tools. Of course everyone realizes this, at least today. The difficulty was an management believing that the entire application, or nearly all, could be built inside that box, and that product owners wouldn't demand special and fancy behaviors. So I remember spending a good deal of time (and fun!) writing wrappers around Windows message handlers, with their LPARAMs and RPARAMs and the challenge that entails, so that other SQLWindows developers could do these things - whereas the C++/OWL path is designed to deal with such stuff natively.