Make the invalid combination unable to proceed¶
Cross-Domain EchoesShared pattern · Error Proofing (Poka-Yoke)
A keyed connector can prevent two incompatible parts from fitting together, so a person does not have to remember every forbidden pairing. A static type checker can stop a program from using an argument where the operation requires a different kind of value. Both move a narrowly defined compatibility check into the system before the bad combination is allowed to proceed. They do not remove all mistakes. A connector can still be attached to a wrongly configured device, and a well-typed program can compute the wrong answer. The visual comparison is about a specific rejection rule, not a general promise of safety or correctness.
Choose a role to see its counterpart in both examples. The diagrams show relationships, not measured quantities.
Physical assembly
A connector that rejects a wrong fit
Read Physical Keying or InterlockMechanism
A deliberately keyed geometry admits the intended pairing and mechanically blocks specified incompatible pairings.
In this example: Physical keying blocks only the specified mismatches. Intact geometry and correct downstream configuration are still required.
Programming languages
A statically checked function call
Read Type SystemDomain-specific abstraction
A function expecting an input of type A is checked against an argument of that type before the program is admitted.
In this example: The example selects static checking under the language’s type rules. Dynamic type systems enforce checks at another time.
The restriction is checked by the system at the attempted combination, reducing reliance on memory or vigilance.
Written comparison
The attempted combination
Physical assembly
Two physical parts
Programming languages
An operation and argument
Name the particular mismatch to prevent rather than treating all errors as one category.
The built-in restriction
Physical assembly
Key-and-slot geometry
Programming languages
Language typing rules
The restriction is checked by the system at the attempted combination, reducing reliance on memory or vigilance.
A bounded permission
Physical assembly
The connection can be completed
Programming languages
The call passes the type check
Acceptance means this compatibility condition passed. It does not certify the whole assembled device or program.
What carries across
Prevent a named error at the point of combination, then state clearly which other errors the check leaves possible.
Where the comparison stops
Mechanical incompatibility and a formal type judgment enforce different constraints. Neither makes all downstream behavior correct.
- Static typing is only the selected manifestation; a type system need not act before execution.
- Physical keying depends on intact geometry and the specified pairing; bypasses, damage and mistakes outside that pairing remain outside the claim.
- Type compatibility does not prove a program’s intended answer, termination or every safety property.
Conditions for this comparison
- The forbidden physical pairings have been enumerated and are actually excluded by the geometry.
- The program is checked under a stated static type system; no unchecked escape is silently treated as part of its guarantee.
Source entries
Shared pattern
Error Proofing (Poka-Yoke)
Prime
Core Idea
*shifting the burden of error prevention from human vigilance to system design*
Physical assembly
Physical Keying or Interlock
Mechanism
How it works
- Make right-fits-only the geometry. Shape connectors, slots, and keys so the correct pairing seats easily and every wrong pairing is mechanically blocked before it can complete.
Programming languages
Type System
Domain-specific abstraction
Core Idea
Each syntactic form in the language has a rule that assigns it a type given the types of its subexpressions: a function application f x is well-typed with result type B if f has type A → B and x has type A; a conditional if b then e1 else e2 is well-typed with type T if b has type Bool and both e1 and e2 have type T.
What It Is Not
- Not a guarantee that a program is correct. Milner's "well-typed programs cannot go wrong" means a precise, narrow thing: no operation is applied to an argument of the wrong kind. It does not certify that the program computes the right answer, terminates, or is free of logic errors. A well-typed program can be completely wrong about its intended behavior; type soundness bounds one class of failure, not correctness in general.