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

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 relevant.

I just wish we'd stop with 'all X should' titles. Its demeaning and inaccurate.

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

#5

Post by jcr » Sat, Dec 20, 2014, 1:48 AM UTC

ashish01 wrote: post #3

Can some please do a similar list for machine learning and also for maths relevant to ML?

Machine Learning is a fast moving field, and many papers are incremental improvements, so an always up-to-date list will be unlikely. None the less, there are quite a few lists out there if you look. Here are some I've seen posted recently:

https://news.ycombinator.com/item?id=8728112

http://deeplearning.stanford.edu/wiki/index.php/UFLDL_Recomm...

http://www.cs.toronto.edu/~hinton/deeprefs.html

http://arxiv.org/abs/1404.7828

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

#6

Post by recursive » Sat, Dec 20, 2014, 1:53 AM UTC

platz wrote: 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…

Floating point behavior still represents a significant portion of new questions asked on stack overflow. I'd say it's still very relevant.

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

#7

Post by notacoward » Sat, Dec 20, 2014, 1:56 AM UTC

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 own list. Maybe I will. Nonetheless, the author specifically mentions "cover a wide-range of topics" as a goal and this list fails to meet that goal.

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

#8

Post by kelukelugames » Sat, Dec 20, 2014, 2:00 AM UTC

platz wrote: 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…

"X all Y should" is a clickbait title prohibited by HN.

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

#9

Post by dj-wonk » Sat, Dec 20, 2014, 2:01 AM UTC

platz wrote: 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…

> There is very little all programmers should be required to have in common.

We don't need to say "all must know X things" in order to convey a notion of a well-rounded programmer. Of course we don't have to agree. Still, generally speaking, I think the bare minimum is this: the ability to solve your problems with the languages and tools you know in a reasonable amount of time.

But that doesn't say much, so any list needs to get more specific:

* ability to use your tools * ability to decompose a problem * ability to debug a problem * ability to communicate intent via code * ability to communicate intent via language

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

#10

Post by frozenport » Sat, Dec 20, 2014, 2:06 AM UTC

notacoward wrote: post #7

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…

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...