Customer Reviews

Advanced Programming Language Design

5 star:		(2)
4 star:		(0)
3 star:		(0)
2 star:		(0)
1 star:		(2)

 

 

This is a wonderful book that covers tons of languages, including several that are far from the mainstream. The author demonstrates a very strong knowledge of all concepts discussed in the book, and wording is very clear and concise. This is an excellent book for undergradute or graduate courses on programming languages.

This book is awful! There is nothing positive I can say about it. It is also thirteen years old and very out of date.

The book purports to be "modern," but among the more than seventy languages Finkel discusses are many that have fallen into disuse, or have never been implemented, or were only implemented as academic curiosities. At the end of Chapter 1 on Page 28 he says, "The language concepts introduced here are in some sense classical Algol-like structures. They are developed in various directions in the following chapters ..." Much of the book emphasizes non-imperative languages. That may be fine for those in an academic environment looking to do research, but be aware that it has little to do with what most programmers do for a living. Besides Algol, most of the book is based on Ada, APL, CLU, Fortran, LISP, ML, Modula, Pascal, Prolog, Smalltalk, Tcl, and about sixty other mostly obscure languages. He talks a lot about Pascal and ML as if they were recent cutting-edge languages. He does talk quite a bit about C++, but never mentions Java.

The book reads like a dissertation or collection of journal articles sometimes referring to topics that have not yet been covered or that will never be covered in the book. If you are a self-motivated learner, you will have difficulty, as I did, getting through Chapter 1, that supposedly reiterates what you should already know to prepare you for the rest of the book. Chapter 9 on aggregates, patterns, and database languages about which I consider myself knowledgeable, was rendered in such a confusing manner, that I could hardly make heads or tails of it. The author has little gift for teaching. He himself says on Page 114, "...an elegant program is one that is readable the first time by a novice, not one that plays unexpected tricks." None of the hundreds of code samples and snippets are "elegant," and many are indecipherable even after reading four or five times. His writing style, while attempting to be conversational, jumps to conclusions without the intervening logic. For example, he mentions "cons" on Page 87, "cdr" on Page 124, and "car" on Page 127. Then, on Page 277 he says, "Predicates specifying car and cdr are easy. ..." and gives the following two formulas without explaining what they mean.
car(cons(H,T),T) :- isList(T) .
cdr(cons(H,T),T) :- isList(T) .

The syntax Finkel uses for example code throughout the book is inconsistent. On Page xiii he says, "I have invented what I hope will be clear notation. It is derived largely from Ada and some of its predecessors." However, he never describes his syntax and semantics, so it appears to be a hodge-podge that is not clear at all. Not all terms that he uses are in the glossary or the index, and often terms are used without prior explanation. Symbols are not in any table or appendix; there is no guide to meaning or pronunciation, and none are listed in the index.

He uses the same syntax at different times with different meanings or different syntax at other times for the same meaning. Following are some examples: Type identifiers are ordinary identifiers prefixed by one or more tic marks (single quotes). Sometimes he uses the familiar C-language asterisk * prefix dereferencing operator, while at other times he uses the caret ^ postfix dereferencing operator. Sometimes the caret ^ is a binary exponentiation operator, but sometimes stands alone at the head of a statement. An asterisk * can be a type constructor, a binary multiplication operator, or it can mean "choose a type from each operand." Comma can be a list separator or a tuple constructor. Tilde ~ can be a deconstructor prefix or a binary operator. Null and nil have different meanings depending on context. There are a lot of single colons, double colons, hyphens, and equal signs in various combinations ( :, :-, :=, =:, ::, ::=, ::==) as well as various kinds of arrows (<, >, ->, <-, =>, =<, <=, >=) and parentheses(), square brackets[], and curly braces{} with various levels of nesting. Many have very different meanings than what you would assume. There are Greek letters, alpha, beta, epsilon, lambda (for lambda calculus), and nu. There are set theory symbols such as the upside-down capitals A, T, U, and V as well as circles with plus or x inside.

There is no consolidated syntax reference. Some terms or symbols have definitions or explanations embedded in and scattered throughout the 420 pages of dense text. Many are introduced casually in context with the assumption that the reader is already familiar with them or can deduce their meaning.

Don't buy this book! Instead buy one of the books by A. B. Webber, R. W. Sebesta, M. L. Scott, or F. Turbak et al.

Words cannot describe how awful the writing is in this book. Dense language is packed into poorly organized paragraphs; ideas are explained either in too much (overwhelmingly so) detail, or barely explained at all, and then followed up by other densely written paragraphs, which suppose that Finkel did an adequate job explaining, well, anything at all.

This is either the work of a savant, or a child - copying formal definitions of programming language design ideas out of the abstracts of research papers with the density of a neutron star.

My personal opinion? Finkel is able to get away with it because he is writing for an industry where good writing is seldom found. It's a good thing my class is using a different book... oh wait.

To end off, here's a paragraph I'll type out for you:

"The situation becomes surprisingly complex when procedures (and labels) are passed as parameters. They carry with them their nonlocal referencing environment, so that when they are invoked, they may access nonlocal variables that are otherwise inaccessible in the program. A procedure in combination with its referencing environment is called a closure."

That's the best paragraph I've read yet.

It is a book special to all that want to know interesting details about useful and "popular" languages like C, Pascal, etc, but also about that so called "classic"(on that concerns design) that are not so current, like Icon, CSP, going up to outsiders like Io. It is great for an undergraduate course on programming language topics (to show why things are not finished just in Computer Programming I) or even to stimulate graduate students to research in area. Perhaps not the best scientifically (Watt or Appel did better, yeat!), but is the best in motivation!