Live data from Hacker News

Technical Papers Every Programmer Should Read (At Least Twice)

blog.fogus.me

21–30 of 61 posts

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

#21

Earlier quoted context omitted.

The algorithm for the simplest variant of that problem (take a single random sample from a list of a priori unknown length) can be derived by simple inductive reasoning. If the list has size 1, the problem is trivially solved. Otherwise suppose we have a list (x:xs) and we recursively solve the problem for xs. If all the recursion returns is the random sample from xs, we clearly have insufficient information to take…

>Then the result for (x:xs) is (r, n) where n = n' + 1 and r = x with probability 1/n or else r'. Do you mean r = x:r' instead of r = x?

No, r has the same type as x. The logic behind that probability split is simple: We have r' (the random sample taken from the tail list xs) and x, and we have to choose between them with some probability based on n. Clearly x should occur with a 1 in n chance.

When you approach it inductively the way I did, there really isn't any choice in the matter, which is why this algorithm design technique is so powerful. Udi Manber developed the technique in his paper Using Induction to Design Algorithms from 1988 and later used it throughout his great old book Introduction to Algorithms: A Creative Approach from the early 1990s. Here's the paper in case you're curious: http://akira.ruc.dk/~keld/teaching/algoritmedesign_f05/Artik...

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

#24
post #18

I don't mean to speak badly of this bibliography. Of the papers in the list I've read, they're all great. And I'll add the others to my list and make sure I get to them. But I think the premise of the blog post is a little flawed. Reading papers is a poor way to make yourself a better programmer. Read them in spare moments, sure, but spend your time reading code , not paper. At best, these things will help you avoid…

    but spend your time reading code, not paper.
These things are not mutually exclusive. I agree that you should definitely read code also; good and bad. However, this is a post about one specific thing: great papers.

    Admonitions
That's a bit strong. I listed some papers that I like and believe important. I don't recall providing admonitions if you didn't read them.

    re-read "Out of the Tar Pit" every six 
    months is just bad advice to my mind.
That's just me. I like that paper and so I re-read it. I wouldn't say that you nor anyone else should do the same.

    It's a good way to convince yourself 
    you're smarter than everyone else.
I'm sorry, have we met?

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

#25
post #9
post #5

Earlier quoted context omitted.

Sorry. My Markdown syntax was bad. There are now links to the articles marked by ↗.

Can't find the link for "Organizing Programs Without Classes". The Oracle site says "click here to download", but there is nothing to click?

PDF: http://selflanguage.org/_static/published/organizing-program...

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

#26
post #9
post #5

Earlier quoted context omitted.

Sorry. My Markdown syntax was bad. There are now links to the articles marked by ↗.

Can't find the link for "Organizing Programs Without Classes". The Oracle site says "click here to download", but there is nothing to click?

here is link to ps.gz.

And you can find PDF at http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.127.5...

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

#27
post #13
post #5

Earlier quoted context omitted.

Sorry. My Markdown syntax was bad. There are now links to the articles marked by ↗.

This is a great collection of papers, and I don't mean to downplay how happy I am to find it, but you might want to use a linking method that's more obvious, like having relevant text be blue and underlined. The principle of least surprise is important, usually more important than cleverness in design. (Now I'm going to go off and read that Lamport paper.)

[deleted]

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

#28
post #27
post #13

Earlier quoted context omitted.

This is a great collection of papers, and I don't mean to downplay how happy I am to find it, but you might want to use a linking method that's more obvious, like having relevant text be blue and underlined. The principle of least surprise is important, usually more important than cleverness in design. (Now I'm going to go off and read that Lamport paper.)

[deleted]

"link to paper" comes to mind...

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

#30

Earlier quoted context omitted.

>Then the result for (x:xs) is (r, n) where n = n' + 1 and r = x with probability 1/n or else r'. Do you mean r = x:r' instead of r = x?

No, r has the same type as x. The logic behind that probability split is simple: We have r' (the random sample taken from the tail list xs) and x, and we have to choose between them with some probability based on n. Clearly x should occur with a 1 in n chance. When you approach it inductively the way I did, there really isn't any choice in the matter, which is why this algorithm design technique is so powerful. Udi M…

Whoops, I misinterpreted what you meant by "single random sample". I will definitely check out that paper though.
Post reply on HN