5 ms·
This (lengthy) quote comes to mind. If you think it is interesting, please read the whole EWD. EWD 340 (Prof. Edsgar Wybe Dijkstra) [1]: "The competent progra
by edejong 10y ago
This (lengthy) quote comes to mind. If you think it is interesting, please read the whole EWD.
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.html https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...
- galacticpony 10y agoI think it is interesting that you left out the very next few sentences, which provide very relevant context: "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.
- todd8 10y agoI agree with Dijkstra, the looping constructs of FORTRAN's DO and ALGOL 60 were too baroque. Dijkstra's comments were written in 1977, at that time FORTRAN IV and ALGOL 60's loop semantics were a mess and were common sources of errors. 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 https://en.wikipedia.org/wiki/Edsger_W._Dijkstra or in any resource on the history of Computer Science.
- galacticpony 10y agoI know about Dijkstra. 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.
- dhimes 10y agoTricks are fun- little puzzles. But they don't belong in code unless they both (1) significantly (relative you the task) save time and/or resources and (2) are very well explained in comments- like the full non-clever version being left in the code. 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.
- pjmlp 10y ago"I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras." -- Alan Kay, The Computer Revolution hasn't happend yet — 1997 OOPSLA Keynote
- voidlogic 10y agoWhile this may have a lot of truth to it, the ironic thing here is you are posting this in response to a Dijkstra quote urging us down the path of humility.
- TeMPOraL 10y agoHumility sometimes isn't, as currently discussed in https://news.ycombinator.com/item?id=13480255 https://news.ycombinator.com/item?id=13480255.
- edejong 10y agoCould you explain how exactly this quote is applicable to Dijkstra's quote? Which part do you think is arrogant? Alan seems to make an overly broad statement, which is funny, but also weak.
- sten 10y agoCorrect me if I'm wrong, but was Dijkstra not known for never actually using a computer. He wrote code with pencil and paper. There's a gulf between academic code and the needs of the day to day programmer. That said, I agree with his statement about one liners. Code should be parsimonious. It should never be a puzzle to understand what the code is doing.
- edejong 10y agoI hereby correct you. You are wrong. 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.
- DonaldFisk 10y agoGood advice. 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."