Niklaus Wirth, 1934-2024: Geek For Life

Well, you have to leave something to the Intelligence of the Reader :-)

> anyway, i think that if you want advice on programming, you should get it from people who are good at it. people who think software is 'mere software' are never going to achieve anything in the field and can be safely disregarded, however many awards they receive.

Again, Violently Disagree! People who think Djikstra/Hoare/Boehm/other greats had not written much "code" to warrant being taken seriously and were "mere theorists" do not understand the first thing about Science/Research/Meta-whatever and Engineering/Implementation; the former is the bedrock on which the latter stands.

> wirth's achievements as a Scientist/Engineer/Technician/Programmer/Coder were because he took software seriously, the opposite extreme from the 'mere software' viewpoint

Not opposite, he was both a Scientist and an Engineer which is the source of his greatness. Languages/Compilers/OS/HDL/Processor design/Applications the man did it all.

certainly wirth and dijkstra laid the foundations of modern software development; so, too, did mccarthy, perlis, sussman, steele, kay, minsky, mcilroy, ritchie, thompson, and perhaps most of all stallman

here's minsky: https://web.media.mit.edu/~minsky/papers/Why%20programming%2...

article title: "WHY PROGRAMMING IS A GOOD MEDIUM FOR EXPRESSING POORLY UNDERSTOOD AND SLOPPILY­-FORMULATED IDEAS"

> boehm's does not. instead he theorized about how to manage programmers,...

Absolutely not! "Software Engineering" is far far more than just "manage programmers". Either you are unaware of his work or are intentionally downplaying it. His wikipedia page lists his works/achievements for everybody to read/study. He was a first-class theorist in the fields of "Software Engineering Economics", "Software Process Methodologies" and "Software Engineering" to name a few.

I am well aware of the works of Djikstra/Hoare/Wirth/etc. and how their work is different from that of Boehm's/Parnas'/etc. For the purposes of our discussion i am lumping them under the term "the greats" to highlight their fundamental and complimentary contributions to the field.

> Having described —admittedly in the broadest possible terms— the nature of computing's novelties, I shall now provide the evidence that these novelties are, indeed, radical. I shall do so by explaining a number of otherwise strange phenomena as frantic —but, as we now know, doomed— efforts at hiding or denying the frighteningly unfamiliar.

> A number of these phenomena have been bundled under the name "Software Engineering". As economics is known as "The Miserable Science", software engineering should be known as "The Doomed Discipline", doomed because it cannot even approach its goal since its goal is self-contradictory. Software engineering, of course, presents itself as another worthy cause, but that is eyewash: if you carefully read its literature and analyse what its devotees actually do, you will discover that software engineering has accepted as its charter "How to program if you cannot.".

> The popularity of its name is enough to make it suspect. In what we denote as "primitive societies", the superstition that knowing someone's true name gives you magic power over him is not unusual. We are hardly less primitive: why do we persist here in answering the telephone with the most unhelpful "hello" instead of our name?

> Nor are we above the equally primitive superstition that we can gain some control over some unknown, malicious demon by calling it by a safe, familiar, and innocent name, such as "engineering". But it is totally symbolic, as one of the US computer manufacturers proved a few years ago when it hired, one night, hundreds of new "software engineers" by the simple device of elevating all its programmers to that exalting rank. So much for that term.

> The practice is pervaded by the reassuring illusion that programs are just devices like any others, the only difference admitted being that their manufacture might require a new type of craftsmen, viz. programmers. From there it is only a small step to measuring "programmer productivity" in terms of "number of lines of code produced per month". This is a very costly measuring unit because it encourages the writing of insipid code, but today I am less interested in how foolish a unit it is from even a pure business point of view. My point today is that, if we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent": the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

> Besides the notion of productivity, also that of quality control continues to be distorted by the reassuring illusion that what works with other devices works with programs as well. It is now two decades since it was pointed out that program testing may convincingly demonstrate the presence of bugs, but can never demonstrate their absence. After quoting this well-publicized remark devoutly, the software engineer returns to the order of the day and continues to refine his testing strategies, just like the alchemist of yore, who continued to refine his chrysocosmic purifications.

you're bringing up the very real achievements of people like dijkstra and parnas in order to confuse the reader into putting boehm in the same category, as if he had achieved something similar. perhaps he could have, he was a smart guy, but he didn't, probably because he believed in 'mere software'. he ended up as a snake oil merchant, a successful one who found a lot of buyers. you're in danger of wasting your life the same way

I am fully aware of Djikstra's criticism and i am not sure what you hope to show by pasting a wall of text. Just to clarify, his criticism was appropriate at that time since the field was just coming into existence and there wasn't much nailed down. The situation now is very different, we have decades of research/models/experience for a sound basis mainly due to folks like Parnas/Boehm.

It is actually funny for me to see you quote Djikstra since the whole XP/Agile rigmarole is the very antithesis of everything he stood for i.e. writing programs which are "correct" by design using Predicate Logic and not the XP/Agile method of "design and refactor a self-created mess as you go".