Rob Pike’s Rules of Programming (1989)

Rule 5 and the Primacy of Data Structures

• Strong consensus that “data dominates”: good data structures and schemas make algorithms and control flow almost obvious.
• Multiple references to data-first design in practice: start from DB schema or types, then layer UI, business logic, and queries on top.
• Several argue that most hard refactors and performance wins come from rethinking data layout, not clever code.
• Others note the emotional difficulty: you often know your data model isn’t right yet, but you must still ship and iterate.

Perlis, Pike, and “One Data Structure, Many Functions”

• Debate over whether Perlis’s “100 functions on one data structure” aligns with Pike’s rule and Brooks’s “show me your tables”.
• One side reads it narrowly: a single central representation per domain concept (e.g., one driver-license record type), not a universal mega-structure.
• Critics warn that too-general data structures cause poor fit, complex algorithms, and loss of separation of concerns.
• Functional and Clojure-style ecosystems are cited as examples of leaning into a small set of rich, generic data types.

Premature Optimization, Performance, and Simplicity

• Rules 1–4 are linked to the famous “premature optimization” dictum; many complain that a decontextualized version has been used to justify slow, bloated systems.
• Others defend the original intent: avoid micro-optimizations and contorted control flow before measuring, but do care about algorithmic complexity and obvious hot paths.
• Disagreement over how often one can “predict” bottlenecks: some claim experienced engineers usually can; others insist profiling routinely contradicts intuition.
• Several note that today’s real problems are premature abstraction and architecture-for-hypothetical-futures more than premature optimization.

AI-Assisted Development and Data Design

• Multiple commenters report that codegen models tend to choose naive data structures, elaborate control flow, and poor documentation unless explicitly guided.
• A common workflow: humans design core data models and module boundaries; AI fills in straightforward code and later assists with refactors.
• Some see AI as useful for exploring alternative designs; others judge it poor at navigating design space compared to learning a functional language or C.

Databases, Relationships, and Documentation

• Relational databases are praised for forcing explicit relationships and making systems understandable via schemas.
• Good schema and key design are described as central to correctness, performance, and maintainability.
• When using AI on legacy codebases, focusing prompts on key data structures and data flow yields far better documentation than module-by-module summaries.