Lambda the Ultimate

I have already attempted to secure a copy from Barnes & Nobel, only to discover that despite The MIT Press listing of the text as a November 2004 title, it has not yet in fact shipped.

However, there are some PDF excerpts available on the companion website.

Firstly, I have to say I heartily agree with some of the statements of the authors. I've always considered knowledge of a general-purpose assembly language one of the requisites for calling oneself a "programmer". Learning assembly usually does involve machine architecture and compiler aspects, e.g. the AoA.

A relatively recent online resource for the pre-NAND part (though it doesn't go into logic gates) is Designing Analog Chips.

I browsed the powerpoint, the software, and a few of the chapters online. The material is easy to follow if you already learned it, but otherwise it looks hopeless.

Maybe a brilliant kid with recreational programming experience could work through it, falling back on Google for help on parsing (the book sure doesn't explain it), but otherwise, it seems like it's only a satisfying recapitulation to be presented at the end of an undergraduate CS/EE program.

I do really admire the approach.

Judging from the slides this book tries to be everything, and succeeds being nothing at all.

Two years at the university brought me the same knowledge they are teaching, but because it was spread out among different classes, and because we could use the best books in each area, every topic had somewhat higher quality.

Replace the hardware part with Hennessy&Patterson, the programming language part with a Scheme book, compilers with the Appel book, the high level part with any software engineering course.

As it is, I see no reason at all why anyone should read this book, and several why one shouldn't (like the OO language as the end-all of software engineering; even SE classes allow to discuss their concepts without OO sometimes, or see Szyperski's Component Software).

I've wished for courses much like this book that start at the bottom and work their way up to a certain goal. For example, I have great interest in tiling. I wish wikipedia articles had something like debian package dependencies, "tiling depends on group theory" "tiling is required by quasi-tiling".

Tiling led me to penrose tiles, then to group theory, now I have related questions that I don't know how to ask, because I don't know the answers to "what else depends on group theory?" or "what else requires tiling?"

If wikipedia artictles had such dependencies, it would easy to build a course that connected any two nodes.
Interesting courses that come to mind are, "Binary, Trinary, and Analog - How the Cold War Influenced the Computer Architecture of Today." , "Unicycles as Physical Analogs of Linear Logic, an overview of the works of Henry Baker" or possibly "Libraries, a crutch for insufficiently expressive programming languages? Provocative ideas from Discordian Theoreticians."

Though maybe that last one is a bit too radical.

In any case, are there more examples of this top to bottom coverage of a subject?

--Shae Erisson - ScannedInAvian.com

I don't have the time for a complete review at the moment, but here are a couple of observations.

The book is quite impressive. It is accompanied by huge amounts of support code and tools, that enable its hands-on, laboratory, approach.

The authors draw attention to basic software engineering concepts from the very beginning (e.g., interfaces vs. implementation, unit testing, modularity).

The programming language that is built during the course, called Jack, isn't state of the art (and as we know, it is possible to build a Scheme interpreter, which LtU readers would have preferred over the object-based language in the book). The authors are wise enough to provide a section explaining their design choices (sec. 9.4), in which they write Jack is an "object-based" language, meaning that is supports objects and classes, but not inheritance... [Jack's] primitive type system is, well, rather primitive... it is s weakly typed language... all these deviations from normal programming languages were introduced into Jack with one purpose: to allow the development of elegant and simple Jack compilers...

You may disagree with the choices the authors made, but at least they are explicit about them and mention that there are alternatives.

I gave the book to a friend of mine, now finishing his MSc. He was very enthusiastic and said that the book gives a very nice integrated picture of many important topics.

I've been following the discussion of our book (www.idc.ac.il/tecs) in this blog with a mix of pain and amusement. In particular I am rather impressed by the ability of some of the contributors to form extremely solid opinions about a book that they've never seen (by their own cheerful admission).

Noam Nisan and I spent 5 years writing the book and related software. Please spend 5 minutes looking *at the actual text* before writing the next post about it.

If one of you is seriously interested in writing a book review I will gladly send him/her a copy. Let me know at shimon@idc.ac.il .

-- Shimon

FYI, the author made a presentation at Google, which is available online:
http://video.google.com/videoplay?docid=7654043762021156507