ė - Goal and Overview
The goal of this project is to program computers using pluggable units of software.
To do this we need:
- layers, relative sofware units
- multiple languages.
Very simple example
Pluggability is necessary for scalability, but, more elaborate (complicated) examples are needed.
- technical drawings come "for free"
- concurrency comes "for free"
- "build and forget" development
- distributed programming comes "for free"
- multiple-CPU paradigm
- ability to plug together software components to create mimimal set of functionality
- 0D - No Dependencies
- FIFOs and LIFOs
- Structured Message Passing
- "First Principles Thinking"
- "Parallelism" is composed of more than one concept
Questions such as...
Why do hardware designs tend to work while software designs fail and become more complicated?
Pipelines are different from functions. How are pipelines different?
Message passing. Is message-passing possible in the synchronous paradigm?
Message passing - asynchronous - has a bad rep because it is often ad-hoc. Is there an equivalent to "structured programming" for async message-passing?
Closures - are closures the same as "processes" in operating systems?
DaS - Diagrams as Syntax. Why are most programming languages textual?
Tells - what is currently considered difficult? Multitasking, async, callbacks, mutation, sequencing, history, state ... Can these be improved? Are they difficult because they're difficult or because our notation makes them difficult?
Is "something" the same across all programming languages?
What is parallelism?
Operating Systems and Programming Languages were invented in the 1950's under the single-cpu assumption. Is the single-cpu assumption still valid?
Are end-users forced to use the "same" operating systems / computer environments as developers?
Can the goal (pluggable components) be sub-divided into smaller sub-goals?
- Which properties must components have to be pluggable?
- Which properties inhibit pluggability?
- upon answering the above questions, it is possible to synthesize a new programming environment?
Tools / POCs
Tools and Proofs of Concept that are related to this project but not part of the 1-week Jam
- transpiles diagram testbench.drawio to JSON
- transpiles diagram helloworld.drawio to JSON
- uses hybrid diagram elements containing Python code
- boxes, connections, ports written as a diagram
- "Leaf" code written as Python (embedded in the diagrams)
- the diagrams are hybrids - boxes + ports + lines + Python code
- i.e. micro-concurrency written in diagram form, the rest written as regular Python code
- do the minimum necessary, and let Python do the rest of the heavy lifting
- uses PROLOG inferencing to create a factbase, including containment and connection relationships
- could be simplified, probably with Ohm-JS
- similar to above, except slightly more ambitious
- transpiles helloworld.drawio to Python, then runs the Python
- transpiles d2py.drawio to Python, then runs the Python
- d2py.drawio is a "script" for self-compiling the das-to-python transpiler to Python
- the resulting Python script calls "make" for building the transpiler
- the diagram shows one way to trap errors and quit
- the UX (the diagram language syntax) could be more humane - at the moment, it consists of boxes and lines which might look "too complicated" to non-programmers (thought: maybe rely on box containment to "inherit" messages, eliding some of the ports and lines)
- checkout afa53b8
- contains very old (pre-2013) Visual SHell experiment
- diagram compiler written in itself (using yEd editor)
- generates .gsh files
- .gsh is grash a minimal (approx 8 instruction) assembler for invoking UNIX C system functions (e.g. dup2(), exec(), etc.)
- (I ran out of time during this Jam to make this work again)
- see UNIX shells
- see Aho's paper on using pipeline syntax as a replacement for Denotational Semantics syntax
- (I ran out of time to dig up this reference during this Jam)
- partially based on implementing Harel StateCharts
- partially based on Holt's book Concurrent Euclid, UNIX, Tunis
- partially based on designing hardware using state machine diagrams
- "sequencing" and "concurrency" is "easy" with state diagrams, less easy with functional notation
- conclusions about 0D and "parallelism"
- HSM - Hierarchical State Machines
This project is essentially about joining the pieces of the project into a coherent whole.
- Most of the pieces are on the floor (see sub-projects in detailed documentation) and getting simpler with each iteration.
- Currently working on Python version of Leaf components using HSMs (hierarchical state machines), trying to simplify HSM P.O.C.