Eiffel (ECMA-367 / ISO/IEC 25436:2006)

Analysis against the Eiffel language standard (ECMA-367, approved June 2005; ISO/IEC 25436:2006) and EiffelStudio 25.12 (January 2026). Eiffel, created by Bertrand Meyer, is the language that introduced Design by Contract.

This assessment applies the coupling account — coupling as access to a shared resource, and the coupling floor [1], [2] — and the knowledge-embodiment theorem [3]; the language is assessed against its official reference [4].

1 Assessment

This page assesses Eiffel in five parts: core coupling — what the language’s own constructs force; ecosystem coupling — what the surrounding platform, tooling, and community cost; engineering readiness — whether the artifact can be reproduced, verified, observed, worked in quickly, connected to other languages, and governed openly; the profile — the unscored facts a score cannot express; and the scoring detail — the mechanism marks and the arithmetic behind every score. A ✅ bullet marks a construct that helps. A ⚠️ or ❌ bullet marks a cost; the scoring model does not price every cost named here.

Core coupling 46/100 · Ecosystem coupling 46/100 · Engineering readiness 57/100

1.1 Core coupling

1.1.1 Type

  • ✅ Design by Contract (DBC): require (preconditions), ensure (postconditions), and invariant (class invariants) make an element’s change conditions explicit. This is the coupling-relevant feature: contracts name the requirements an element realizes, so a change in one element’s requirements that forces another element’s contract to change is visible at the boundary
  • ✅ Void safety (attached types): x: attached T vs x: detachable T separates non-null from nullable at compile time (Eiffel 6+). Eliminates the null-checking coupling class at compile time
  • ✅ Strong static typing: No implicit coercion, no unchecked casts as escape hatches
  • ✅ No argument overloading: Each feature name within a class maps to exactly one feature — “one name, within one class, means one thing.” This eliminates method-resolution ambiguity coupling and is what makes Eiffel’s multiple inheritance safe
  • ✅ Command-Query Separation: Queries (which return information) must not modify the instance — a Meyer design rule that prevents side effects hidden in value retrieval from coupling unrelated elements
  • ✅ Generics with constraints: LINKED_LIST [G -> COMPARABLE] decouples containers from element types
  • ⚠️ Multiple inheritance: Supported with rename, redefine, and select — powerful feature reuse but creates hierarchy coupling and diamond complexity
  • ⚠️ Inheritance still available: Class hierarchies couple behavior to the inheritance tree

1.1.2 Construction

  • ✅ Creation procedures (create): Separate allocation from initialization; create x.make(...)
  • ✅ Invariants validate object state: invariant clauses check well-formedness after every feature call
  • ⚠️ Creation procedures can have side effects: Nothing enforces pure construction
  • ❌ Once routines create global singleton state: once routines run once (per thread by default, configurable per process or per object) and cache their result — a memoized shared-state coupling across the system

1.1.3 Memory

  • ✅ Automatic GC: No manual deallocation, no use-after-free, no dangling pointers
  • ✅ No pointers: Memory safety by construction; expanded types give value semantics
  • ⚠️ GC pauses: Non-deterministic, couple timing-sensitive code to runtime
  • ⚠️ Void references possible (legacy code): Without attached-type discipline, dereferencing a void reference raises a Void_call exception at runtime

1.1.4 Error

  • ✅ Rescue/retry: Structured exception handling where rescue + retry separates error recovery from error detection — failure handling decoupled from the code that triggered it
  • ✅ Contract-driven exceptions: Exceptions arise from precondition/postcondition/invariant violations, making failure points explicit and first-class rather than accidental
  • ⚠️ Exceptions not used for control flow: Eiffel treats exceptions as contract failures, so error recovery is limited to what the contract model supports
  • ⚠️ Contracts can be disabled at compile time: EiffelStudio can compile an executable to include or exclude any set of contracts (workbench vs. deployment modes), coupling correctness to build configuration

1.1.5 Concurrency

  • ✅ SCOOP (Simple Concurrent Object-Oriented Programming): Separates concurrency from logic via processor- and handler-oriented design; decouples “what runs concurrently” from “how it synchronizes” (e.g. multiple threads without explicit mutex management). Available in EiffelStudio, though not yet part of the official language definition
  • ✅ Agents: Wrap operations into objects, closely connected with closures and lambda calculus — decoupling callbacks from the calling code
  • ⚠️ SCOOP is complex and niche: Correct concurrent design requires deep expertise; low adoption
  • ⚠️ Shared mutable state possible: No compiler-level race detection

1.1.6 Platform

  • ✅ Native compilation without a runtime: EiffelStudio compiles to a native executable, so a deployed program does not depend on a vendor runtime
  • ✅ Portable across the major desktop platforms: EiffelStudio targets Windows, Linux, and macOS
  • ⚠️ One vendor owns the ISO-conforming implementation: EiffelStudio is the ISO-conforming implementation and is commercial software from Eiffel Software, so the platform’s evolution depends on that single vendor

1.1.7 Trade-offs (not coupling)

  • Contract vs. Runtime Cost: Contract checking adds overhead; disabling it (deployment mode) removes the enforcement
  • Inheritance vs. Composition: Eiffel encourages inheritance as its primary reuse mechanism; multiple inheritance couples but enables precise feature reuse via renaming
  • SCOOP vs. Pragmatism: The concurrency model is elegant and low-coupling but hard to adopt in practice
  • Once Routines vs. Independent Units: Memoization decouples repeated computation but couples the element to global shared state that other elements may depend on
  • Contract Depth vs. Discipline: DBC only helps if teams actually write contracts; without them Eiffel degenerates to a plain typed OOP language

1.2 Ecosystem coupling

1.2.1 Performance

  • ✅ Compiled to native code: EiffelStudio generates efficient native executables
  • ⚠️ GC pauses: Non-deterministic, though modern GCs keep them short (R2)
  • ⚠️ Contract overhead: Runtime checks add cost; disablement improves performance but removes guarantees
  • ✅ Deterministic when contracts disabled: Predictable execution in deployment mode

1.2.2 Ecosystem

  • ❌ Small ecosystem: Far fewer libraries than the JVM or .NET, so a solution couples to the few that exist and to a niche community
  • ✅ EiffelStudio is a complete IDE: Integrated compiler, debugger, and contract-aware tooling
  • ⚠️ Dated tooling: Modern build systems and package managers are weak relative to mainstream
  • ⚠️ Niche community: Limited third-party support and resources
  • ⚠️ Fragmented implementations: EiffelStudio, “The Eiffel Compiler” (tecomp), Gobo Eiffel, SmartEiffel, and LibertyEiffel differ; the GNU implementations track an older language version and do not fully implement the ISO standard

1.2.3 Evolution

  • ✅ ISO/ECMA standard: Eiffel is an ISO/IEC standard (ISO/IEC 25436:2006, ECMA-367), giving a stable language core
  • ⚠️ Slow, conservative evolution: The standard is stable but innovation is glacial
  • ⚠️ Implementations diverge: EiffelStudio and the GNU-based implementations have drifted on language features
  • ❌ Niche survival concern: Long-term support depends on a small commercial base

1.2.4 Domain

  • ✅ Excellent for high-integrity and contract-heavy domains: DBC is ideal where correctness is paramount and reliability is the design goal
  • ✅ Good for teaching design-by-contract: The language enforces the discipline
  • ⚠️ Poor for mainstream web/systems: GC, niche ecosystem, dated tooling
  • ⚠️ Little adoption in modern development: Hard to hire for

1.2.5 Learning

  • ✅ DBC is a clear mental model: Contracts make intent explicit
  • ⚠️ Multiple inheritance + renaming complexity: Advanced Eiffel is hard to master
  • ⚠️ SCOOP adds a second learning curve: The concurrency model is non-trivial
  • ⚠️ Fewer modern resources: Documentation is dated relative to mainstream languages

1.2.6 Syntax

  • ✅ Readable, English-like: if x then ... else ... end, require/ensure/invariant read naturally
  • ✅ Explicit contracts: The syntax makes specification a visible part of every feature
  • ⚠️ Verbose: end clauses and full declarations add ceremony
  • ⚠️ Non-standard keywords: Keywords (e.g. feature, deferred, attached) are unfamiliar to most programmers

1.2.7 Testing

  • ✅ Contracts enable automated testing: preconditions/postconditions/invariants act as built-in test assertions
  • ✅ EiffelStudio debugger: Contract-aware, can inspect invariant violations
  • ✅ Exception handling tools: rescue/retry makes error paths debuggable
  • ⚠️ Few third-party test frameworks: The ecosystem is thin

1.2.8 Security

  • ✅ Memory safe: GC, no pointers, no use-after-free, no buffer overflows
  • ✅ Void safety: Prevents null-pointer vulnerabilities by default (with attached types)
  • ✅ Strong typing: No type-confusion bugs
  • ✅ No argument overloading: Unambiguous feature resolution reduces surprising dispatch
  • ⚠️ Once-routine shared state: Can create hidden shared-state vulnerabilities

1.3 Engineering readiness

1.3.1 Reproducibility

  • ❌ Builds are not byte-reproducible by default.
  • ❌ Dependencies resolve without a lock by default.

1.3.2 Supply chain

  • ⚠️ Published packages carry no signed provenance by default.

1.3.3 Observability

  • ⚠️ No stable tracing and metrics standard.
  • ⚠️ The standard library has no structured logging.

1.3.4 Feedback

  • ⚠️ No fast in-editor analysis.

1.3.5 Interop

  • ⚠️ No maintained portable target.

1.3.6 Governance

  • ✅ No charged mechanism in this dimension.

1.4 Profile

Unscored, and kept separate from every score on purpose. The profile records what a mechanism price cannot express: what a running program costs, how well a coding model and an agent work in the language, and whether a safety-critical path exists.

1.4.1 Energy and cost

What this axis asks: what does a running program cost in energy and time?

  • ✅ Compiles to native code: the fastest class in the language energy and time benchmarks [5], [6]. A causal re-analysis attributes the difference to execution time [7].

1.4.2 AI and agent readiness

What this axis asks: how well does a coding model and an agent work in this language?

  • ❌ Sparse training data: models write it unreliably [8].

1.4.3 Safety certification

What this axis asks: is there a certified or standards-qualified path to a safety-critical system?

  • ⚠️ No certified or standards-qualified path for safety-critical systems.

1.5 Scoring detail

1.5.1 Core coupling Dimensions

Dimension Mechanism Description Present Cost
Type T1 dynamic no static check — 0
T2 weak static — 0
T3 dynamic/duck dispatch — 0
T4 no sum types ✅ −4
T5 no generics — 0
T6 no namespaces — 0
T7 type erasure/reflection — 0
T8 operator overloading — 0
T9 inheritance required for polymorphism ✅ −4
T10 no null-safety — 0
T11 no module boundary — 0
T12 no effect tracking ✅ −8
T13 async/sync colouring — 0
T14 unchecked foreign boundary ✅ −4
Type subtotal −15 (−20)
Construction C1 global mutable state by default — 0
C2 no immutability by default ✅ −4
C3 constructors coupled to allocation — 0
C4 no constructor/validation — 0
Construction subtotal −4
Memory M1 manual deallocation — 0
M2 GC non-deterministic pauses ✅ −8
M3 no RAII ✅ −4
M4 no ownership model ✅ −8
Memory subtotal −15 (−20)
Error Er1 no structured path — 0
Er2 unchecked exceptions only — 0
Er3 errors ignored/non-exhaustive — 0
Er4 no composable result type ✅ −4
Error subtotal −4
Concurrency K1 GIL/no parallel — 0
K2 shared mutable state default — 0
K3 manual sync no race detection ✅ −8
K4 no structured concurrency — 0
K5 no primitives — 0
Concurrency subtotal −8
Platform P1 cannot function outside one vendor/domain — 0
P2 single-vendor but other uses ✅ −8
P3 legacy/discontinued platform — 0
Platform subtotal −8

Core Dimensions score: 46/100 — total cost = −54 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

1.5.2 Ecosystem coupling Dimensions

Dimension Mechanism Description Present Cost
Performance R1 interpreted no AOT/JIT — 0
R2 GC pauses ✅ −8
R3 JIT warmup — 0
Performance subtotal −8
Ecosystem Ec1 no package manager — 0
Ec2 fragmented tooling — 0
Ec3 small/niche/discontinued ✅ −8
Ec4 proprietary ✅ −8
Ec5 platform-locked tooling — 0
Ec6 monoculture — 0
Ec7 legacy burden — 0
Ecosystem subtotal −15 (−16)
Evolution V1 breaking changes — 0
V2 frozen — 0
V3 discontinued — 0
V4 glacial standards — 0
Evolution subtotal 0
Domain D1 domain/vendor lock-in ✅ −15
D2 poor domain fit — 0
D3 framework forces architecture — 0
Domain subtotal −15
Learning L1 steep ✅ −8
L2 large surface/multi-paradigm — 0
L3 sparse docs — 0
Learning subtotal −8
Syntax S1 verbose ✅ −8
S2 inconsistent — 0
S3 punctuation-heavy — 0
Syntax subtotal −8
Testing G1 weak tooling — 0
G2 poor debugging — 0
G3 runtime-only errors — 0
Testing subtotal 0
Security Q1 memory-unsafe — 0
Q2 dynamic/weak typing risk — 0
Q3 known vulnerability/injection — 0
Security subtotal 0

Meta Dimensions score: 46/100 — total cost = −54 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

1.5.3 Engineering readiness Dimensions

Dimension Mechanism Description Present Cost
Reproducibility Y1 build not reproducible ✅ −8
Y2 dependencies not pinned ✅ −8
Reproducibility subtotal −15 (−16)
Supply chain Y3 no signed provenance ✅ −8
Y4 registry without namespacing — 0
Supply chain subtotal −8
Observability Y5 no stable tracing standard ✅ −8
Y6 no structured logging ✅ −4
Observability subtotal −12
Feedback Y7 slow build — 0
Y8 no fast in-editor analysis ✅ −4
Feedback subtotal −4
Interop Y9 no foreign-function interface — 0
Y10 no portable target ✅ −4
Interop subtotal −4
Governance Y11 single-vendor governance — 0
Y12 closed specification — 0
Governance subtotal 0

Readiness Dimensions score: 57/100 — total cost = −43 (per-dimension subtotals are capped at −15; an uncapped cost is shown in parentheses where the cap bites).

Verdict: Eiffel’s Design by Contract is the strongest contract-based coupling tool any mainstream-adjacent OOP language offers: it states each routine’s obligations and guarantees in the source, so a boundary change is detected at the contract level rather than hidden in implementation. Void safety removes a whole null-checking coupling class that Java and C# still carry. The no-argument-overloading rule and Command-Query Separation eliminate two specific coupling hazards (ambiguous dispatch, hidden side effects). Main strength: DBC + void safety expose and prevent coupling better than almost any OOP language. Main weakness: niche ecosystem, once routines create shared state, and contracts are only as good as the discipline that writes them.

The formal development. The definitions, theorems, and proofs behind this page are published in:

All published papers

References

[1]
Y. Loth, “On the nature of coupling: All coupling as shared resource access.” Zenodo, Aug. 2026. doi: 10.5281/zenodo.21925122.
[2]
Y. Loth, “Coupling as a consequence of cohesion: Decomposition, the coupling floor, and domain-imposed coupling.” Zenodo, Aug. 2026. doi: 10.5281/zenodo.21925201.
[3]
Y. Loth, “On the nature of cohesion: Cohesion as correctness relative to a partitioning rule.” Zenodo, Jul. 2026. doi: 10.5281/zenodo.21703193.
[4]
ECMA International, “Eiffel: Analysis, design and programming language.” ECMA International; Standard ECMA-367, Geneva, Switzerland, 2006.
[5]
R. Pereira et al., “Energy efficiency across programming languages: How do energy, time, and memory relate?” in Proceedings of the 10th ACM SIGPLAN international conference on software language engineering (SLE), 2017, pp. 256–267. doi: 10.1145/3136014.3136031.
[6]
R. Pereira et al., “Ranking programming languages by energy efficiency,” Science of Computer Programming, 2021, doi: 10.1016/j.scico.2021.102609.
[7]
N. van Kempen, H.-J. Kwon, D. T. Nguyen, and E. D. Berger, “It’s not easy being green: On the energy efficiency of programming languages,” in Proceedings of the 40th IEEE/ACM international conference on automated software engineering (ASE), 2025. doi: 10.1109/ASE63991.2025.00131.
[8]
S. Joel, J. J. Wu, and F. H. Fard, “A survey on LLM-based code generation for low-resource and domain-specific programming languages,” ACM Transactions on Software Engineering and Methodology, 2025, doi: 10.1145/3770084.