Way to Learn Computer

I agree that every compiler writer (not engineer: programming is a cruelly difficult writing *sui generis*, not engineering) needs this book but its market is or should be much wider.

There is NO way to learn programming except at the intersection between compiler writing and applications programming, and it is a MISTAKE to teach programming as either a context-free application programmer’s worship of machines and authority, or as the acquaintance with one programming language, its mistakes of design and implementation included, as Eleusinian mysteries demanding reverence.

Dijkstra, famously, described programming as applied mathematics. The concept of “applied” introduces an ineradicable tension between one discipline and another where the key ability is the ability to shuttle between layers of representation.

Crude language speaks airily of the needs of the user, where the user is hypostatized, singular, male, and imaged as wealthy and lacking taste. The actuality is that the relationship goes in computing all the way down, one user is also a worker for another, and only a programmer who has mastered his trade understands the need to transcend, in the course of understanding, the relationship.

Thus this book is useful not only to the compiler writer but also to the application programmer, because (for example), the application programmer has to understand at least in general terms how the For or Do construct of his language is evaluated.

He’s importuned instead to meditate upon business needs with the result that something like 80% of large systems fail.

A programmer who, in Visual Basic, does not understand that For intIndex1 = 1 To intLimit – 1 is not “inefficient” because the expression is evaluated by value, doesn’t know his trade. A programmer who, in C, doesn’t know that while ( intIndex1 = 0; intIndex < = intLimit - 1; intIndex++ ) IS inefficient insofar as the expression is repeatedly evaluated doesn't know his trade, and the book is full of useful information about these important semantic issues.

Many programmers use the totally inappropriate automobile metaphor to describe the computer and in so doing they declare that no more than they would look under the hood of their car, they should be freed of important issues of semantics and if possible coherent and readable syntax in their mindless coding.

The metaphor confuses a force and energy determined system with an information engine. It also encapsulates a narrow understanding, restricted to America and other energy-wasteful societies, of what it means to relate, even to cars, for the atypical but thrifty American, who buys manual transmission used cars, or the Havana teen, who starts his car by rolling it down the hill, both are familiar, of necessity, with what goes on “under the hood”…or else.

A person with claims to professional writing skills would of course be familiar with semantics as well as syntax. But in programming, semantics is confused with “being a compiler developer or something”.

Unlike natural language semantics, which bleeds out in history and sociology, programming language semantics is coeval with the “way the compiler works” in the sense of its specification, captured NOT in Programming Languages for Dummies BUT INSTEAD in the specifications document for the language.

[In France titles in the For Dummies series are "pour les nuls", which is *tres amusant*. I don't mean to slam this series which is well written and useful, but its title needs rethinking, for it at once asserts class pride and solidarity while disempowering in the very act of doing so.]

Good program design is based on knowing how the compiler “works” in the sense of understanding the language contract, which in C forces while evaluation by reference but in Visual Basic forces it by value.

The advanced material in this book on the implementation of Prolog and logic languages is important because it shows how far these languages are from being complete in the sense of first-order logic with quantification, which explains the survival of procedural languages.

My First Computer Book, special-ordered from the Roosevelt University Bookstore in 1971, was Peter Wegner’s Information Structures, Programming Languages, and Machine Organization, a book in the Algol tradition which taught how to think at the Edge City, where the user’s problem meets the circuits. This book, like Wegner, teaches the same lessons. About its only flaw is that like many titles from Morgan Kaufmann, which seems to have an incestuous relationship with MIPS and the RISC kiddies, it overemphasizes clever optimization and completely downplays the importance of the stack model of computation, a RISCy tradition.

Rating: 4 / 5

Every debugging engineer needs to know how the code is interpreted or compiled. Debugging complex problems or doing memory analysis on general-purpose operating systems often requires understanding the syntax and semantics of several programming languages and their run-time support. The knowledge of optimization techniques is also important for low-level debugging when the source code is not available. The following book provides an overview of all important concepts and discusses almost 50 languages. I read the first edition 6 years ago and I liked it so much that I’m now reading the third edition from cover to cover.

Thanks,

Dmitry Vostokov

Founder of DumpAnalysis Portal

Editor-in-Chief of Debugged! MZ/PE magazine
Rating: 5 / 5

The best (only?) book on the subject of PLs that ties abstract concepts directly to practice. Clear, concise and incredibly thorough in both breadth and depth. A rare pleasure…
Rating: 5 / 5