How to Read a Paper
S. Keshav
Researchers spend a great deal of time reading research papers. However, this skill is rarely taught, leading to much wasted effort. This article outlines a practical and efficient three-pass method for reading research papers. I also describe how to use this method to do a literature survey.
- The author advocates a three pass approach. On the first pass the reader should only read the abstract, introduction, and conclusion in full and for the rest of the paper simply read the section and subsection titles. On the second pass the reader should read the paper in more carefully, but without diving into hairy mathematical details. At the end of this pass the reader should be able to summarize the paper's argument and explain its main points to someone. Finally, if full mastery of the material is required, the reader should then attempt to reimplement the paper. Once a reader does this they will be able to notice any innovative arguments the authors make as well as anything they may have brushed under the rug.
- This paper also lays out a set of guidelines for a literature survey that seems like a great way to get to the meat of a subject without wasting time on low quality papers. The author advises seeking out highly cited papers in the field and then combing through shared citations to get a sense for the top researchers in the field and continuing on to their papers.
A Note on Distributed Computing
Jim Waldo, Geoff Wyant, Ann Wollrath, Sam Kendall
We argue that objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space. These differences are required because distributed systems require that the programmer be aware of latency, have a different model of memory access, and take into account issues of concurrency and partial failure. We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability. These failures have been masked in the past by the small size of the distributed systems that have been built. In the enterprise-wide distributed systems foreseen in the near future, however, such a masking will be impossible. We conclude by discussing what is required of both systems-level and application-level programmers and designers if one is to take distribution seriously.
- The thesis of this paper is that it is not possible to abstract away the distributed nature of a computation for the ease of programers without paying a price. If you choose to simplify the programming interface to hide its distributed nature you are implicitly giving up the reliablility of any computations performed. When you hide the distributed nature of the computation from the programmer you do not provide a window into how a computation is broken up accross multiple machines and because of this there is no way to properly recover if one the machines involved in a computation fails midway. The only way to remedy this is to complicate the programming interface by unveiling the distributed nature of the environment and ensuring that developers take care to check that each machine successfully completes their sub computations. This significantly adds to the developer's burdens, but is the only way to guarantee a reliable system.
- Outlines the three key difference between single machine and distributed computations. These differences are the latency increase created by making machines talk accross a network, the difficulty of memory access accross machines (how to manage pointers to memory from one machine to another), and how to handle one or more machines failing during a computation.
- Gives an interesting breakdown of the failures of Sun's NFS. The authors show that all of NFS's problems have stemmed from the fact that its interface was not designed to address the distributed nature of the application and, as such, has no means to recover in the event of a partial failure.