Author claims type adds nothing beyond relational membership and can be dropped as a special construct

The article argues that type is not a special construct but rather a form of relational membership, meaning that any property usually ascribed to a type can be expressed as a predicate on values. It notes that historically type systems were added to fix problems caused by overly restrictive or presumptuous foundations, such as Russell’s paradox, which arises from assuming every formula has a well-defined value. The same logical machinery that blocks self-referential contradictions like f(x) = not f(x) also blocks the problematic formula behind Russell’s paradox. Consequently, the author sees type as baggage that can be removed by addressing the underlying cause instead of adding layers.

Adopting the view that type is relational would require replacing conventional type checking with ordinary predicate evaluation within a unified relational logic framework. This shift could impose costs on existing language implementations, as compilers and interpreters would need to be rewritten to handle type information as regular facts and rules rather than as a separate phase. Engineers might lose the ergonomic benefits that dedicated type systems have provided, such as concise syntax for common constraints and early error messages that rely on distinct compile-time reasoning.

The argument stops working when a decent relational representation is not available or becomes excessively complex, making it impractical to encode all desired properties as simple predicates. Moreover, the author acknowledges an important exception: type still captures what the programmer knows at write time, which may not be fully derivable from runtime values alone. In situations where separate compile-time guarantees are essential, such as ensuring absence of certain errors before execution, the unified approach may not provide the same level of assurance.

Overall, the proposal invites engineers to reconsider the necessity of distinct type layers and to explore designs where compile-time and run-time reasoning share the same relational substrate. If the relational machinery can faithfully express all needed properties, the resulting systems could be simpler and more uniform. However, any implementation must verify that the relational approach does not sacrifice the practical guarantees that motivated the original introduction of type systems.