"I see a great future for very systematic and very modest programming languages. When I say “modest”, I mean that, for instance, not only ALGOL 60’s “for clause”, but even FORTRAN’s “DO loop” may find themselves thrown out as being too baroque."
While I agree with the general sentiment, it's very important to take anything Dijkstra says with a huge grain of salt. He was a mathematician first and foremost. He obsessed about things like a mathematician. Such people, while very smart, make for very unproductive software engineers. They also have a way of sounding deceptively smart and thoughtful, when really they're just talking out of their ass. Beware.
Without qualification, Dijkstra was one of the greatest computer scientists in our field's short history. While I don't agree with every single one of his ideas, I would encourage budding computer scientists and professional programmers to look over what he accomplished. He most certainly was not unproductive.
Wikipedia says that Dijkstra is known for:
- Dijkstra's algorithm (single-source shortest path problem)
- DJP algorithm (minimum spanning tree problem)
- First implementation of ALGOL 60 compiler
- Structured analysis
- Structured programming - Semaphore
- Layered approach to operating system design
- T.H.E. multiprogramming system (one of the first operating systems)
- Concept of levels of abstraction
- Concept of layered structure in software architecture (layered architecture)
- Concept of cooperating sequential processes
- Concept of program families
- Multithreaded programming
- Concurrent programming
- Concurrent algorithms
- Principles of distributed computing
- Distributed algorithms
- Synchronization primitive
- Mutual exclusion
- Critical section
- Generalization of Dekker's algorithm
- Tri-color marking algorithm
- Call stack
- Fault-tolerant systems
- Self-stabilizing distributed systems
- Resource starvation
- Deadly embrace
- Deadlock prevention algorithms
- Shunting-yard algorithm
- Banker's algorithm
- Dining philosophers problem
- Sleeping barber problem
- Producer–consumer problem (bounded buffer problem)
- Dutch national flag problem
- Predicate transformer semantics
- Guarded Command Language
- Weakest precondition calculus
- Unbounded nondeterminism
- Dijkstra-Scholten algorithm
- Smoothsort
- Separation of concerns
- Program verification
- Program derivation
- Software crisis
- Software architecture
This quote by galactipony is really offensive to me:
> Such people, while very smart, make for very unproductive software engineers. They also have a way of sounding deceptively smart and thoughtful, when really they're just talking out of their ass. Beware.
It is quite clear to me that Dijkstra wasn't "just talking out of [his] ass."
Learn more about Dijkstra at https://en.wikipedia.org/wiki/Edsger_W._Dijkstra or in any resource on the history of Computer Science.
I didn't say Dijkstra was talking out of his ass in this case. I'm saying you often can't tell when people like him are talking out of their ass, as they sometimes do. Who would think the inventor of all these algorithms would ever utter a half-formed thought, on a whim? Unthinkable! Yeah... no.
Another distinction you fail to see is that somebody who is great at finding the best or optimal algorithms (i.e. a great theorist) isn't necessarily a productive programmer. To the contrary, perfectionism and productivity are at great odds.
Dijkstra was heavily at odds with real-world programming as it was done, to the point of isolating himself with his work. If we followed his opinions on how to program, we wouldn't get much of anything done.
I suppose what you're saying here is that there are a lot of business tasks which don't require a great theorist.
I don't think Dijkstra would disagree.
But still, calling Dijkstra an "unproductive programmer"? Really? I'll take one Dijkstra's algorithm over a dozen web apps. And if I can have a patent on it, I can even make a solid business case for that choice.
> If we followed his opinions on how to program, we wouldn't get much of anything done.
And yet, how many man-years of engineering effort could we waste having bad theorists who can quickly hack out LoB code try to re-invent Dijkstra's algorithm?
Perhaps software engineering is a very wide field, and it takes all types?
I've learned this the hard way in my career. I always have to fight against taking the extra 20 hours to perfect something when it only took me 1 hour to get to 95% and 95% is more than good enough for the particular task.
But, lets discuss the 'for clause' and 'do loop': these constructs were made specifically for one kind of simple loop. It is not a systematic solution for an iterative process. To me it seems Dijkstra specifically aims for languages such as LISP (which, with the renewed interest from Clojure is one of the most oldest successful (semi-) functional programming languages).
It still seems intellectually dishonest to leave it out. Clearly, what Dijkstra in 1972 considers too "clever" may in fact be tools that are now basic building blocks of everyday software. We can all agree that "too clever" is bad. We can't agree on what "too clever" is.
"But, lets discuss the 'for clause' and 'do loop': these constructs were made specifically for one kind of simple loop. It is not a systematic solution for an iterative process."
I'm fairly sure (from what I remember him writing) that he doesn't like it because you can do the same thing with existing constructs, so you'd be adding complexity to the language that isn't strictly necessary. History has shown that actual programmers prefer having for loops like Algol.
"To me it seems Dijkstra specifically aims for languages such as LISP (which, with the renewed interest from Clojure is one of the most oldest successful (semi-) functional programming languages)."
Probably not, or else he would've talked about LISP in a different manner (he does talk about it in an earlier paragraph).
Yes, programmers prefer it, but the general structure:
`for (init-statement ; boolean-continuation-expression ; iteration-statement) statement;` is syntactic sugar for a specific imperative process (with the iteration and ending expression appended at the end of the block). It does not generalize to other imperative processes, it cannot be transformed into a meaningful expression and it invites 'clever' programmers to do 'too much' in the various for-clauses.
Wrt to LISP, do you mean this part? That seems to align well with my standpoint: use very few basic principles and be stable.
"The third project I would not like to leave unmentioned is LISP, a fascinating enterprise of a completely different nature. With a few very basic principles at its foundation, it has shown a remarkable stability. Besides that, LISP has been the carrier for a considerable number of in a sense our most sophisticated computer applications. LISP has jokingly been described as “the most intelligent way to misuse a computer”. I think that description a great compliment because it transmits the full flavour of liberation: it has assisted a number of our most gifted fellow humans in thinking previously impossible thoughts."
Of course we agree. Too clever is "stuff I'm too lazy to understand". What we don't agree is on the definition of I; everyone has their own binding for that symbol, which carries a context for different types of stuff we are too lazy to understand.
If you have to spend time explaining 'what' the code is doing, it is "too clever".
If you have to spend time explaining 'why' the code is doing something.. then "them's the breaks working in a complicated world".
Code should only be as complex as the problem domain.
It's not absolute. It's something to be negotiated at a particular shop.
-- Alan Kay, The Computer Revolution hasn't happend yet — 1997 OOPSLA Keynote
Alan seems to make an overly broad statement, which is funny, but also weak.
Dijkstra decided to program using pencil and paper much later, and mostly because he (like most good programmers) already knew the solution before writing it down.
I correct you again for implying he wrote purely academic code. This is plainly false: for example, he specified part of and implemented the compiler of the Algol-77 language. He implemented one of the first multi-layer (ring-based) OSes.
And then you mention the day-to-day programmer is not in need of academic code. To the contrary! Dijkstra argued that the software crisis (the gap between what computers can do, and what they are actually doing) is caused because day-to-day programmers do not have the right tools and knowledge at hand. In EWD 340, Dijkstra argues this is caused by the mental overhead caused by clever tricks and languages allowing these tricks.
As a professional, I am constantly relating to concepts and code which have an academic basis. Examples are from type theory, lambda calculus, paxos, map-reduce, queueing theory, compression algorithms and many more. I have seen many programming languages, wrote assemblers, interpreters and compilers, worked professionally with imperative, OOP, functional and (higher-order) logical languages, so I dare to say that programming is not about what you can do with the language, but what the language does with you.
I know I'm preaching to the choir here. I know we've all come back to our own code six months later and had to puzzle it out.
More on cleverness from an old AI textbook (Artificial Intelligence Programming by Charniak, Riesbeck and McDermott):
"1.12.5 Cleverness
Avoid it . Clever tricks ... [Lisp specific stuff omitted.]
To paraphrase Samuel Johnson, we advise you to look over your code very carefully, and whenever you find a part that you think is particularly fine, strike it out."
EWD 340 (Prof. Edsgar Wybe Dijkstra) [1]:
"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called “the one-liners”. It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question “Can you code this in less symbols?” —as if this were of any conceptual relevance!— or he just asks “Guess what it does!”. From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language. Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. "
[1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...