4Developers 2017: The Babel Fish Data: A Case Study (Norbert Wójtowicz)

## Overview Norbert Wójtowicz presents a thesis that data, rather than objects, should be the foundational principle of software systems. He uses the Babel Fish metaphor from Hitchhiker's Guide to the Galaxy to illustrate how data enables different systems written in different languages to communicate. He then draws a historical parallel to scurvy—a disease eradicated in the 18th century but tragically reintroduced in the 19th century through misguided practices—to argue that programming has similarly lost the benefits of data-oriented development.

## The Core Problem The speaker argues that in the 1960s-70s, programming languages discovered functional programming, logic programming, relational databases, and garbage collection—essentially all the foundations of modern computing. However, the 1980s-90s saw the adoption of object-oriented programming (Java, C++), which reintroduced complexity and fragility. Modern software struggles with late deployments, bugs, and crashes despite having washing hands (TDD, agile, scrum). The solution is recognizing that data is the vitamin C of programming.

## Fundamental Data Structures All systems can be built from three essential data structures: 1. **Streams**: Ordered sequences that introduce temporal order 2. **Trees**: Hierarchical structures underlying all UIs, whether mobile, web, or desktop 3. **Meshes**: Interconnected graphs representing business domain relationships

The speaker illustrates with Spotify's example: three core objects (listeners, artists, songs) with everything else being relationships between them. As features accumulate, the mesh becomes denser. Collection types needed are lists (order), maps (key-value association), and sets (mathematical operations), with important distinctions between homogeneous and heterogeneous collections.

## Clojure Spec Details The talk focuses extensively on Clojure Spec, a specification library enabling: - **Validation**: Predicates that return true/false for data, with detailed error explanations showing exact failure points - **Composition**: Building complex specifications from simple ones using logical operators (and, or) - **Conforming**: Not just validating but transforming data through specification layers - **Generation**: Automatically creating valid test data matching specifications - **Function specifications**: Adding constraints to function arguments, returns, and relationships between them - **Instrumentation**: Runtime assertion checking in development/staging environments - **Test automation**: The test.check library generates hundreds of thousands of tests automatically

## Property-Based Testing Patterns Drawing from QuickCheck (developed by John Hughes), the speaker outlines testing patterns: 1. Idempotency: Repeated operations yield the same result 2. Invertibility: Operation plus its inverse returns the original value 3. Model-based testing: Verify against a simpler reference implementation 4. Business axioms: Invariants that must always hold (e.g., Facebook friendships are bidirectional) 5. Distributed system testing: Generate random event timelines, distribute across multiple clients, verify eventual consistency

Computers can generate millions of test cases revealing edge cases humans never anticipate. Shrinking automatically reduces failing cases to minimal reproducible examples.

## Front-End Architecture Application The speaker demonstrates applying these principles to front-end systems using data log as the query language. Components comprise: queries (graph queries for data), renders (pure functions returning UI trees), mutations (pure data streams), and reconciliation (pure functions transforming mutations into state snapshots). Testing occurs purely in code without running a browser, using specifications to verify layer integration. CSS testing is achieved by generating millions of data variations and rendering them.

## Takeaways Programming should be data-centric, with data treated as immutable, semantic (clear meaning), and recursive (composable). Adopting data-oriented principles, specifications, and property-based testing yields better composability, superior testing, and simpler systems.