Computer science research papers are funny things. On the one hand, there's all sorts of interesting stuff in them. And on the other it almost doesn't matter because the stuff just isn't accessible.
I found this out when I was doing research for Parrot, where a lot of the interesting things were done in Lisp, a language that, to a first approximation, nobody knows or cares about. I'm finding it again as I do research for Tornado where the interesting things are done in Haskell, again a language that, to a first approximation, nobody knows or cares about.
This, I think, is sad. Not that nobody cares about Lisp or Haskell (languages have to rise and fall on their own merits, and since it's all syntax I only have a limited interest in it) but rather because the relative obscurity of the languages being used makes it all that much more difficult to get some of these concepts in more wide-spread use.
As an example, take transactional memory. This is a really powerful concept that allows you to avoid a whole range of nasty problems when writing multithreaded code -- there's no worry about deadlocks or priority inversions, and in the common case where there's reading but not writing of global data it's much more performant. The problem is that most of the papers on STM express the code in Haskell with corresponding text that is written academically.
The problem is that if you don't read academic-speak (and most people don't) and don't read Haskell (which, again, most people don't) then you're just SOL. Granted, I'm not sure in practical terms it matters much for low-level constructs since most programmers aren't going to go implement things themselves, but still... for those of us who do want to implement this sort of thing it's a big pain.
More importantly, I think it makes it more difficult to recruit more people to write this sort of low-level code. Yes, it's tricky, but it's hardly rocket science. As we found with Parrot, most clever and willing programmers could do these low-level things but didn't because they were scared of them -- as an example, garbage collection terrified folks even though it just wasn't that tough. The problem was that all the literature was, bluntly, inaccessible.
So, I guess this is my complaint, or possibly my plea -- if you're writing papers about new things, by all means do your test implementation in whatever language you want, but when you write the paper? Use a language people actually know, dammit, even if you have to fake it.
Clever new things don't do anyone any good if nobody can understand the damn things. And when people don't understand them it's your failure as an author, not theirs as a reader, so... be understandable, even if you feel like you have to stoop. In the long run it'll be a lot more useful.
By far, the most important phrase that's not in the english language is mise en place.
Never underestimate the importance of flavored seltzer water. When surrounded by sugar and fat you're going to eat something, and best it's not something too calorie dense.
Heavy cream should always be bought in gallon quantities. Multiple gallon quantities...
There is no such thing as too much food when cooking for an organization of any size. There are, in fact, only three quantity categories: not enough, could have made some more, and the Mailroom says thanks for the goodies.
Always be nice to the Mailroom...
The big O for these things is O(N ln B) where N is the number of recipes and B is the number of batches being made. That is, doing one batch each of five recipes is O(5 ln 5) but doing five batches of one recipe is O(1 ln 5). This is important to remember when planning out how much can be done before collapse...
When cooking for members of the legal profession, the phrase "too much alcohol" is only valid in the technical sense. That is, the statement there is too much alcohol for the gelatin to set is meaningful, while the statement there is too much whiskey in this pie, nobody will like it is entirely nonsensical.
when you come across the phrase "when the heap fits in main memory" and you realize that the alternate case is ignorable -- swapping is such a catastrophic failure all by itself it doesn't matter how an algorithm or technique performs when that happens.