Earlier quoted context omitted.
you deprecated beck's work as 'mere software'. this presupposes that software is 'mere', which is to say, less significant than the other topics at hand. this logically entails deprecation of oberon, which is also software similarly, you said that when i repeated dijkstra's judgment that boehm's work, indeed boehm's entire field (and beck's!) was 'snake oil', i was betraying only my own ignorance. but that would logi…
You have failed your course in logic. > you deprecated beck's work as 'mere software'. this presupposes that software is 'mere', which is to say, less significant than the other topics at hand. this logically entails deprecation of oberon, which is also software Stating Beck's work as "mere software" (i.e. nothing noteworthy) DOES NOT mean all software (from others) is "mere software". A course in Set Theory/Proposit…
boehm speaks very highly of dijkstra's work in that interview (which is short), because dijkstra's work is universally acknowledged to be foundational, and deprecating it would only hurt boehm's own reputation; but nowhere will you ever find dijkstra speaking highly of boehm's work, or indeed in any but the most scathing terms. the very article you cite describes dijkstra renaming one of his papers to remove 'software engineering' from the title to prevent it from being associated with work like boehm's
the well-known text i quoted of dijkstra's is, contrary to your assertion, directed very directly at boehm's work, and not at how far the field had developed but at what it was attempting to accomplish (boehm was the leading proponent of that sort of 'software engineering' at the time, and, as the interview shows, continued to advocate it for the rest of his life.) as far as i can tell, this remained dijkstra's point of view until his death, which wasn't until 02002—plenty of time to re-evaluate boehm's work if contrary evidence had surfaced
to be generous, it's possible that you didn't know this because the article was even longer than the six-paragraph dijkstra quote you previously complained was too long for you to read (and are mischaracterizing here, presumably unintentionally)
i don't think you'll ever find wirth or hoare (who boehm also namedropped in the interview) saying anything complimentary about boehm either, though they weren't dutch enough to publicly lambast his work the way dijkstra did; definitely let me know if i'm mistaken. hoare at least didn't immediately abandon the term 'software engineering' to snake-oil merchants like boehm, continuing for decades his unsuccessful attempt to redefine the term to mean developing mathematics equipped to solve the problems of what you deride as 'mere software'
that's what electronic engineering, civil engineering, and mechanical engineering do; in an electronic engineering curriculum, for example, you learn to derive and apply formulas that describe the behavior of circuits (perhaps you would say 'mere circuits'), not of circuit designers
i don't entirely agree with dijkstra; i think, like hillel wayne https://www.hillelwayne.com/talks/crossover-project/, that software engineering is real engineering, in which it makes sense to talk about degrees of correctness other than 'perfect' and 'wrong', and testing is worthwhile, as is experience with actual physical computers. we have an enormous body of knowledge about how to do it effectively, including substantial and important contributions from dijkstra, hoare, and, yes, kent beck too. but not boehm
what boehm has contributed to it is mostly wrongheaded thinking we've had to battle against for decades, ultimately triumphing by outcompeting companies that practiced it wherever they aren't protected from market competition as trw was. also, getting the acm to withdraw from the hopelessly boehm-follower-corrupted swebok process
walk into any faang company or most startups and you'll find programmer-written unit tests for most of the code base, uniform code standards, refactoring, continuous integration, and small releases. these are four and a half of the 12 core practices of extreme programming, popularized by beck and friends though obviously not invented by him. (the other seven and a half, including tdd, are not so widely accepted.) you'll find algol-derived languages, structured control flow (if not structured programming as dijkstra visualized it), paged virtual memory, compiler-inserted virtual machine isolation, and semaphores. you'll find (again) algol-derived languages, quicksort, null pointers, often csp-based concurrency (erlang and golang), and sometimes even sound static type systems and formal methods. you'll find bytecode interpreters, top-down design, meta-key-based user interfaces, and sometimes even pascal derivatives if we count golang
by contrast, boehm's cocomo model, spiral model, wideband delphi, incremental cost model, and software cost estimation in general are nowhere to be found, because they're basically worthless and usually actually counterproductive. the sei cmm turned out to be a model not of capability but of incompetence. it's no wonder he spent much of that interview talking about the achievements of people he heckled at a conference one time in 01969 instead of his own
this is not because management and practices are unimportant. we've made enormous strides in the social systems that allow us to write software in the last 50 years. in addition to the kent-beck-popularized practices i listed above, usability testing, source control, decentralized source control, universal internet access, open-source licensing, stack overflow, automated build systems, bug tracking systems, coding interviews, canary deployments, fuzzing, and a/b testing have each individually been revolutionary. boehm invented zero of these and popularized zero of these, possibly because several of them involved software innovation
as for wasting people's time, i think you and i are the only people reading this thread; the only person whose time i'm wasting is my own