I know it's the author's thing, but I've really grown to hate the pictures of food in his articles. I might feel differently if it were done well, but there needs to be more of a reason to include a picture of food than simply wanting a visual break in the article.
Yes, it really is that simple. I am preoccupied by food in general and sushi in particular. Sorry that there is no deeper, allegorical reason for the pictures.
I adblock the images in your articles because I find them highly distracting and slightly repulsive (I'm not a fan of sushi). I did so the first time your articles came up here on HN (and I remarked upon it then), and I had to do so again yesterday, as I've had a new machine since then.
I'm 80/20 vegan/vegetarian so I should feel especially repulsed (I don't; got a real time mind filter in place for that - using it on online ads as well - very simple & effective solution) but still one has got to admire your jolly reaction to all the sushi hate here. A very sympathetic (insular?) trait, keep those interesting blog posts coming!
I think the sushi breaks are great (and hilarious), and help create a personal "brand" for the blog.
They anchor his previous blog posts in my mind. When I stumble upon a new reprog article on HN, I remember his previous articles ("oh, this is the sushi blog!").
I think the most valuable parts of this book for me were the stories that involved solving problems within constraints. If you work with a large enough dataset or management that won't allow you to buy the hardware to just make your problems go away constraints are still a big part of software development.
That one is a quote from Ken Thompson, the inventor of (among much else), Unix and UTF-8. It is quoted in _Programming Pearls_, though -- I think, in the sequel rather than the original.
As noted, a quotation from Ken Thompson. It appears in the chapter "Bumper Sticker Computer Science" in _More Programming Pearls" along with many other fine aphorisms.
As brilliant as the algorithms listed in the book are, I find them less and less interesting in and out of themselves nowadays. Those data structures and search algorithms have really become basics. I just don't understand why people still blindly worship this book and the way it was and are still trying to replicate it during interviews. If you want to test a developer, don't force them to do bitwise manipulations in C. Why not step up a bit further and try to ask them to apply those data structures and algorithms into a server cluster or a server cloud and see how they come up with a solution. That is more likely the case they will encounter nowadays.
All right, enough of rants. Here is my take on this book. This is one of my favorite books. Great things like this book, in the same way as Unix, C and other oldies, can last for a really long time. One thing of the book that intrigued me was the way those old great hackers managed to conquer seemingly impossible problems, despite the severe constraints such as limited memory space, in a extremely resourceful manner. The bit sort in chapter one and the chapter how Ken Thompson squeezed storage space for his chess program are two of my favorite read. The other thing I think may be even more useful is the back of the envelope estimation, which encourages out of the box thinking or street smart (though those kinds of questions got abused and became notorious in technical interviews).
Constraints still exist as we begin to attack harder and bigger problems, such as "web-scale" applications. New metrics for the back of the envelope estimation came into beings such as network latency, database queries. I really hope someone of our times can come up with a similar book in the same spirit, but addressing the issues we face nowadays.
"I cannot describe the excitement I felt when my
own first article "Multidimensional Binary Search
Trees Used for Associative Searching" was published
in September 1975. It received second place in the
1975 Forsythe Student Paper Competition. Back
then, original research papers were viewed as within
the reach of undergraduate students (truth be told, I
tied with a high school student) and of interest to the
general ACM community. I wrote my paper (under the guidance of Donald Knuth) explicitly for the
Competition; had it not existed, I would not have
written it. It remains to this day my most cited
research paper. (And because I’m sure that your
inquiring mind wants to know, I’ll point out that first
place went to a lad by the name of Guy Steele, who
I’m betting turned out okay."
This excerpt is from his most recent article on acm, "In the realm of insight and creativity".
Bentley's book "Writing Efficient Programs" is also really super. Unfortunately, it's been out of print for a long time. If you ever see it, snap it up.
When I interviewed at Microsoft, they recommended reading this book -- I doubt it helped at all, but it's a great read (as is the sequel) if you haven't read it.
There's a real sense of history too, some of the problems illustrate how far we've come: like talking about transferring a whole megabyte several miles as a challenge.
I love this book. I have it next to my bed and read in there from time to time before I fall asleep. Makes you dream up great algorithms (at least I try to belief that ;)
I, by pure luck alone, happened across this book early in my career, and I still go over it from time to time. I will probably die with it in my "keep forever" library.
Ha! Me too! I asked a librarian at my university to fetch me "whatever they had on Perl" (this was my first incursion into the interpreted language world) and the librarian came back to me with this. Imagine my surprise when I started reading the book over the weekend (only then I noticed the title said 'Pearls' not 'Perl').
Forward 10 years, I have a copy in my bookshelf and read a chapter every now and then just to keep myself real. I've completely (and happily) forgotten everything about Perl though.
whenever I'd seen this book mentioned in 'best programming books' lists, on Stack Overflow and the like I'd figured it was a cutely named book to do with Perl and skipped over it.
