51–60 of 61 posts
"if [...] you don't know the basics of characters, character sets, encodings, and Unicode, and I catch you, I'm going to punish you by making you peel onions for 6 months in a submarine. I swear I will."
Archived the papers mentioned by fogus and converted the .ps files to .pdf. For those who want quick access to them, download here: http://c.wunki.org/A2s0
I'd like to see Joel Spolsky's epic article on unicode added to the list: http://www.joelonsoftware.com/articles/Unicode.html "if [...] you don't know the basics of characters, character sets, encodings, and Unicode, and I catch you, I'm going to punish you by making you peel onions for 6 months in a submarine. I swear I will."
Meta comment: I find that downvoting people are aren't being rude and abusive is bad manners.
Why? Most of the contents of these papers have made their way into books and programming languages. There's nothing wrong with getting it from a secondary source.
The historian in me is also just fascinated to see the source of an idea that has made a large impact.
The Google Filesystem: http://labs.google.com/papers/gfs.html Great example of what you can design when you decide certain things - like storing small files - are not important.
MapReduce: Simplified Data Processing on Large Clusters: http://research.google.com/archive/mapreduce.html Great example of taking an existing idea and using it to achieve high performance.
The Implementation of the Cilk 5 Multithreaded Language: http://supertech.csail.mit.edu/papers/cilk5.pdf Apple's Grand Central Dispatch uses a lot of ideas from this paper.
I read a random sampling paper recently which took a simple problem and approached it in ways that were much more elegant than I did. Its almost a toy problem but I found the paper really interesting: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.138.7...
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…
I would heartily disagree. As an example, reading about Vector Clocks by Lamport had an immediate effect on how I thought about a real-world problem, and it has stayed with me since. My first reading of "GOTOs considered harmful" led to the phase of my career where I was all about structured programming. (For s perspective, much HLL programming then was in fortran with the three-branch IF-statement.) Admonitions to d…
Actually, I've come to the opposite conclusion recently.
During college, as well as for all of my personal projects, and during the early part of my career, I had the fortune of mostly working on projects for which I was the sole coder from start to finish.
As you say, when you're the only variable in the equation, you eliminate the need for strong debugging skills by following a set of best practices which tends to prevent creation of bugs in the first place.
And then I inherited my first seriously brain-damaged codebase. 16,000 lines of "what not to do". All of my favorite practices listed in the c2 wiki were completely ignored. Massive copy-paste coding. State BOOL's distributed throughout the app making it extremely fragile and tightly coupled. Thread safety? What's that? Hell, they couldn't even avoid giving methods and variables ambiguous names, even in the simplest of cases ("buttonClick". wtf? is that a command (e.g. clickButton) or an event (e.g. buttonClicked)?)
I was wholly unprepared for debugging this monstrosity. My first instinct was to rewrite the whole thing. In fact, a co-worker of mine had attempted exactly that before I was assigned to this beast, but introduced his own set of show-stopping bugs before being pulled off onto another project, ultimately wasting two weeks of work (his branch was abandoned) and souring the waters for any such attempt on my part.
For several months I forced myself to avoid the urge to rewrite, and just slogged through it until I finally started to understand what was going on.
I have to say, forcing myself to continue to chew on something sour when every instinct told me to spit it out really improved my ability to follow what was happening in a foreign codebase. Now, even when bughunting relatively sane codebases, I feel I'm more quickly able to zero in on the problem.
What would be useful is a site that collects links to CS papers, then for each paper lets users (who presumably actually read that paper) comment on it, and/or rate it. Or does such a beast already exist?
Mendeley [1] does some of what you're talking about. Primarily it's a way to organize your own collection of papers and access them from native or web apps on various devices. It also has some social features, like connecting users with similar interests and sharing tags on papers. Its "Computer and Information Science" category [2] lists the papers with the most "readers" which I think in this case means "Mendeley u…