Out of the Tar Pit

---

https://curtclifton.net/papers/MoseleyMarks06a.pdf

• research paper from 2006 on the complexity of software
• complexity comes from
  1. state (data about the program)
  2. control (how the logic of the program flows)
  3. code volume (complexity breeds complexity, compounding of the above two)

object-oriented programming

• complects state and control and could be multiple ways to affect state
  • also complects identity with state (value objects vs. intentional identity)

functional programing

• completely avoids state and side-effects and as such, gains referential transparency (given same input, always return same output)
• when state is required, it is passed on as an extra parameter to the function. this set of extra parameters can become arbitrarily large and thus loses the ease of control that it promises

logic programming

• purely declarative (make statements about the problem and desired solutions)
• promises escape from the “control” problem because no explicit ordering

proposal

• in the ideal world, you can just specify requirements and what you want to happen (this is basically declarative programming in the ideal)
  • the infrastructure and system should handle this
• In this world,

  “All data will either be provided directly to the system (input) or derived. Additionally, derived data is either immutable (if the data is intended only for display) or mutable (if explicit reference is made within the requirements to the ability of users to update that data).”

• derived data is accidental state, thus not all data provided by user is essential

• “Because of this, and the huge complexity which state can cause, the ideal world removes all non-essential state. There is no other state at all. No caches, no stores of derived calculations of any kind. One e↵ect of this is that all the state in the system is visible to the user of (or person testing) the system (because inputs can reasonably be expected to be visible in ways which internal cached state normally is not)”

  • this is interesting and almost what coda does where all the inputs are available to the user (but also they have to make the derived states and then hide them manually) but i guess this is the draw of this kind of program, where you can create doc where the user only has to worry about their input (their state that they are bringing) and the program magically figures out what to do with it. The user has full control over their input and doesn’t have to worry about any of the internal workings of things (as long as the program is correct)
• the tradeoffs to doing this are:
  1. performance (having to re-derive values to use them is not efficient)
  2. ease of expression (the most “ideal” may not be the easiest to express) recommendation: avoid state and control whenever possible and separate them from the rest of the system whenever absolutely necessary

Relational Model

• It has nothing to do with databases specifically, instead it is “an elegant approach to structuring data, a means for manipulating such data, and a mechanism for maintaining integrity and consistency of state.”
  • it also clearly separates logical and physical layer of system
• (sql is not an accurate reflection of this lol)

The model is composed of the following components

relations

• homogenous set of records, which are sets of attributes.
  • relations have no duplicates and no ordering
• can be either
  1. base relations (stored directly)
  2. derived relations (views)
• expression via relations is nice because it doesn’t specify the access path (how to query / process data)
• no distinction made between entities and relationships

manipulation

• relational calculus and algebra
  • close to math operations?

integrity

• specifying a set of constraints which must hold at all times
  • e.g. primary key / foreign key
  • Notably, imperative mechanisms for enforcing this (such as triggers) are not included

data independence

• principle of separating the logical model from the physical storage representation

Functional Relational Programming

• all essential state takes form of relations and essential logic expressed using relational algebra (extended with pure user-defined functions)
• concept of “Feeders” (cause change to essential state via new inputs) and “Observers” (generate output in response to changes when an observed state changes)
• essential state is only input directly by the user
• this is eerily similar to coda’s formula language