Monorepo comprising the core set of shared /sys "system" modules that flexibly compose into varying arrangements of (1) extremely-late-bound, (2) strongly typed, (3) decentralised, "cell like" functional processes.
- modules: sys ← standard libs
- modules: sys.ui
- modules: sys.driver
- build toolchain (output → W3C/ECMA standards)
(✊🏻💯 ) Built on, and mission-locked to modern, portable, Web Standards.
Sustained long range R&D
Architecture, API's, and other conceptual primmitives will change (almost certainly radically 🐷) prior to any 1.x.
| repo | status | |
|---|---|---|
| ● | sys | current 🧫 |
| ○ | ↑ platform-0.2.0 | previous |
| ○ | ↑ platform-0.1.0 | previous |
General immutability pattern.
See full type definitions: @sys/types
In its basic usage pattern:
type T = { count: number }
foo.current // === { count: 0 }
foo.change((d) => d.count++) // Σ | safe mutation
foo.current // === { count: 1 }...and with a more flavor to the shape and characteristics of the Immutable<T> design pattern primitive (which is used extensively across the system for strongly typed manipulation of state).
A broad number of diverse (and divergent) systems can be driven by this one single "safe" state manipulation pattern.
Below shows how an Immutable<T> of JSON is declared, listened to, manipulated, and then ultimately disposed of (lifecycle):
type Immutable<T> = {
current: T
change(fn: Mutator<T>): void
listen(): Events<T>
}
type T = { count: number }
// Generator<T> over some immutability strategy
// (typically an external library's implementation, see namespace: `@sys/driver-*`).
const foo = Generator.create<T>({ count: 0 }) // ← Immutable<T>
/**
* Imutable change pattern.
* (safely mutate a proxy).
*/
foo.current; // === { count: 0 } ↓
foo.change((d) => d.count = 123); // Σ | ← safe mutation
foo.current; // === { count: 123 } ↓
// Strongly typed Event<T> stream observable: 💦
const events = thing.listen(): Events<T>
events.$.subscribe((e) => { /* event stream handler */ });
/**
* ↑ 💦
*
* Stream of Patch<T> changes optionally available,
* eg. "RFC-6902 JSON patch standard".
*
* The Events<T> library itself enshrines the meaning of the message stream
* conceptually through domain specific, pre-canned, stongly typed properties
* and methods of functional filters/helpers.
*/
// Finished.
events.dispose();
Open System.
Open Commons.
Doug McIlroy's as quoted by Salus in "A Quarter Century of Unix" (ref):
- Write programs that do one thing and do it well.
- Write programs to work together.
- Write programs to handle text streams, because that is a universal interface.
Doug McIlroy's 4-point formulation of the Unix Philosophy:
-
Make each program do one thing well.
To do a new job, build afresh rather than complicate old programs by adding new features. -
Expect the output of every program to become the input to another, as yet unknown, program.
Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input. -
Design and build software, even operating systems, to be tried early, ideally within weeks.
Don’t hesitate to throw away the clumsy parts and rebuild them. -
Use tools in preference to unskilled help to lighten a programming task,
Even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.
- Modularity
- Cohesion
- (Good) Seperation of Concerns
- (Good) Lines of Abstraction ← aka. information hiding
- Loose Coupling
"libraries not frameworks"
An orientation toward framework agnosticism (which is the choise default in most circumstances). Then levered by a simple/strict extensino pattern, (eg. "drivers") as appropriate to the module's domain, technology, and constraints.
"Extracting energy from the turing tarpit" (Alan Kay)
"Architecture can transcend architecture" - (Turing ← Alan Kay)
- video Alan Kay, "Learning and Computer Science", 1970s, video Alan Kay, 2011, "Programming and Scaling"
- paper Alan Kay, 1984, "Opening the Hood of a Word Processor"
- video David Clark (1960's vs. 1970/80's)
"But what's interesting, is once the engineers got a hold, the visionaries went away (timestamp)" - video Crockford (2011) - "JSON [as the] intersection of all modern programming languages (timestamp)"
- video SmallTalk (1976, 1980), only three primitive concepts. Everything is an object*, everything is a "message", be as extremely late-bound as possible. Build everything else up and out of that (aka. LISP-ey).
*NB: "object" meaning the original SmallTalk conception of "object," not the later "OOP" notions that emerged in the following decades (ref.related).
Augmenting Human Intellect: A Conceptual Framework
1962, Douglas C. Engelbart, SRI Summary Report - ref
“We refer to a way of life in an integrated domain where hunches, cut-and-try, intangibles and human “feel for a situation” usefully co-exist with powerful concepts, streamlined terminology and notation, sophisticated methods, and high-powered electronic aids.
(aka. the "all of us"). Diverse social/relational networks of people, across scales. "People" not "users."
Initial high fidelity design emphasis on the 1:1 (dyad) and 1:3 (tradic tendencies) as graph/network primitives.
Identity is not one simple reductive thing (or a "rented" database ID owned by some arbitrary vendor). Each and every one of us inhabit many contexturally dependent and diverse identities. Overall system design must ultimately bridge all the way to that complexity if it is to be of enduring value.
“I am large, I contain multitudes” - 1892, Walt Whitman
A complex system that works is invariably found to have evolved from a simple system that worked. - ref
The inverse proposition also appears to be true:
A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a simple system that works.
"Framework" agnostic. Web standards.
License, MIT.
To understand the context around MIT Licence ("an open-source classic")
see Kyle E. Mitchell's
"The MIT License line-by-line. 171 words every programmer should understand."