Let me preface this post by saying that no programmer should feel compelled to read any of these papers. I list them because I think that they provide a breadth of information that is generally useful and interesting from a computer science perspective. What you do with that information is your prerogative, including ignoring it completely. Instead, learn what you think is important for what you need to accomplish your job, education, interests, etc.
Inspired by a fabulous post by Michael Feathers along a similar vein, I’ve composed this post as a sequel to the original. That is, while I agree almost wholly with Mr. Feather’s[^writing] choices, I tend to think that his choices are design-oriented[^design] and/or philosophical. In no way, do I disparage that approach, instead I think that there is room for another list that is more technical in nature, but the question remains, where to go next? In this post I will offer some guidance based on my own readings. The papers chosen herein are not intended to act as a C.S. hall of fame, but instead hope to accomplish the following:
Because of these constraints I will have missed some great papers, but for the most part I think this list is solid. Please feel free to disagree and offer alternatives in the comments.
by Christopher Strachey
Quite possibly the most influential set of lecture notes in the history of computer science. Left and Right-values, Parametric and Ad-hoc polymorphism were all defined in this paper. Much of the content may already occupy your mind, but the sheer weight of the heady topics assembled in one place is stunning to observe.
by John Hughes
I found this paper extremely lucid on the advantages of functional programming with the added advantage of showing off examples of beautiful code. There are seemingly an infinite number of papers on the topic of laziness with streams and generators, but I’ve yet to find a better treatment. Finally, I’ve always been partial to Reginald Braithwaite’s “Why Why Functional Programming Matters Matters” as a complement to this paper.
by C. A. R. HOARE
I came to this paper late in my career, but when I finally found it I felt like I had been hit by a bus. At the core of the paper lies the following assertion:
P {Q} RTaken to mean:
If the assertion P is true before initiation of a program Q, then the assertion R will be true on its completion
Where P is a precondition, Q is the
execution of a program, and R is the result.
In other words, as long as a program/function/method/etc. receives a set of parameters conforming to its preconditions, its execution is guaranteed to produce a well-formed result. This paper inspired me to explore contracts programming in Clojure, but the proof implications reached in Hoare’s paper run much deeper.
by Leslie Lamport (1978)
Lamport has been highly influential in the field of distributed computation for a very long time and almost any of his papers on the subject should impress. However, this particular paper is likely his most influential and single-handed defined two branches of study in distributed computing since:
The most amazing aspect of this paper is that after you read it you might think to yourself, “Well, of course that’s how it should work.” Jim Gray once said that this paper was both obvious and brilliant. I would say that there is no higher compliment.
by Luca Cardelli and Peter Wegner
I had originally thought to list Milner’s A Theory of Type Polymorphism in Programming, but thought that a survey paper would be better. I must admit that my own readings have not gone deep into the exploration of type systems, so any additional suggestions would be greatly appreciated.
by John McCarthy
It’s become a cliche to recommend McCarthy’s seminal paper introducing LISP. I will not count this toward the target of 10, but I would be remiss to excluse it because it’s a great read that is nicely supplemented with the study of a simple implementation of McCarthy’s original specification.[^lisp]
by Michael Ernst, Craig Kaplan, and Craig Chambers
Describes a method for dispatching functions based not on a static set of rules, but instead as the traversal of a decision tree that could be built at compile-time and extended incrementally at runtime. What this means is that dispatch is controlled and adapted based on an open set of conditions describing the rules of dispatch. This stands opposed to the current popular trend of languages whose dispatch is hard-coded and not open for extension at all.
by Henry G. Baker
At the heart of Clojure and ClojureScript’s implementation is
#equiv that is in turn based off of Henry Baker’s
egal operator introduced in this paper. Briefly, equality
in Clojure is defined by equality of value, which is facilitated by
pervasive immutability. Equality in the presence of mutability has no
meaning.
by David Ungar, Craig Chambers, Bay-wei Chang, and Urs Hölzle
The greatest crime perpetrated in the name of JavaScript is the propensity for every framework, library, and trifle uses the prototypal inheritance capabilities of the language to implement class-based inheritance. I propose that this behavior stunts the power of JavaScript. However, the class-based mentality is pervasive, and is only likely to grow stronger as JavaScript moves toward “modernized” data-modeling techniques. Having said that, I love the prototypal model. It’s flexibility and simplicity is astounding, and this paper[^self