Programming Language Design and Implementation (Torben Ægidius Mogensen) (z-library.sk, 1lib.sk, z-lib.sk)

# Programming Language Design and Implementation — Reading Guide ## 【One-Line Pitch】 A concept-driven tour of the programming-language design space that shows how every design decision—from syntax to memory management—ripples into implementation complexity, performance, and usability. Ideal for advanced undergraduates, graduate students, and working professionals who want to design or evaluate languages with operational awareness rather than taste alone. ## 【Book Arc】 - **Opening (~0%–15%)**: The book positions itself as neither a compiler textbook nor a comparative-language survey. It assumes you already know basic parsing and code generation, and instead asks a deeper question: what does it mean to *design* a language, and how do choices interact with implementation? The preface lays out the author's core conviction—designers need operational understanding, not just familiarity with what others have done. - **Early (~15%–31%)**: The book confronts the "why new languages at all?" question head-on. Since most languages are Turing complete, computational power alone can't justify a new design. The author dissects common comparison criteria—program size, speed, ease of programming, ease of reasoning—and shows why each is flawed or subjective. This section also introduces cross-cutting design principles: simplicity without over-simplification, precise describability, implementation awareness, and the critical role of libraries. - **Middle (~31%–46%)**: The historical chapter traces programming languages from Turing machines and the lambda calculus through Plankalkül, FORTRAN, LISP, ALGOL 60, Simula, C, ML/Haskell, Python, Java, and Rust. This isn't nostalgia—each language illustrates specific design choices and their consequences. The implementation-strategies chapter then covers compilation vs. interpretation, REPLs, intermediate code, virtual machines, hybrid methods, cross-compilers, obfuscation, and bootstrapping. - **Middle (~46%–58%)**: The syntax chapter dives into lexical elements: character sets, case sensitivity, identifiers, whitespace, comments, and reserved symbols. The memory-management chapter is notably deep, covering static, stack, and heap allocation, manual management with malloc/free implementations, reference counting, and tracing garbage collectors including mark-sweep, two-space, generational, and concurrent collectors. - **Late (~58%–end)**: The remaining chapters continue the concept-by-concept structure—types, scopes, modules, domain-specific languages, formal semantics, and limits of computation, with the second edition adding coverage of quantum computation. The excerpts confirm the book's breadth but do not detail these later sections' content. ## 【Key Takeaways】 - **Turing completeness is the wrong lens for comparing languages** (Early): Since nearly all languages are Turing complete, computational power can't justify new designs. The real differentiators are program size, speed, ease of programming, and ease of reasoning—but each criterion has deep flaws. Program size can be gamed by embedding interpreters; speed says more about implementation than design; ease is subjective. What matters is how features combine in practice. - **Design principles are cross-cutting, not per-feature** (Early): Six guidelines recur throughout: no perfect design exists, choices interact (for better or worse), simplicity is paramount but over-simplification harms practicality, languages must be precisely describable, designers need implementation sketches before finalizing decisions, and library support is essential unless you're building a domain-specific language. These aren't laws—they're guardrails. - **Implementation awareness prevents design regret** (Early): The author's central thesis: a designer who doesn't understand implementation consequences will make choices that are excessively hard to implement, impede performance, or make program behavior unpredictable—especially when features interact. The book's implementation sketches are deliberately not detailed, but they're sufficient for a competent programmer to build from. - **Domain-specific languages trade completeness for provability** (Early): Deliberately non-Turing-complete languages can guarantee properties like termination or resource bounds that are undecidable in general-purpose languages. This trade-off is a feature, not a bug, for DSLs—they're useless outside their domain but powerful within it. - **Memory management is a design spectrum, not a binary** (Middle): The book walks through static, stack, and heap allocation, then manual management (including a simple malloc/free implementation with block joining and size sorting), reference counting, and tracing collectors (mark-sweep, two-space, generational, concurrent). Each approach has distinct trade-offs in throughput, latency, and programmer burden—and the choice shapes language semantics. - **Syntax details carry semantic weight** (Middle): Lexical choices—character sets, case sensitivity, identifier rules, whitespace significance, comment syntax, reserved symbols—aren't cosmetic. They affect parsing complexity, tooling, internationalization, and even program correctness. The book treats these as design decisions with real consequences. - **Implementation strategy is itself a design choice** (Middle): Compilation vs. interpretation, REPLs, virtual machines, hybrid methods, cross-compilers, and bootstrapping are not neutral implementation details. They influence language design—for example, what's feasible in a language that's always interpreted vs. one that's always compiled. The bootstrapping section shows how a language's compiler can be written in the language itself. ## 【Reading Tips】 - **Read the preface and design-principles section carefully** (~12%–31%): This is the intellectual core. The six design principles and the critique of comparison criteria frame everything that follows. Skim if you're in a hurry, but this is where the book's philosophy lives. - **Use the history chapter as a reference, not a narrative** (~38%–46%): The language-by-language survey (Plankalkül through Rust) is best consulted when you encounter a language in later chapters and want context. Don't read it straight through unless you're a history buff. - **Deep-read the memory-management chapter** (~54%–58%): This is the most implementation-heavy section in the excerpts, with concrete malloc/free implementations and garbage-collector algorithms. If you're designing a language with automatic memory management, this chapter is essential. If not, skim the algorithm details. - **Treat implementation sketches as starting points** (throughout): The author explicitly says sketches are guides, not specifications. If you're implementing a language, use these as scaffolding and fill in details yourself. If you're only evaluating designs, the sketches help you estimate implementation difficulty. - **Do the exercises if you're serious about design** (throughout): The book includes both technical and discussion exercises. The discussion ones are particularly valuable for thinking through trade-offs—try at least one per chapter to internalize the design-space mindset. ## 【Coverage Limits】 This guide is based on excerpts covering roughly the first 58% of the book. Later chapters on types, scopes, modules, domain-specific languages, formal semantics, limits of computation, and quantum computation are confirmed to exist but their specific content is not covered here. ##