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.
- compilation toolchain (W3C standards)
- modules: system
- modules: system.ui
- modules: ext.lib
(built on, and commited to, Web Standards)
Sustained long range R&D.
Architecture, API's, and other conceptual primmitives will change (almost certainly radically 🐷) prior to any 1.x.
Whilst the author(s) have been in diverse, exploratory dialogue with LLM's since November of 2022, this repo contains no "copypasta" of direct output from an LLM (or any related so called "AI" technology).
Informed, augmented, yes...but no abdication of direct human: discipline, creativity, coherence.
| repo | status | |
|---|---|---|
| ● | platform-0.2.0-alpha | current |
| ○ | platform-0.1.0 | previous |
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 (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.
The following global commands run from the root of the project and operate on all nested sub-modules of the system within this monorepo.
These commands constitute the primary CI (continuous integration) pipeline.
See github action
which protects the main branch when merging in PRs (pull-requests).
A security audit on the up-stream dependencies is performed on each CI cycle.
$ yarn audit <= security checks
$ yarn build
$ yarn test
To run all of these locally within a single command:
$ yarn ciTo see the layout of the module namespace, and related meta-data, run the list command:
$ yarn ls <= Sorted alphabetically
$ yarn ls --topo <= Topologically sorted on the module dependency graph (depth-first)
The topologically sorted option (--topo) shows the build order used when running the compiler over each module (global yarn build).
Here the usage of the term "compiler" flexibly maps to any kind of code transpiling activity, from module bundling through to binary compilation (eg, rust/wasm).
NOTES: the system currently uses node.js for build tool-chain bootstrapping only. Once the Typescript compiler
and ESM module bundler is bootstrapped into existence, the dependency on node.js falls away. Put another way, node.js is intentionally not a fundamental dependency (although node.js is not going away anytime soon of course). It bootstraps us into the W3C/JS runtimes standard.
There is much healthy innovation emerging around the eco-system of Web standards runtimes outside of the browser (ref WinterCG). Particularly around runtime security properties, and isolated/safe code execution (with pathways to being able to make auditable claims about the security of what code ran, and where, under what contexts).
In the arena of remote code-module execution on either user-controlled machines, or in cloud-like environments, within the runtime context of Web Standards JavaScript/WASM, deno has some interesting and important security characteristics that makes it preferable to node.js. In any event, the module/packaging structure of the system conforms with the open-commons ECMAScript "ESM Module" standard keeping it flexible to any and all future runtimes that may proliferate around web-standards (see WinterCG).
UI Framework Agnostic: In the arena of user-interface, particular attention is placed on maintaining a loose coupling with any one UI rendering library. And UI modules (system.ui) are partitioned clearly as distinct to the pure functional "logic only" libraries (system). This is because UI invariably tends towards a much higher volatility in technical architecutre over time, and is generally swapped out more frequently over the software lifecycle. Any form of "interface" (the I in API) tends toward messiness, noise, and complexity - the one involving the "humans" (UI) is especially prone. And down at the straight forward engineering level, much hidden complexity is often lurking in and around UI code.
Organizing for all this is expressed within the distinct folders /sys/ and /sys.ui/ in the code root. The purpose of the system.ui's child-folder structure is to isolate and callout by name each core UI rendering technology of the libraries contained within: <technology-name>.<lib-name>, for example:
/code/
|- system/
|- system.ui/
|- <type>.*/ <== prefix calls out the particular tech/lib being "ring fenced."
|- react.*/ <== (libs)
|- svelte.*/ <== (libs)
This is a general theme of the system, to think of commitments to technology choices in as abstract and forward looking a way as possible.
Obviously to pragamaitcally achieve anything, committments to certain technologies do need to be made in any given moment. But careful, and sustained
attention while making these kinds of calls can also ensure the long-term time runway, where the "idea" itself remains consistent, but the implementation
choices can be swapped out and evolved over time. This is the ideal at least; AND "reality is a bitch!" and engineering tends to throw up "gnarly problems" on an all too regular basis. Yet, "evolution" is a messy process, and we find spontaneosly emerging self-cleaning, self-maintaing creative ecosystems right across nature - so this is a feature of reality that can totally be coaxed (encouraged) into stable forms of existence.
Development machine environment setup suggestions.
The system (platform) lives as an "open commons" shared resource for the world. As such the core modules of the system are open source (OSS) and all up-stream dependencies conform with transitively equivalent OSS licences.
In the case of this repo the baseline is the MIT Licence, and when evolving the licencing strategy through considered refinement over time, will move toward the attractor of "more free" as in individual freedoms ("libre") kind of free.
To run a "licence analysis" and validate the module depenency graph against this principle run:
$ yarn mitref: fossa configuration docs
License - MIT
For a scintillating break down of this open-source classic, treat yourself to Kyle E. Mitchell's
"The MIT License line-by-line. 171 words every programmer should understand."