The problems discussed in this important and timely paper have been with us for decades: the terms “software engineering” and “software crisis” were coined in 1968, when for the first time “programmers’ difficulties were openly discussed in a public forum--and with unusual frankness”  at the NATO Software Engineering Conference. The authors demonstrate that “we are now deep into a new and severe software crisis” characterized by failed projects, software crashes resulting in lost customer confidence, thousands of bugs in products endured by the marketplace with “few or no consequences for behavior and performance that in almost any other context would be viewed as unacceptable, unethical and actionable,” poor or inadequate documentation, easily compromised systems, and so on. Further, the authors stress the need for a disciplined approach starting with clearly defined specifications and observe that quick and dirty programming, perhaps adequate “to hack together a program that occupies a screen of code,” does not scale, as well as that both professionalism in software management and appropriate choice of tools are essential for success. They emphasize that university students must, from the beginning, be taught using the best languages and best practices.
The need for simple and elegant high-level languages has been known for decades, but “fashionable” languages that do not support abstraction (and safety) are still with us. A program first and foremost has to be readable and understandable by humans, and the authors properly put readability at the head of the list of proposed solutions. They stress the requirement for language-supported safety and discuss it at length, and then present the requirements for demonstrable correctness, security, reliability, and modifiability. As the language to be used, the authors propose their modernized dialect of Wirth’s Modula-2 (with quite a few examples showing its properties), and in my opinion, their promotion of this language is justified.
The authors properly criticize some popular but clearly inadequate approaches to software development including languages “inherently lending [themselves] to writing cryptic [and unsafe] code”; specifications created “on-the-fly under the assumption that the final project can be created in chunks” without knowing how, and whether, they will work together; code that is never reviewed “for code quality and specification compliance”; and so on. Their proposals to clearly state these problems and teach how to solve them, using their dialect of Modula-2, are more than welcome. At the same time, as many of us (ought to) know, such ideas have been around for decades. The paper’s reference list of 65 items regretfully does not include  or other software engineering classics such as Dijkstra. I would also disagree with some of the authors’ statements regarding traditional languages: first, Algol (both 60 and 68) was not “designed by a large committee,” and second, while PL/I indeed is of rather monstrous size and complexity, it was not too difficult to extract from it a small, disciplined subset used both in teaching and in industry. Note also that such an unfashionable and arguably unpleasant language as COBOL was recently praised (of all places) in the Financial Times for “being strictly structured, modular, and, not least, having clearly readable self-documenting syntax and format,” thus avoiding the “challenging problem of code fragility where change in one part of a program has unforeseen consequences on another” .
To deal with the current software crisis, as Wirth observed, “programmers must become engaged crusaders against homemade complexity” . This has to start early, in the classroom, and the authors propose to “teach classic professional engineering principles and tradecraft, and instill the self-discipline to apply them habitually.” Thus, I would certainly recommend the paper as an excellent step in the right direction.