Lambda the Ultimate

I have bought the book after seeing the description here and reading through some chapters.
It's maybe not directly relevant, but I was personally not so enthusiastic about giving the money for the book to charity. I would rather have given money to the open source projects described on the book, the authors, or simply paid less. I think activity in the open source community and helping charity organizations are distinct and I don't like to collide them. I also understand that that may have been the will of the book authors, which I respected by my purchase.

Charity...

... who are then passing on the income to a third party. If you didn't know they were doing this, or what the third party was, how would that affect anything?

I have a hard time believing that all authors, if they had the individual choice of how to use some of the book income, would choose to give exactly this amount of money to exactly this charity organization. I rather assume that the idea comes from some of them, and was naturally accepted by the other (who would refuse?), but would potentially have made something else if given the discretionary choice.

All in all, yes, I would prefer not to know. When you sell me something, you don't need to tell me how you plan to spend the money if it's entirely unrelated. If you tell me, I suppose that's because you think I should be aware of it, because maybe somehow it justifies the price I pay. It's a source of awkwardness when it doesn't.

This is getting really off-topic for LtU.

I read parts of the book and can only say that I was disappointed too. Primarily since the book doesn't deliver what the title promises: a thorough exposition of the architecture of software. Most chapters just discuss a piece of history, an occasional design decision, how to use or configure programs, or the initial assumptions on writing a piece of software. The sole exception, possibly, was by the author of LLVM; but even here I sorely missed some design pictures. I mean, surely software engineering has passed the point that software is loosely described with a few ideas. Where are the package diagrams, library dependency graphs, maybe some UML?

Having said that, I think that Z-Bo is too negative. A book on the architecture of software is a good idea; I am sure a lot of architects are interested in that. Only thing I can say is: Better luck next time.

That was a great chapter. In particular, he referenced external documents as pointers for further reading. He didn't copy and paste his Ph.D. thesis into this book, but instead gave the technical highlights as to why his Ph.D. project ended up being a huge open source and commercial success.

Let's compare with Allman's sendmail:

• No mention of qmail
• Complete refusal to see a common security problem in all of his security examples (ambient authority) and waving his hand at the problem as academically difficult, when it is clearly not; qmail stomps out ambient authority by writing an interpreter that serves as a powerbox for mail functionality
• Good programmers stomp out stupid ideas, including one's they were responsible for. Allman's critique was so incredibly weak he may as well have been Tiger Woods P.R. director for apologizing to his wife.

For Eclipse, there also is very little external references. Because the author positions Eclipse as the be-all end-all of IDEs, it is beneath the author to talk about specific useful subsystems in an IDE, and how the subsystems are integrated. For example, a valid external reference for text editors is The Craft of Textediting, which explains the Emacs everything-is-a-buffer model in detail. There is also the book Inside SharpDevelop which discusses an IDE with a much more narrower focus. Then there is also Practical API Design by the author of NetBeans.

Also for Eclipse, what about how monolithic the development tools currently are and how when people re-use the code, they use monkeypatches using aspect weaving to get Eclipse to talk to their plug-in. Clearly there are some design issues in Eclipse.

I also really hated the chapter on CMake. My summary: "It started off as a way to manage building C/C++ code on multiple platforms, and morphed into this ginormous thing nobody ever imagined. My God, how did this happen? Let me tell you..." If anyone wants to read a book about a great build system, read Software Configuration Management using Vesta. The justification for writing a new build system there is miles beyond what CMake did.

Having said that, I think that Z-Bo is too negative.

I could be much more negative :)

The hard thing, though, is that it is hard to be too negative when people are still alive. As Henry Petroski, author of famous design error and evolution books, points out: The best examples he uses always come from the past, since there is usually political motivation and other reasons for not using fresh examples for criticism. One of his few fresher examples is the Tacoma Narrows Bridge.

My favorite, so far, is the Berkeley DB chapter which, to my mind, is squarely about various aspects of software architecture. I think it is a rehash of stuff the BDB folks have presented elsewhere, before, many times ... but they assembled it nicely and appropriately for this collection. (I guess I'm also biased because I have long thought BDB is truly a great example of good software architecture. I wish I knew and had had a chance to work with people like that.)

Like z-bo, I didn't like the Sendmail chapter but for different reasons. It appeared to have nothing at all to do with software architecture in any useful sense and was instead a hash of many earlier sendmail talks that were mainly about amusing anecdotes signifying the importance of sendmail throughout history.