2 ms·
I'd like to disagree with this. In particular, about [1]: It is a collection of papers in many different topics. There is little technical overlap between Alan
by puzzledobserver 3y ago
I'd like to disagree with this. In particular, about [1]: It is a collection of papers in many different topics. There is little technical overlap between Alan Turing's Entscheidungsproblem paper, for instance, and Hoare's paper on axiomatic semantics. Also, the papers are all from the 70s. They're uniformly influential papers, and have shaped the field, but the fields and the vernacular used by working researchers is very different. At best, the papers approximate a four year undergrad curriculum in CS, and at worst, are a recipe to get distracted and overwhelmed. The link to Wikipedia [2] is somewhat better in that the papers appear to be more modern, but suffers even more from the problem of diversity.
A somewhat similar problem arises with test-of-time and best paper awards. To elaborate on my complaint, imagine the exaggerated case of someone trying to understand modern science by intensely focusing on the work of researchers who won the Nobel Prize. Clearly all very important work, but understanding the 1990 Physics Nobel Prize (on electron-proton scattering) is of no use to understanding the work for which 1991 Nobel was awarded (complex systems and polymers).
There are two things that (I'm assuming the OP's field of interest is computing) a CS education provides: At the undergrad and in the early stages of grad school, breadth of topics, and their modern synthesis. You don't spend much time reading papers (at least in an undergraduate education), but you understand the basics, and get a feel for the problems considered and the sensibilities of researchers. In an intermediate-level graduate seminar, you pick a narrow topic, and focus on papers in that topic. The first papers in the area (like Dijkstra's papers on distributed computing), the best / most important papers in the area, and the latest papers on topical interests (like Merkle trees and blockchains). There is thematic and technical continuity from one paper to the next, and you start to understand the the story being told. Then, late in graduate school, and in the rest of one's professional career, one starts reviewing papers that haven't even been published. At this point, you see the story being written: the steps and the missteps, and the memorable and not-so-memorable papers in a field. To truly understand a field, one needs to read not just the great papers, but also the middling ones.
And one needs to concentrate on a topic. The thing about a forum such as HackerNews is that for every topic of interest, there's likely a person here who's an expert in the area, but it is easy to confuse that observation with the much stronger claim that there's a person here who's an expert on every topic. The last of those people died in the mid-20th century, if they ever existed.
- jldugger 3y agoI feel like you're giving advice on how to become a PhD student, and frankly, that's not the point of the question, and if it is: any grad student who can't read papers should ask their advisor for advice. So I take OP's perspective to be from a practitioner (such as myself). Apart from my colleagues in R&D, we aren't called upon to write new papers that demands expertise in ever increasing narrowness. Instead we are to solve the needs of the product, usually regardless of specific expertise. So we need to be more broadly equipped, as it's typically better to have a screwdriver and a hammer and a screwdriver in the toolbox than a ten different screwdriver bits of varying niche application. As an example, the TD-IDF paper curated in [1] has been broadly useful as a log analysis tool to surface interesting log lines and remove the mundane common "error" logs. There's been many advancements since then, using bayesian techniques or deep learning, but this one is simple enough and cheap enough to deploy.
- mst 3y agoOld ideas that were good but didn't become common/standard are something I run across a fair bit in papers and yeah, they're often way behind the state of the art but also a lot easier for me to understand/implement and far better than the relatively naive approach I'd've taken otherwise.