Papers Every Programmer Should Read (At Least Twice) | Hacker News Reader

Papers Every Programmer Should Read (At Least Twice)

blog.objectmentor.com

358 pointsColinWright26 comments

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...

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.

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

http://cstheory.stackexchange.com/questions/1168/what-papers... [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%...

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

http://l3d.cs.colorado.edu/~ctg/classes/lib/canon/turing-com... [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.

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...

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.

>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.

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.

... 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.

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

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

Fixed. Thanks.

Never seen that! Thanks! This link works for me: http://web.mac.com/ben_moseley/frp/paper-v1_01.pdf

Thanks for posting this fogus. This is great so far.

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...

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

Prolog was created around 1972 by Alain Colmerauer.

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

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

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.

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...

"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...

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

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

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

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

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

A programmer should not encourage paywalls.

It seems the site is down :(

Any mirror link?

Google to the rescue?

http://webcache.googleusercontent.com/search?q=cache:D6mF_SI...

Reply on news.ycombinator.com