Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.fogus.me

Post reply on HN
Print view View original

31–40 of 72 posts

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

#31

Post by zak_mc_kracken »

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…

Good catch.

These are definitely interesting papers, especially to someone like me who has a much stronger interest in programming languages than other (admittedly essential) topics like performance and similar, but this selection is a revealing demonstration that a lot of people who are heavy into functional programming tend to think that FP is the silver bullet of software engineering and that beyond it, there's nothing really interesting worth learning (especially not OOP or other non-FP methodologies).

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

#32

Post by bdamm »

Any list without Shannon's 1948 "A Mathematical Theory of Communication" is just not a good list. Sorry.

http://cm.bell-labs.com/cm/ms/what/shannonday/shannon1948.pd...

The foundation of information theory. It is, by far, the most astonishing paper I have ever read. Far more astonishing than Lamport's famous conclusion about clocks. It is the kind of paper that causes a soul rift when read thoroughly.

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

#33

Post by waterlesscloud »

KevinEldon wrote: post #14

It'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

Wow. That really is a quite revealing comparison.

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

#34

Post by Semiapies »

waterlesscloud wrote: post #33
KevinEldon wrote: post #14

It'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

Wow. That really is a quite revealing comparison.

Part of it might be that this was dropped on a Friday night, US time.

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

#35

Post by theoh »

recursive wrote: post #6
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.

Considering JavaScript makes it difficult to avoid, that's not surprising... And since js is probably one of the common denominators of much activity on the fringes of programming it seems like floating point should be widely discussed.

Unrelated to numeric computing, my favourite thing would be Butler Lampson's Hints for Computer System Design.

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

#36

Post by momo-reina »

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…

Actually I'd argue that there are quite a few things that programmers should have in common, if by programmers we're talking about serious engineers/computer scientis[1] and not "amateur-hour web designers"[2].

Knowledge of the fundamental concepts talked about on that list of papers, and the history therewith, is what allows us to go past the current level of engineering and actually reach greater heights. Most of the emphasis nowadays is spent on knowledge of specific toolchains, frameworks, etc, instead of actually learning WHY and HOW these things work.

From that basic foundation you can then go into any field and learn the semantics, details, and problem-specific techniques to deal with the problems presented. Without that foundation, we're all just floundering around, becoming proficient in using these tools without actually KNOWING how they work and therefore unable to take them to the next level.

[1] - A conversation with Alan Kay https://queue.acm.org/detail.cfm?id=1039523 [2] - JavaScript isn't Scheme http://journal.stuffwithstuff.com/2013/07/18/javascript-isnt...

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

#37

Post by ploxiln »

dvanduzer wrote: post #22
frakkingcylons wrote: post #20

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 hist…

I might call it "sadly" outdated... not that I'm a fan of provably-correct programming (I've never done it, I just fix systems and networking software), but the seemingly modern comfort with buggyness and sloppy implementation... funny or sad, who knows

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

#39

Post by Matumio »

jvreeland wrote: post #11

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.

This is an excellent read, but I disagree with the title. It's a must-read for people interested in CPU architecture and for programmers who, after profiling, still consider doing micro-optimizations. E.g. if you seriously think about reordering your struct members for faster access. If you're building a web service, skip it.

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

#40

Post by sneak »

momo-reina wrote: post #36
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…

Actually I'd argue that there are quite a few things that programmers should have in common, if by programmers we're talking about serious engineers/computer scientis[1] and not "amateur-hour web designers"[2]. Knowledge of the fundamental concepts talked about on that list of papers, and the history therewith, is what allows us to go past the current level of engineering and actually reach greater heights. Most of t…

I started programming seventeen years ago as an "amateur-hour web designer". This sort of attitude is not productive or helpful to our rapidly-growing industry.
Post reply on HN