Getting Started with EK9 · Appendix C

The Evidence: the research behind the rules

Many of EK9's rules forbid something other languages allow. This appendix gathers the reasons in one place: each entry names the rule, what it prevents, and the source of the lesson.

None of these ideas is new. EK9 did not invent unit testing or information hiding; it takes ideas the field has trusted for decades and builds them into the language, so they are enforced rather than advised.

Every source is real. If one interests you, read it, or give it to an AI and ask for a summary at the level you want.

No `null`; values are absent, unset, or set

EK9 has no null keyword. A value is absent, unset, or set. EK9 is designed so that an absent value can never be read, and the compiler checks every read.

The cost of getting this wrong is famous. Sir Tony Hoare, who introduced the null reference in 1965, later called it his "billion-dollar mistake" (QCon London, 2009), for the errors it caused over the following decades.

No `return`; name the result instead

EK9 has no return to leave a function part-way through. A function names its result up front, and the compiler checks that every path sets it.

Apple's "goto fail" bug (2014, CVE-2014-1266) shows what a jump out of the middle of a block can do: a duplicated goto fail; line skipped TLS signature verification on iOS and macOS.

No `break` or `continue`; use streams and guards

EK9 has no break or continue. You express "stop early" or "skip this one" with stream pipelines and guards instead.

This traces to Edsger Dijkstra's "Go To Statement Considered Harmful" (Communications of the ACM, 1968) — the argument that unrestricted jumps make code hard to reason about. break and continue are small gotos; removing them keeps the shape of a loop honest.

No fall-through in `switch`

In EK9 a matching case runs and that is all; there is no fall-through into the next case, so there is no break to forget.

Forgetting that break is a recorded weakness: the CERT C coding standard covers it in recommendation MSC17-C, and the Common Weakness Enumeration lists it as CWE-484, "Omitted Break Statement in Switch".

Copy at the boundary; no leaking your insides

A type that owns data copies it in and copies it out, so no outsider can reach in and change it.

This is information hiding, named by David Parnas in "On the Criteria To Be Used in Decomposing Systems into Modules" (CACM, 1972). The specific trap — handing back a reference to your own internals — is representation exposure, described by Barbara Liskov and John Guttag (2000) and by Joshua Bloch's advice on defensive copying. A related modern example: Go shared one loop variable across iterations for over a decade, causing a whole class of bugs, until the language was changed to copy it per iteration in Go 1.22 (2024).

Traits, not tangled inheritance

EK9 uses traits to share behaviour across unrelated types, instead of deep inheritance chains.

Traits come from "Traits: Composable Units of Behaviour" by Nathanael Schärli and colleagues (ECOOP, 2003), which showed how to compose behaviour without the fragility of multiple inheritance.

The compiler measures coupling and cohesion

EK9 measures how tangled your types are (coupling) and how focused they are (cohesion), and it enforces generous but fixed limits.

The terms were coined by Stevens, Myers and Constantine in "Structured Design" (IBM Systems Journal, 1974). The specific measures EK9 enforces are efferent coupling (Ce) for coupling and LCOM4 for cohesion — the latter from M. Hitz and B. Montazeri, "Measurement of Coupling and Cohesion in Object Oriented Systems" (1995). Cohesion applies to classes, services and components, not to records or traits.

Named, typed message placeholders

EK9's localised text uses named, typed placeholders like ${name}, checked at compile time — never untyped positional markers like %s or {0}.

Weitz and colleagues, "A Type System for Format Strings" (ISSTA, 2014), built a checker that finds format-string mistakes at compile time — mistakes an ordinary compiler cannot see. EK9 makes the compiler see them.

More sources cited in the chapters

These shaped individual chapters rather than a single rule. Each is footnoted where it is used.

Preconditions and contracts (Functions): C. A. R. Hoare, "An Axiomatic Basis for Computer Programming" (1969), and Bertrand Meyer's Design by Contract, built into the Eiffel language and described in Object-Oriented Software Construction (1988). require is EK9's precondition.
Writing the test first (Testing as You Go): Kent Beck, Test-Driven Development: By Example (Addison-Wesley, 2002).
Naming a value once (Reading the Compiler's Guidance): Juergens, Deissenboeck, Hummel and Wagner, "Do Code Clones Matter?" (ICSE, 2009), on changes made to some copies of code but not others.
Small pieces joined by pipes (Streams and Pipelines): Douglas McIlroy, who conceived the Unix pipe, added in 1973.
Many functions over one structure (Records and Enumerations): Alan Perlis, Epigrams on Programming (1982), epigram 9.
Composition over inheritance (Traits and Composition): Gamma, Helm, Johnson and Vlissides, Design Patterns (1994), and William Cook, Walter Hill and Peter Canning, "Inheritance Is Not Subtyping" (POPL, 1990).

The two big payoffs

Two names sit behind the whole language, and the second volume, EK9 in Depth, returns to them:

Hoare's null mistake — which the three-state model above is designed to remove.
The Liskov Substitution Principle (Barbara Liskov, 1987; Liskov and Wing, 1994) — the rule that a subtype must be usable wherever its parent is. EK9 supports it with its rules — no casts, and an override keeps the purity of the method it replaces — and the second volume looks at how far those rules go.