The Humble Programmer (1972)

On a serious note, you do have a good point. I haven't read much of Dijkstra's work myself.

More precisely he is always a champion of the idea of having programs express things in a direct and understandable way which makes comprehension straightforward. And a champion of getting there by removing unneeded features from languages.

This was a necessary overcorrection to now-forgotten excesses. But today it is clear that he went too far. As an example, I would consider Go's a language which is heavily influenced by Dijkstra's ideas on the value of simplicity in language design. However the internal loop exit implied by break exists. Multiple return values are used to separate out data (the result of a calculation) from metadata (the presence and details of errors). We use features beyond what Dijkstra considered wise.

That's impossible; Discipline of Programming has only 217 pages of text. Surely you've been so enthralled by your reading that you didn't notice skipping through the covers to the book laying below!

You need to understand that Dijkstra's primary research focus was algorithms. Mathematically deriving algorithms from formal specifications isn't a weird idea at all. Sure, it feels cumbersome when the algorithm you're deriving is a commonly known one, like a mergesort or a binary search. The idea is that you can derive other, more specific algorithms in the same way, and you'll have proven their correctness.

These days, algorithms are not a major part of most computer systems. Trying to apply Dijkstra's approach to a user interface or a JSON parser makes little sense. But this does not invalidate the method for its intended domain. It also does not make Dijkstra's ramblings misguided nonsense.

Conceiving simple tests to prove a simple piece of programming works, keeps it simple. Simple is powerful.

Does anyone know what these test problems and solutions were? Or have similar examples?

For example, processing power, communication speed, and storage has improved by orders of magnitude, but battery capacity is perhaps better by one factor of ten. Much of the advance in battery life comes from reduced power consumption by other components. Much of the advance in software development has come by creating inefficient abstractions that let us create things faster but squander CPU, network, and battery life.

Most companies today are willing to burn up some hardware performance in order to reduce software development time. If they're burning too much, they'll fix it or they'll go out of business. Premature optimization is still not a good idea.

Since then, programs are shared and run on many more machines; the cost is amortized through portability and writing general-purpose tools. Dijkstra was right to say that something had to change, but he didn't anticipate the efficiency gains from sharing portable software, at least not in this essay. Instead he seems to have thought that programmers should learn to write programs faster. We've made some progress on that, but the great efficiency gains happened at a higher level.

I spend about an hour on HN a day, in small bouts. Most of the time I will skim over titles to see if there is anything interesting, if there is and its a long read (like this one) I will save it to "Pocket" to read it later. I will probably get around to reading this few weeks or even a month from now.

I suspect, very few people will read it on the spot, which is why even interesting submissions like this doesn't get a lot of discussions.

I think the problem with Dijkstra is that A) he views every program as a huge algorithm, where 90% of programming now is doing IO and user interfaces B) he doesn't take into consideration that people can have different brain wiring than he has and be effective with other techniques that the ones he advocates.

And since there's a lack of comments on many of the threads, I'll add my opinion to this one. This was written by a man who's got a long-term love affair with programming. I recognize this because I am the same way, and it's actually rarer than you might think.

Most of the people who were my colleagues have gone on to management, or more likely switched to other careers. I've been in management repeatedly (even C-level) and have had to talk my way back into software architecture and development. I wrote my first program 41 years ago and it's still my favorite past-time.

But I suspect that the main reason why it's hard for most people to talk about his work is that they lack the historical context to understand what he's talking about. For someone who has never studied or used FORTRAN, ALGOL 60, or any of the macro languages he alludes to, his criticisms seem very abstract. For someone who has seen those languages, they're concrete and visceral.

Looking back twenty years ago, I now understand that one of the highest-value courses in my CS degree was the "Survey of Programming Languages" class. We spent two to three weeks studying and working with each of LISP, FORTRAN, ALGOL-60, Smalltalk, and a couple others I don't remember. I enjoyed the class but at the time I wasn't developed enough to think more than "man, people sure have come up with some strange ways of doing things; ok, back to C, I love my filesystems class."

Now I recognize how precious that exposure was. It's kind of like traveling; exposure to different cultures teaches you as much about your own culture as about theirs. You don't always realize what assumptions you're making until you see other people making different assumptions.

This is the value of formal CS education, i.e. Dijkstra's life work. Some people ask whether a CS degree is worthwhile when the Internet makes it so easy to learn how to program. It's the difference between university and vocational training; if you only want fix cars, you just need some skills classes and time spent apprenticing in a mechanic's shop. If you want to be an automotive engineer, you need an engineering education. If you just want a job, you don't need college; if you want to participate in the core of what our civilization has to offer, you need an education (self-study or formal, doesn't matter).

(Tip for the kids in school today: If you're at university and you find yourself frequently saying "Why do I have to learn this crap? I'll never use it!" then you might just be wasting your time and money. Do yourself a favor and drop out, unless someone else is paying for your play time. But if you learn for the sake of learning, if you recognize that learning how to learn, to prepare for a lifetime of learning, is the point of education, then stay in school, since you'll reap the rewards many times over.)

It's interesting how terminology has changed. In the 1970s you might have been able to say that Dijkstra was part of a field called "software engineering", in that he was writing about methodology for developing software. But in the 1980s it became a fairly different field, focused more on how to develop effective processes for large-scale development (modeling, testing, code review, team structure, tooling, etc.). By 1988 Dijkstra was vehemently against that version of software engineering.

Here's his article on that subject: http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036...

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.".

Take some time, this one is worth stepping back from the Internet firehose of information and sipping the lemonade of prose.

If it is too long for you, then it is only good you don't waste your precious little time on this planet reading it.