Live data from Hacker News

Technical Papers Every Programmer Should Read at Least Twice (2011)

blog.fogus.me

21–30 of 72 posts

Re: Technical Papers Every Programmer Should Read at Least Twice (2011)

#21
post #12

Eight out of ten are about programming languages, and strong on the functional side to boot. It's not that these topics aren't important, or that they're not great papers, but isn't that a bit too heavily skewed toward one area? Shouldn't at least one of those top ten be more directly about security, or performance, or some other kind of idea rather than the notation we use to express ideas? Yeah, I know, make your o…

Yes, there is an emphasis (and bias!) towards functional languages and distributed systems. Yes, Fogus' intent is to raise awareness of these concepts. Yes, other people would have different lists. Yes, the list could have more breadth. Personally, I'd like to see a concept map of essential computer science topics combined with some of the top papers and books that cover each. It could be implemented as a curated col…

> Personally, I'd like to see a concept map of essential computer science topics combined with some of the top papers and books that cover each. It could be implemented as a curated collapsable directed graph.

I've tried building one of these before, both for CS and for Maths. Funnily enough formatting, displaying and making it accessible (whilst retaining enough data) was the time-consuming issue, despite all the tech around for handling graphs. :/

Re: Technical Papers Every Programmer Should Read at Least Twice (2011)

#22

I think Communicating Sequential Processes [0] by Hoare is another landmark paper that should be on this list for its perspective on organizing concurrent processes. This was actually required reading for the concurrency section of my undergrad operating systems course. [0]: https://www.cs.cmu.edu/~crary/819-f09/Hoare78.pdf

"The practice of supplying proofs for nontrivial programs will not become widespread until considerably more powerful proof techniques become available, and even then will not be easy. But the practical advantages of program proving will eventually outweigh the difficulties, in view of the increasing costs of programming error."

The Hoare paper actually linked is hopelessly outdated, despite being an interesting historical artifact.

Re: Technical Papers Every Programmer Should Read at Least Twice (2011)

#27
#oly $#it! I have read these papers, all of'm! WHAT! Haha that is so accurate LOL!

Great stuff! But there are way more important whitepapers to be honest. I can't really think of the others right now, but if you go to the Digital library from ACM / IEEE, you can find really good stuff.

Re: Technical Papers Every Programmer Should Read at Least Twice (2011)

#28
tormeh said: Nope, not going to read papers. Scientific papers are full of scientese and I'm allergic.

And got downvoted to hell for it. Which is too bad, because its worth discussing. There _is_ a lot of bad writing and intellectual masturbation in academic publications.

There is also a lot of good writing. In particular, I find Lamport's writing to be prosaic and easy to follow.

Re: Technical Papers Every Programmer Should Read at Least Twice (2011)

#29
post #4

There is very little all programmers should be required to have in common. The field is just that big now. 9 times out of 10 a list like this includes a treatise on floating point number representation, which while useful, probably isn't of utmost importance in the 21st century, but hey, at one time folks thought that was required for 'all programmers' to read. At least this list does seem more up to date and relevan…

A few years ago when there was a wave of books titled "1000 ____s to ____ Before You Die," I really wished I'd been in a position to get a book published called "Never Mind The 1000 Things, Just Die."
Post reply on HN