Eiffel: Analysis, Design and Programming

Eiffel: Analysis, Design and Programming is the formal name of the Eiffel programming language as standardized by ECMA International (ECMA-367) and the International Organization for Standardization (ISO/IEC 25436). The language was created by Bertrand Meyer in 1986 with a singular ambition: to make software correctness a first-class property of the programming language itself, not an afterthought enforced by testing alone.

History & Origins

The Problem Meyer Set Out to Solve

In the mid-1980s, software development was dominated by a reliability crisis. Large commercial systems failed in production, not because developers lacked skill, but because the gap between specification, design, and implementation created countless opportunities for inconsistency. Preconditions assumed by a routine’s callers were never written down. Postconditions that callers depended upon were never guaranteed. Class invariants drifted as systems evolved.

Meyer had studied formal specification methods — particularly Tony Hoare’s axiomatic semantics and Jean-Raymond Abrial’s Z notation (which Meyer contributed to around 1978–79) — and believed their rigor could be embedded directly into a practical programming language rather than remaining in separate mathematical documents. He also drew from his experience with Simula’s object model, Ada’s emphasis on software engineering discipline, and ALGOL’s structured syntax.

The result was Eiffel, first introduced publicly at the inaugural OOPSLA (Object-Oriented Programming, Systems, Languages, and Applications) conference in October 1986. The first commercial release followed from Interactive Software Engineering (ISE) later that year.

Interactive Software Engineering and the ISE Era

ISE (later renamed Eiffel Software) was the primary vehicle for Eiffel’s commercial development. The company produced the canonical EiffelStudio IDE and maintained the reference implementation of the language. Meyer served as chairman and chief technology officer, ensuring the language and tooling evolved as a cohesive whole rather than fragmenting across incompatible implementations.

Formalization as ECMA-367

As Eiffel matured, the community sought international standardization. On June 21, 2005, ECMA International approved the 1st edition of ECMA-367, formally titled “Eiffel: Analysis, Design and Programming Language.” The 2nd edition was adopted in June 2006, and ISO published it as ISO/IEC 25436 in November of that year. This makes Eiffel one of relatively few programming languages to achieve full ISO standardization, placing it alongside COBOL, Fortran, Ada, and C in that exclusive group.

The standard’s full title — “Analysis, Design and Programming Language” — reflects Meyer’s conviction that a single consistent notation should span the entire software development lifecycle, from requirements analysis through design to executable code.

Design Philosophy

Design by Contract

Eiffel’s defining contribution to computing is Design by Contract (DbC), a methodology for specifying software interfaces in terms of mutual obligations. The metaphor is a legal contract: each party states what it will provide and what it requires in return.

In Eiffel, contracts are expressed in three forms:

Preconditions (require) — conditions the caller must satisfy before invoking a routine:

withdraw (amount: INTEGER)
    require
        amount_positive: amount > 0
        sufficient_funds: amount <= balance
    do
        balance := balance - amount
    ensure
        balance_reduced: balance = old balance - amount
    end

Postconditions (ensure) — conditions the routine guarantees upon return. The old keyword captures the value of an expression at the point of entry, enabling before/after comparisons.

Class invariants (invariant) — conditions that must hold for every observable state of any instance of the class:

class BANK_ACCOUNT
    ...
invariant
    non_negative_balance: balance >= 0
    owner_not_void: owner /= Void
end

Contracts serve three simultaneous purposes: they are documentation (precisely specifying intent), they are tests (checked at runtime in debug builds), and they are formal specifications (amenable to static analysis and proof). This triple role distinguishes Eiffel’s approach from ad hoc assertions or external documentation.

The Correctness-by-Construction Principle

Meyer’s broader philosophy, articulated in Object-Oriented Software Construction, is that software should be correct by construction rather than correct by testing. Testing can demonstrate the presence of bugs but never their absence; contracts can provide logical guarantees about software behavior for all possible inputs satisfying the precondition. When combined with static verification tools, Eiffel contracts can provide near-formal proofs of correctness.

Command-Query Separation

Eiffel enforces a clean architectural principle: queries (functions returning values) must have no side effects, while commands (procedures modifying state) return no values. This separation makes reasoning about code significantly easier — reading a value cannot change the system’s state, which eliminates an entire class of subtle bugs common in languages that mix queries and commands.

-- Query: pure, no side effects
count: INTEGER
    do
        Result := internal_list.count
    end

-- Command: modifies state, no return value
add (item: STRING)
    do
        internal_list.extend (item)
    end

Uniform Access Principle

Clients of a class cannot tell whether they are accessing a stored attribute or computing a result via a function — the syntax is identical:

-- These look the same to the caller:
bank.balance        -- could be a stored field
bank.balance        -- could be a computed function

This allows internal implementation to change (e.g., from stored value to computed property) without breaking any client code.

Key Language Features

Multiple Inheritance with Conflict Resolution

Eiffel supports full multiple inheritance — a class may inherit from any number of parent classes. The “diamond problem” (where two parents share a common grandparent) is handled through explicit renaming and selection:

class FLYING_CAR
inherit
    CAR
        rename
            move as drive
        end
    AIRCRAFT
        rename
            move as fly
        end
end

Inherited features can be renamed to avoid collisions, redefined with new implementations, or selectively combined. This makes multiple inheritance tractable without the ambiguities that plagued C++.

Genericity

Eiffel provides parametric polymorphism through generic classes:

class SORTED_LIST [G -> COMPARABLE]
feature
    extend (item: G)
        do
            -- Insert item in sorted position
        end

    has (item: G): BOOLEAN
        do
            -- Binary search
        end
end

Generic parameters can be constrained (e.g., G -> COMPARABLE requires that G supports comparison), enabling type-safe generic algorithms. This predates Java generics by over a decade and avoids many of Java’s generics limitations.

Void Safety

One of Eiffel’s most important modern contributions is void safety — the elimination of null pointer exceptions at the language level, a problem Tony Hoare called his “billion-dollar mistake.”

The ECMA-367 2nd edition introduced a type-system distinction:

name: STRING          -- Attached: can never be void (null)
nickname: detachable STRING  -- Detachable: may be void, must be checked

The compiler statically verifies that attached references are always initialized before use and that detachable references are checked before dereferencing. This was a language-level solution to null safety that predated Kotlin’s approach by roughly a decade.

Agents (Closures)

Eiffel’s agents provide first-class routines — callable objects that wrap a routine call, enabling higher-order programming:

-- Create an agent wrapping a routine
my_agent: PROCEDURE [INTEGER]

my_agent := agent print_integer

-- Pass agents as arguments
list.do_all (agent process_item)

SCOOP: Simple Concurrent Object-Oriented Programming

Eiffel’s concurrency model, SCOOP, addresses the fundamental difficulty of concurrent programming through the type system rather than explicit locking. Marking an object reference as separate indicates it may be handled by a different processor (thread or remote node):

process (data: separate DATABASE_CONNECTION)
    do
        -- Synchronization with 'data' is automatic
        data.execute_query ("SELECT * FROM orders")
    end

When a routine receives a separate argument, Eiffel guarantees exclusive access for the duration of the call, eliminating data races without manual mutex management.

Compilation Architecture

Melting Ice Technology

EiffelStudio uses a compilation strategy called Melting Ice that enables rapid development cycles without sacrificing production performance:

• Frozen code: Fully compiled to C, then to native machine code
• Melted code: Interpreted bytecode for changed classes

During development, only the classes modified since the last compilation are “melted” (recompiled to bytecode for immediate execution). Unchanged code remains “frozen” as native machine code. This hybrid approach provides near-instant turnaround on incremental changes while keeping the full system runnable.

For production deployment, everything is finalized — compiled to optimized C and then to native executables. No runtime environment is required; Eiffel programs run as standalone native binaries.

Compilation Targets

EiffelStudio can target:

• Native code on Linux, Windows, and macOS via a C backend
• .NET / .NET Core via Common Intermediate Language (CIL) generation

The Standard Library: EiffelBase

The canonical Eiffel library, EiffelBase, provides foundational data structures and algorithms with full contract specifications. Every class specifies preconditions, postconditions, and invariants as part of its interface, meaning that even library documentation is executable and verifiable. This consistency — contracts throughout the standard library, not just user code — makes Eiffel codebases unusually coherent and self-documenting.

Implementations

Evolution and the OOSC Books

Meyer’s two-volume Object-Oriented Software Construction remains one of the most comprehensive treatments of object-oriented design ever written:

• 1st edition (1988): Introduced Design by Contract and justified Eiffel’s design; seminal text for the OOP community
• 2nd edition (1997): Expanded to over 1,300 pages; won a Jolt Award; separated general OOP principles from Eiffel-specific notation; remains a standard reference in software engineering

These books were influential not just for Eiffel adoption but for shaping how the entire industry understood object-oriented programming, encapsulation, inheritance, and correctness.

Influence on Later Languages

Eiffel’s ideas permeated languages designed after it, even when Eiffel itself did not achieve mainstream adoption:

• Ada 2012: Added contract-based programming (Pre and Post aspects) — a direct acknowledgment of Eiffel’s influence on the Ada standards committee
• D: Built-in contract programming (in, out, body blocks) explicitly modeled on Eiffel
• Spec#: Microsoft Research’s extension of C# added contracts inspired by Eiffel’s DbC
• Kotlin: Eiffel’s Design by Contract has reportedly been cited as an influence on Kotlin’s contracts feature
• Microsoft Code Contracts: A .NET library implementing DbC concepts for C# and VB.NET, inspired by Eiffel
• JML (Java Modeling Language): A specification language for Java that adapted Eiffel’s contract notation for annotation-based use

The concept of void safety also anticipated Kotlin’s non-nullable types, Swift’s optionals, and Rust’s ownership model — all different solutions to the same null-dereference problem that Eiffel addressed in the ECMA-367 2nd edition.

Current Relevance

Eiffel occupies a unique position in 2025: it is neither a mainstream industrial language nor an abandoned historical curiosity. EiffelStudio 25.02 (February 2025) brings full .NET 8.0 support and continued tooling improvements, demonstrating active development nearly 40 years after the language’s introduction.

Its community is concentrated in domains where software correctness is non-negotiable — finance, engineering, safety-critical systems — and in academia, where Eiffel’s clarity of design and contractual rigor make it an exceptional teaching language for software engineering principles.

For developers who prioritize correctness over conciseness, Eiffel remains a language without peer: it is the only mainstream language where Design by Contract is not a library feature or an annotation system bolted on afterward, but a core part of the language semantics from the ground up.

Resources

• eiffel.org — Community portal, documentation, and EiffelStudio downloads
• ECMA-367 Standard — Official language specification
• Eiffel Software — Commercial support, EiffelStudio IDE
• Liberty Eiffel — Open-source alternative compiler
• Gobo Project — Portable Eiffel tools and libraries