
Papers Every Programmer Should Read (At Least Twice) - ColinWright
http://blog.objectmentor.com/articles/2009/02/26/10-papers-every-programmer-should-read-at-least-twice
======
drv
A paper that would be on my personal list is "What Every Computer Scientist
Should Know About Floating-Point Arithmetic" (Goldberg):
[http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_go...](http://download.oracle.com/docs/cd/E19957-01/806-3568/ncg_goldberg.html)

~~~
unwind
Thanks for mentioning it, and saving me the work of typing (or copying) the
long title. This paper is great. If I had a dime for every time I've linked to
it on Stack Overflow, I would have a lot of foreign change of little practical
use.

------
ColinDabritz
There was an excellent cs theory stack exchange question on this:

[http://cstheory.stackexchange.com/questions/1168/what-
papers...](http://cstheory.stackexchange.com/questions/1168/what-papers-
should-everyone-read) [pdf]

The top two are nearly tied for: "A mathematical theory of communication" by
Claude Shannon

[http://guohanwei.51.net/code/A%20Mathematical%20Theory%20of%...](http://guohanwei.51.net/code/A%20Mathematical%20Theory%20of%20Communication.pdf)

"On Computable Numbers, with an Application to the Entscheidungsproblem" by
Alan Turing

[http://l3d.cs.colorado.edu/~ctg/classes/lib/canon/turing-
com...](http://l3d.cs.colorado.edu/~ctg/classes/lib/canon/turing-compnum.pdf)
[pdf]

I would add that

'The Annotated Turing' by Charles Petzold

<http://www.theannotatedturing.com/>

is an excellent treatment of Turings paper, including much of the relevant
additional math and computing history both before and after.

~~~
telemachos
More readable versions of the Shannon paper (and a more compressed pdf
version[1]) here: <http://cm.bell-labs.com/cm/ms/what/shannonday/paper.html>

[1] [http://cm.bell-
labs.com/cm/ms/what/shannonday/shannon1948.pd...](http://cm.bell-
labs.com/cm/ms/what/shannonday/shannon1948.pdf)

------
onan_barbarian
It's not a terrible list, but it's very biased towards the question "how
should we structure computer programs?".

This is a good question, but perhaps not the _only_ question, and I'm not sure
that a top 10 list would be quite so focused on it, at the expense of
algorithms, architecture, concurrency, networks, formal methods, etc.

I also doubt the ranty "Worse is Better" should be on any top 10 list,
influential or not. Some of these papers seem better suited to give someone a
background to furiously prognosticate here on HN and perhaps LtU than to do
anything of consequence.

~~~
quanticle
>This is a good question, but perhaps not the _only_ question.

I agree with narrow interpretation of your statement, but disagree with the
broad one. Yes, the structure of computer programs isn't the _only_ problem in
computer science/software engineering. However, I would argue that it's the
most _important_ question. Moreover, it's the only question that translates
well across domains. Algorithms, concurrency models, networks, etc. all will
vary depending on the exact problem you are trying to solve. The principles
behind good program structure, however, remain the same. It doesn't matter if
you're making a computational fluid dynamics simulation, nearest neighbor
classifier, relational database, enterprise inventory control, or a simple
blog engine; taking the time to create a good structure for your program
always pays off.

~~~
onan_barbarian
Any principle of 'good program structure' that applies across "computational
fluid dynamics simulation, nearest neighbor classifier, relational database,
enterprise inventory control, or a simple blog engine" is so vague as to be
meaningless - or at least, not very interesting.

Methodology weenies are always claiming that they've got abstractions that are
_absolutely key_ across very diverse problem areas, usually without any
demonstration that said abstractions are useful for solving hard problems in
any areas at all.

Compared to this kind of waffly crapulousness, we should compare the classic
papers on the design of, say, RISC, TCP/IP, etc. Grinding through how
Tomasulo's algorithm worked on the IBM/360, for example, will greatly expand
your understanding of actual computer architecture; the only weakness is that
it will not especially expand your ability to Issue Pronouncements About What
Good Programs Look Like.

~~~
onan_barbarian
... or more concisely, we will still be reading about 'branch and bound',
'parallel prefix', 'greedy algorithms vs divide and conquer', 'exponential
backoff', 'multi-level caching', 'speculative execution', etc, long after the
Revolution, when the last Object Orientation Guru is strangled with the guts
of the last Functional Programming Weenie.

------
fogus
I would add "Out of the Tarpit" by Ben Moseley and Peter Marks. I read it at
least twice a year.

<http://web.mac.com/ben_moseley/frp/paper-v1_01.pdf>

~~~
zerosanity
Your link goes to something else about an aikido dojo. Try this link:
<http://news.ycombinator.com/item?id=1730320>

~~~
fogus
Fixed. Thanks.

------
_delirium
Robert Kowalski (1979). "Algorithm = Logic + Control". _Communications of the
ACM_ 22(7): 424-436.
[http://www.doc.ic.ac.uk/~rak/papers/algorithm%20=%20logic%20...](http://www.doc.ic.ac.uk/~rak/papers/algorithm%20=%20logic%20+%20control.pdf)

(It's the paper that originated Prolog, but is also more broadly interesting
for its analysis of, well, algorithms as logic plus control.)

~~~
fanf2
Prolog was created around 1972 by Alain Colmerauer.

------
arethuza
Tony Hoare's ACM Turing Award lecture "The Emperor's Old Clothes":

<http://awards.acm.org/images/awards/140/articles/4622167.pdf>

------
pnathan
I've always found rpg's Patterns of Software to have some deep insights into
the nature of software systems. Particularly the ruminations on habitability.

------
endlessvoid94
"On the Designing and Deploying Internet-scale Services" by James Hamilton:
<http://www.mvdirona.com/jrh/talksAndPapers/JamesRH_Lisa.pdf>

html version:
[http://www.usenix.org/event/lisa07/tech/full_papers/hamilton...](http://www.usenix.org/event/lisa07/tech/full_papers/hamilton/hamilton_html/)

------
cpeterso
Butler Lampson's _"Hints for Computer System Design"_ (1983) is a classic
paper with some great anecdotes:

[https://research.microsoft.com/en-
us/um/people/blampson/33-H...](https://research.microsoft.com/en-
us/um/people/blampson/33-Hints/WebPage.html)

------
adulau
MapReduce: Simplified Data Processing on Large Clusters by Jeffrey Dean and
Sanjay Ghemawat (OSDI'04: Sixth Symposium on Operating System Design and
Implementation) <http://labs.google.com/papers/mapreduce.html>

------
astrofinch
Anyone know where I can find an ungated version of "An experimental evaluation
of the assumption of independence in multiversion programming"?

~~~
ColinWright
Simply putting the title into Google gave this as its second hit:

<http://sunnyday.mit.edu/papers/nver-tse.pdf>

~~~
astrofinch
Thanks. Sorry 'bout that; I only tried Google Scholar.

------
Iv
A programmer should not encourage paywalls.

------
VinzO
It seems the site is down :(

Any mirror link?

~~~
fogus
Google to the rescue?

[http://webcache.googleusercontent.com/search?q=cache:D6mF_SI...](http://webcache.googleusercontent.com/search?q=cache:D6mF_SI2jsYJ:blog.objectmentor.com/articles/2009/02/26/10-papers-
every-programmer-should-read-at-least-
twice+http://blog.objectmentor.com/articles/2009/02/26/10-papers-every-
programmer-should-read-at-least-
twice&cd=1&hl=en&ct=clnk&gl=us&source=www.google.com)

