Data Abstractions

This is a subtle topic at the very core of all programming. Another one is interpreters, which are the universal machines.

There is a “molecular interpreter” of RNA sequences (a set of enzymes, which are sets of particularly folded /proteins) in every single cell on the planet.

And guess what? RNA is a linear sequence, with distinct “start” and “stop” markers, so it can be “read” (using what we call structural pattern-matching) in only one direction.

The early LISP guys at Stanford were greatly inspired with these discoveries of their colleagues at MIT back then - seems like all Life is made out of linear LIST-like structures – both the data and the code!, which can be thought off as a bunch of connected arrows (implies a direction, which establishes a particular order).

Lets start with some quotes.

“Data dominates. If you’ve chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming.” — Rob Pike

“I tend to “grow” programs rather than think them out completely before writing them. This way I don’t tend to make large mistakes before I discover that things have gone wrong. Above all, it’s fun, I get immediate feedback, and I see whether my ideas work as soon as I have typed in the program.” — Joe Armstrong

Yes, algorithms follow the data structures, just as our minds follow What Is (at least they should, to be less confused and infested with socially constructed bullshit and memes).

This, however, is only the beginning of the story. The most important thing is that we have to design just right abstraction barriers to separate our abstractions (the use) from their actual representations (implementation details).

It does not matter whether you are using “classes (which define abstract interfaces) and objects”, or “modules (with export ADTs) and values”. The underlying principle of partitioning with abstraction barriers (with “gated” cell membranes) is the same.

It turns out that “classes with inheritance” are more rigid and “artificial” than “composition of values” and “duck-typing”, which is more “natural” - like a Duck, you know!

The distinction is rather profound and deeply philosophical - not everything in the world falls into rigid classification of proper set-subset relations or nesting. Lots of “things” and related concepts interleave, which means that composition (a set union) is the main operation, not just nesting (a proper subset).

So, smart people build their programs around composition, not inheritance. And yes, nesting is the second most important “universal pattern”. You should compose interfaces (a minimal one is a unary function), traits or type-classes, which are ways to formally specify that “duck-typing”.

This is the first subtlety, which turns out to be fundamental and universal. “Socrates is a man” and other naive rigid classifications are not enough to properly describe every aspect of the world.

But, again, both OOP and FP partition the universe of values, both horizontally (with types, defined by abstract interfaces) and vertically (with layers of abstractions, defined as functional DSLs).

This helps you to actually grow your programs as layers of “domain-specific languages”. The main principle for this is to interact only with the one level “below” and assume nothing about potential levels “above”.

The Set Theory and First Order Propositional Logic are DSLs, embedded in (within) mathematics. Together with functions (operations) they are enough to define all possible kinds of /types which are out there. Think about it.

Why? Because named subsets of values (distinct partitions), which is what types are, has to be defined in terms of a particular set of operations, which are valid for all values (in a type).

This is precisely how mathematicians create their ephemeral abstractions (they don’t even bother with actual existence, leave alone representations or implementations of such abstractions, only we – good programmers – do).

So, it is sets of required (to be implemented) type-signatures, packaged as modules, or type-classes, or traits, not the “primitive machine types” that are central to all high-level programming.

Realizing this will make your life as a good programmer a lot happier.