A collection of quotes related to programming and computing that I particularly like.

  • On complexity vs simplicity:
    “Finally, the days where a novice programmer can know all of a language are gone, at least for the languages in widespread industrial use. Few people know “all of C” or “all of Java” either and none of those are novices. It follows that nobody should have to apologize for the fact that novices do not know all of C++. What you must do—in any language—is to pick a subset, get working writing code, and gradually learn more of the language, its libraries, and its tools.” Bjarne Stroustrup, Why is C++ So Big?
    … versus…
    “If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.” Dan Ingalls, from Design Principles Behind Smalltalk
    (via Patrick Logan and Blaine Buxton).
  • “There are only two hard things in Computer Science: cache invalidation and naming things.” Tim Bray, quoting Phil Karlton.
  • “In a concurrent world, imperative is the wrong default!” Tim Sweeney of Epic Megagames, in The Next Mainstream Programming Languages: A Game Developer’s Perspective.
  • “Much of the power of C comes from having a powerful preprocessor. The preprocessor is called a programmer.” P. J. Moylan, The Case Against C.
  • “To write a program that adds two numbers on the long-dead Apple II, you turn it on (boot time is undetectable!) and press Control-B, which gets you into BASIC. If you then type PRINT 3+4 and press Return, you get 7 instantly and painlessly. From launching BASIC to result: five seconds… [since the era of the Apple II] something wonderfully straightforward has been lost: in particular, the immediate feedback that humans need in order to quickly iterate their way to an effective program.” Jef Raskin, The Humane Interface.
  • “The multiplicity of the design space constantly confuses apprentice designers. Given a software design problem, what’s a good solution to it? Events? Objects? Observers? Callbacks? Virtuals? Templates?… The most important difference between an expert software architect and a beginner is the knowledge of what works and what doesn’t.” Andrei Alexandrescu, Modern C++ Design.
  • “Some people, when confronted with a problem, think ‘I know, I’ll use regular expressions.’ Now they have two problems.” Jamie Zawinski.
  • “If POSIX threads are a good thing, perhaps I don’t want to know what they’re better than.” Rob Pike.
  • “I invented the term Object-Oriented, and I can tell you I did not have C++ in mind.” Alan Kay.
  • “It slowly became apparent that one thing not in my methodological equation, or, in fact, in anyone else’s, as far as I can see, is the effect of “people” on methodologies. Once I started accounting for this quantity, I found my methodological predictions and results started matching my experiences. I now consider the characteristics of people as the dominant, first-order project driver… The fundamental characteristics of “people” have a first-order effect on software development, not a lower-order effect. Consequently, understanding this first-order effect should become a first-order research agenda item, and not neglected as a second-order item.” Alistair Cockburn, Characterizing people as non-linear, first-order components in software development.
  • “In their capacity as a tool, computers will be but a ripple on the surface of our culture. In their capacity as intellectual challenge, they are without precedent in the cultural history of mankind.” Edsgar W. Dijkstra.
  • “… while we all know that unmastered complexity is at the root of the misery, we do not know what degree of simplicity can be obtained, nor to what extent the intrinsic complexity of the whole design has to show up in the interfaces. We simply do not know yet the limits of disentanglement. We do not know yet whether intrinsic intricacy can be distinguished from accidental intricacy.” Edsgar W. Dijkstra, Communications of the ACM, Mar 2001, Vol. 44, No. 3. (There’s also plenty of other great Dijkstra quotes.)
  • “Any verbose and tedious solution is error-prone because programmers get bored.” Bjarne Stroustrup, C++ (2nd edition).
  • “Haskell is so strict about type safety that randomly generated snippets of code that successfully typecheck are likely to do something useful, even if you’ve no idea what that useful thing is.” sigfpe
  • “… we did not (and still do not) believe in the standard multithreading model, which is preemptive concurrency with shared memory: we still think that no one can write correct programs in a language where a=a+1 is not deterministic.” Roberto Ierusalimschy, Luiz Henrique de Figueiredo and Waldemar Celes: The Evolution of Lua.
  • Edward A. Lee has a number of great quotes in a paper about The Problem with Threads:
    “… a folk definition of insanity is to do the same thing over and over again and to expect the results to be different. By this definition, we in fact require that programmers of multithreaded systems be insane. Were they sane, they could not understand their programs.”
    “I conjecture that most multi-threaded general-purpose applications are, in fact, so full of concurrency bugs that as multi-core architectures become commonplace, these bugs will begin to show up as system failures. This scenario is bleak for computer vendors: their next generation of machines will become widely known as the ones on which many programs crash.”
    “Syntactically, threads are either a minor extension to these languages (as in Java) or just an external library. Semantically, of course, they thoroughly disrupt the essential determinism of the languages. Regrettably, programmers seem to be more guided by syntax than semantics.”
    “… non-trivial multi-threaded programs are incomprehensible to humans. It is true that the programming model can be improved through the use of design patterns, better granularity of atomicity (e.g. transactions), improved languages, and formal methods. However, these techniques merely chip away at the unnecessarily enormous non-determinism of the threading model. The model remains intrinsically intractable.” (Does that “intractable” word remind you of anyone else?)
    “… adherents to… [a programming] language are viewed as traitors if they succumb to the use of another language. Language wars are religious wars, and few of these religions are polytheistic.”
  • “Frameworks don’t solve scalability problems, design solves scalability problems.” Ryan Tomayko, Rails and Scaling with Multiple Databases. (Ahem, hello Erlang!)
  • “I swear, text will be the death of me.” Dan Sugalski, on how much fun human languages, internationalisation and Unicode is to deal with.
  • “… developers (and especially development managers) tend to be pushovers. I believe this to be so to a large extent because they don’t have a high enough regard for the principles of their craft. If you are a developer working with an overbearing “business” person, it’s your responsibility to stand up for the system and make the case for the consequences of bad decisions (past and present).” Patrick Logan.
  • “We haven’t gotten any smarter, we’ve just changed our representation system. We think better generally by inventing better representations; that’s something that we as computer scientists recognize as one of the main things that we try to do.” Alan Kay, Predicting the Future.
  • “We’ve also seen the rise of PHP, which takes the worse-is-better approach to dazzling new depths…” Larry Wall, Programming is Hard, Let’s Go Scripting…
  • “The design process and the scientific method are the same thing with different names,” Didier Elzinga. (How true is this for coding?)
  • “Threadsafe is an oxymoron.” Dr. Richard Hipp, from his SELECT * FROM SQLite_internals talk at C4[2].
  • “Try writing a formal proof of correctness of a sizable imperative program some day, and then remember that formal provability is a good proxy for how easy it is for humans to understand something!” Adam Chlipala.
  • “If the data structure can’t be explained on a beer coaster, it’s too complex.” Felix von Leitner, Source Code Optimization.
  • “When the Lisa team was pushing to finalize their software in 1982, project managers started requiring programmers to submit weekly forms reporting on the number of lines of code they had written. Bill Atkinson thought that was silly. For the week in which he had rewritten QuickDraw’s region calculation routines to be six times faster and 2000 lines shorter, he put ‘-2000’ on the form. After a few more weeks the managers stopped asking him to fill out the form, and he gladly complied.” Andy Herzfeld talking about Bill Atkinson.