Forum Chat


Mar23,13:31 Johan Marechal
Wees gegroet
Sep20,17:50 Vicente Duque
Kim, Martin, Others :...
Jul07,11:10 Johan Marechal
PGP 9
Jul05,21:13 martin
Fastest in the bush
Jul05,07:48 martin
Spamdexing
Jun28,21:16 martin
New domain / new blog!
Jun28,21:11 martin
On posting etiquette
Book Reviews: General

The Best of Verity Stob

February 18, 2005
Verity Stob, APress 2005
The book is a collection of columns from over the years. They're satirical prose, poems and similar. Verity is mainly a C++ programmer with a healthy low esteem for Visual Basic programmers and other visual dragondroppers. She's not much into software engineering as a discipline in itself, that's obvious. Anyway, read this for the jokes and the style, but if you've been in the software industry less than 20 years or you've never advanced much beyond VB, Access and Delphi, you're not going to get many of the jokes. Worse (better?), you'll be (rightfully?) insulted along the way. In that case, take it as a hint that you've got a way to go. (No comments yet)

The Pragmatic Programmer

November 04, 2004
Hunt - Thomas, Addison-Wesley 2000
It's very much in the style of "Coder to Developer", intended for the lone, or almost lone, programmer. Much wisdom is imparted, chiefly in the form of desirable attitudes to programming. Again, as in many such books, if you don't have the attitude already, I think a lot of it passes you by. You just imagine how much good this book would do other people without the Right Attitudes, but I wonder if they'd ever read the book voluntarily. Or if it would work on them, even if they were force-fed the wisdom. Actually, this book is more like a biography of the authors, and very interesting as such. "Coder to Developer" contains more down to earth advice on products than "The Pragmatic Programmer" does.

Maybe I simply missed the point of this book, who knows. But I didn't find anything in it I disagreed with, so maybe I'm simply not a member of the intended audience of the book. A little light introspection didn't come up with any improvements of my character that must be due to having read the book (even though I'm sure I could use some). (No comments yet)

Hackers & Painters

October 21, 2004
Paul Graham, O'Reilly 2004
I expected this book to contain a lot of the very satisfying and glorious descriptions of hackers as misunderstood geniuses, much deserving of freedom, high salaries, admiration and tech toys. He does write stuff like that, normally. So I was prepared for a cozy and smug read. But no, it's not about that at all, but mostly about what languages that the smart people use and it turns out it wasn't the languages I use at all! Horror! Not only that, but the real jerks, according to PG, are people that make disparaging remarks about how Lisp has too many parentheses. That does remind me of my own review of Sussmans book... OMG! I like this guy, but he doesn't like me, how can this be? You know (or should know) that I'm always right. Now I claim I was, just maybe, wrong, so I'm right again. Right? Actually, I'm beginning to suspect that PG has enough of a case to investigate his claims at the very minimum. He claims Lisp is a miracle cure and that Python isn't far behind. He doesn't mention APL, even though I know it to be extremely productive in the right hands. In short, he got me thinking, but there's still a caveat: it's obvious he has only worked on heroic projects and not on any projects that can actually and really use structured languages like C++. But still, PG is on to something, I'm sure. (No comments yet)

Coder to Developer

May 24, 2004
Mike Gunderloy, Sybex 2004
You can regard this book as the project management book for lone developers. It largely discusses what practices and tools the lone developer can and should use. It even goes into specifics about different products, gives you links to sites and estimates of prices. In other words, an eminently useful little book. (No comments yet)

Programming Pearls 2nd ed., Jon Bentley

May 20, 2004
Addison-Wesley, 2000
It's referenced everywhere; almost every other author mentions it, so I did order it at last. I have to admit it's true; it's really worth it. Small, but tough, book that is all about algorithms, or rather, how to think about algorithms so you can invent them yourself. ( Added 7/2003) (1 comment)
 
 
(martin)
November 04, 2004
 Now get this: I've read this book three times already, and I'm planning on reading it another couple of times. It always brings home yet one more point at a minimum, every time I read it. And it always brings me back to The Righteous Path, as I tend to stray. It grows on you. I really can't recommend it enough.

Modern Compiler Design, Grune et.al.

May 20, 2004
Wiley, 2000
Up until now, there were two books on compiling I kept coming back to: the "dragon book" and Ronald Mak's "Writing Compilers & Interpreters". Each time I do my DFA's and NFA's and DAG's and stuff in the dragon book and give up feeling like a total idiot. Then I go for Mak's book and get real practical. After Mak everything works. In one particular way and usually almost good enough. Now Grune's book is somewhere between these two. Much more practical than the dragon book but still totally useless in practice. At least for me. It's certainly worth reading, though, since you really do pick up things here and there. But if you need to write a recursive descent parser in a hurry, do go for Mak and be done with it. If you want to know what else exists in this world, then possibly go for Grune. ( Added 1/2002) (No comments yet)

Writing Compilers & Interpreters, Ronald Mak

May 20, 2004
Wiley, 1991
This book is divided into "Scanning and parsing", "Interpreting" and "Compiling". You want to know how to "Scan", go to chapter 2 "Scanning" and by jove, you'll know how to scan. Exact code examples, actually working, are there right before your watery eyes. Everything is in C (there was no C++ yet). Symbol table? Chapter 3. Etc. It's so darn practical, it's amazing. I've used this book for several projects and it's always been a great help. Recommended. This book is out of print, but it seems there's a new book by Ronald Mak from 1996 and from the description I gather it's the same one reworked in C++. I don't have it, but the links here are for that new book. ( Added 1/2002) (1 comment)
 
 
2nd edition (martin)
May 24, 2004
 Now I do have it, the second edition. I've only browsed it so far, since this is the type of book you grab when you need it. That is, once you've read it, you don't read it again, even though it's a new edition. But since I'm so used to the first edition, and it's only about half as big as this one (which is really big), I think I'll probably go for the first edition in a pinch anyway. I put the picture of the second edition into the description above, by the way.

Compilers, Aho - Sehti - Ullman

May 20, 2004
Addison-Wesley, 1986
This one is hard to describe except by its cover (the cover illustration is what gave it its "dragon book" name). I think it's one of the first really formal treatments of compiler design. It's exhaustive, exhausting and interesting. I think you really should read it, but I can't tell you why you should. Except it's generally good for the purity of your soul. I read it ten years ago or so, and my soul has been very pure ever since. ( Added 1/2002) (No comments yet)

The Art of Computer Programming Vol I, II and III

May 20, 2004
Knuth, Addison-Wesley, 1973
One of the real original works on computer science. This is still the place to go look for algorithms like balanced trees and quicksort. It's also very good for you to cite something from Knuth when you write an article about anything computer science like. Knuth has reworked all the volumes and I think even added a fourth volume to the set in the meanwhile, but I haven't ordered any of those. For the price, I don't think they'd contribute enough to warrant it. If you can't read the spines, these are the volume names: Fundamental Algorithms, Seminumerical Algorithms and Sorting and Searching. 7/2000 (No comments yet)

Data Structures and Problem Solving Using C++, 2nd ed.,

May 20, 2004
Mark-Allen-Weiss, Addison-Wesley, 2000
Not bad at all. But it's a schoolbook, that's obvious. All the exercises at the end of the chapters is a dead giveaway. And it uses all the old schoolbook examples. It does give you a smooth intro into current C++ STL usage, though. But I must admit it didn't much exite me or teach me anything I didn't know. Except a few things I don't really need to know, actually. (2/2001) (No comments yet)

Structure and Interpretation of Computer Programs, 2nd ed.

May 20, 2004
Abelson-Sussman-Sussman, MIT Press, 1996
Oh my gawd! There's these people I know and respect that keep telling me Lisp and Scheme are so great you can do anything with them, absolutely totally cool everything. Then I try very hard to get through this book by very famous people and the only message I get is that parenthesis are highly beloved in academia. There's this smug undertone of how great we are and how cute those expressions are and all I see are totally illegible syntax with ass-backwards operators. Meanwhile, I'm totally convinced you can rebalance a B+ tree in one parenthesis-ridden line less than two miles long in Scheme, but I still don't know why you'd want to do such a thing. It's right there in the STL, no? And pray tell me, anyone, how all those tail recursions are going to help me write stateless objects under MTS, tight network wire packages and interthread messaging objects. Not to mention decent user interface validation code. Programming today, at least as I see it, is knowing API's, system architecture, operating system strengths and weaknesses, object libraries, not how to make an algorithm just-so for the next staff presentation. Don't get me wrong; getting the basic algorithms right is the most important thing in most computer programming projects. That's why we use the STL. (2/2001) (3 comments)
 
 
(martin)
October 18, 2004
 I have a strong feeling I'm going to have to eat shit because of my comments on this book. I think I may actually have been an ignorant twit. But I'll leave it there as a terse reminder to myself that I can be judgemental and wrong. Since it's so rare, I'll preserve this example for historians. So, all you others out there, don't take this as an excuse to doubt my general perfection, however. (For the story on exactly how this embarrassing change of heart happened, you have to have a little patience. Another book review is coming up. Once I've gathered the courage for it.)

 
 
(martin)
November 04, 2004
 Ho ho... they're not making it easy to like them... now I know what pissed me off so badly the first time. Just listen to what they say after explaining how a tail-recursion doesn't use up the stack in Scheme (page 35)... "One reason that the distinction between process and procedure may be confusing is that most implementations of common languages (including Ada, Pascal, and C) are designed in such a way that the interpretation of any recursive procedure consumes an amount of memory that grows with the number of procedure calls, even when the process described is, in principle, iterative. As a consequence, these languages can describe iterative processes only by resorting to special-purpose "looping constructs" such as do, repeat, until, for and while. The implementation of Scheme we shall consider in chapter 5 does not share this defect." Excuse my face, but to me, the above paragraph reeks of snotty arrogance that isn't in the least motivated by reality. The looping constructs aren't a quick fix invented by inferior minds to avoid having to figure out tail recursion elimination. Also, the tail recursion optimization has been part of many languages before Scheme even existed. Such inflammatory bull has no place in a text for undergraduates, since it stuffs this idiotic attitude into (presumably) receptive minds. But, I made a promise, so I'll hold my nose and work myself through this book. At whatever cost, only hoping I'm not getting a myocardial in the process.

 
 
(nevelsteen)
November 04, 2004
 Self inflicted torture? I didn't know you had it in you.

Machine Learning, Mitchell

May 20, 2004
McGraw-Hill 1997
New book.(Added 10/2000). I tried, I really did, to read this one. The first ten or twenty pages were fairly painfree and then I ran into a really tough definition of general boundary G (and a very similar of the specific boundary S). I'd love to stick those two mathematically formulated definitions into this page, but I'd probably have to go out and buy some equation formatting software for it. I'm no idiot (usually) but those definitions had me on my knees, with my face slowly approaching the floor. Until I realized that without mathematical language, you could state both definitions in plain language in one brief sentence. Exactly which sentence, I've forgotten, of course. Why the pain? So, stuff it. Only machines can learn from this book. (1/2002) (No comments yet)

Neural Networks for Pattern Recognition, Bishop

May 20, 2004
Oxford 1994
New book.(Added october 2000)

(11/2002): Hmmm.... I think I gave it away to somebody. (No comments yet)

Reinforcement Learning, Sutton-Barto

May 20, 2004
MIT Press 1998
New book.(Added october 2000)

(11/2002): Hmmm.... I think I gave it away to somebody. (No comments yet)
TOP