It's weird that "What every programmer should know about memory" Isn't on here. Even for languages that manage memory for you understanding the hard limitations and basic operations used to access and manipulate memory is certainly useful.
Technical Papers Every Programmer Should Read at Least Twice (2011)
11–20 of 72 posts
Re: Technical Papers Every Programmer Should Read at Least Twice (2011)
#12Eight 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 collapsable directed graph.
Re: Technical Papers Every Programmer Should Read at Least Twice (2011)
#13Eight 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…
Perhaps these 10 are among the greater set of papers that every programmer should read. I will shamelessly plug the IRLS paper on l0 optimization: http://onlinelibrary.wiley.com/doi/10.1002/cpa.20303/abstrac...
might want to check
http://blog.valbonne-consulting.com/2014/06/09/an-incomplete...
Re: Technical Papers Every Programmer Should Read at Least Twice (2011)
#14It's interesting to read the HN comments on this post now and what others have said previously.
https://news.ycombinator.com/item?id=3382962 https://news.ycombinator.com/item?id=2979458
Re: Technical Papers Every Programmer Should Read at Least Twice (2011)
#15Nope, not going to read papers. Scientific papers are full of scientese and I'm allergic. I encountered one recently that used "ambulate" instead of "walk". It is simply insufferable.
It needs to stop. Scientific papers aren't good at communicating in any way - they exist primarily as an intellectual masturbation device where the authors try to max out verbosity*vocabulary. The only reason anyone reads them is that we do not have anything better than this filth.
Yes, I am angry.
Re: Technical Papers Every Programmer Should Read at Least Twice (2011)
#16There 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…
Really the only thing "every programmer" should know is how to efficiently look up information relevant to whatever their current goals are.
Re: Technical Papers Every Programmer Should Read at Least Twice (2011)
#17There 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…
The beauty behind fundamental programming language concepts—which make up the majority of this list—is that they apply to programming in general. They are all widely used abstractions, underpinnings for common technologies or powerful mental tools. Most importantly, they promote a sort of higher-order reasoning and mathematical thinking that's extremely powerful but rarely taught well.
Are these strictly required for anyone? I suppose not. But they would be useful for everyone, and we'd all be better off if everyone had a stronger understanding of these things.
Also, I think finding "should" as demeaning is a bit much. "Should" means that the author thinks the benefits of knowing something outweighs the costs of learning it, nothing more. Pretty reasonable. Doing anything else is reading too much into it.
Re: Technical Papers Every Programmer Should Read at Least Twice (2011)
#18Why this Hoare paper and this Lamport paper? A list of ten is a bit long considering how much background material is required reading for every single entry.
Re: Technical Papers Every Programmer Should Read at Least Twice (2011)
#19Eight 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…
Most of us program, so programming languages is actually a fairly general supporting field for the "computer science" community when other active fields tend to be more specialized. Other general fields include systems and algorithms, which seem to be represented somewhat. In my opinion, none of these papers are must reads, but that is just an opinion :)
Disclaimer, I'm a PL researcher, but I work in a systems group.
Re: Technical Papers Every Programmer Should Read at Least Twice (2011)
#20I 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.