The Timeless Philosophy

The philosophy that describes how and why we consider design choices the way we do effects everything downstream of it.

We consider some traits essential: Reliability. Reviewability.

// Note: this page is a draft.

reliable

referencable

like a (old, brick-and-mortar, filled with books) library. we expect to be able to refer to things, and once having a reference, we expect it to not change. we need to be able to embed this reference in other documents, and having them construct a chain of facts which are themselves referencable.

(the “things” here will turn out to be not just data, but computation as well; especially the computations that compile our tools for more computation on more data!)

reviewable

supports reasoning about its overall flow statically

un-degrading

undecaying, uncorruptable, without deterioration.

temporal context may not be bound.

that “ability to reason about statically” property must hold regardless of time.

(spoiler alert: this is why the whole project is called “the timeless stack”.)

reproducible by design

temporal context may not be bound!

this is to some degree a restatement of “referencable”, but explicitly more expansive: we want to be able to use our references to construct plans to produce more data; and we want to be able to reasonably expect – or failing that, at least test – or best yet, both – that these plans will be for processes that are reproducible.

it is important not just to state this principles, nor merely to follow them to the best of our abilities: it is critical to build tools that force us to notice quickly should we falter.

composable

unencumbered products

sort of the converse of composable; we want the products of our systems to be usable without a support network.

each package should be a prepper xD

this doesn’t come up quite so much in repeatr and core tools, but it’s a huge piece of guidance when it comes to packaging style recommendations and the radix project.

decentralized authorship

social! no presuming of monorepos.

offline anytime

general

“builds” are a function from fileset to fileset.

builds are not the only thing that matches this description.

this is a large distinction from most other projects currently pursuing reproducible builds: (linux-)distribution driven approaches consider builds a function from packages to package, and the result is a system that’s much less reusable, has much more emotional baggage, is more likely to capture other properties regarding which there are validly distinct PoVs, much higher complexity, a greater tendency to culturally slip into (crippling) acceptance of side-effects (for reasons that may be valid for some user stories in a distro, but are entirely orthagonal to the question of builds/fncompute)…


some aphorisms:

  • Updating shouldn’t bring you anxiety.