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.
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've always found rpg's Patterns of Software to have some deep insights into the nature of software systems. Particularly the ruminations on habitability.
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
