ė - Goal and Overview
The goal of this project is to program computers using pluggable units of software.
To do this we need:
- micro-concurrency
- 0D
- layers, relative sofware units
- multiple languages.
Hello World
Very simple example
Leaf
Container
Re-Architecting
Scalability
Pluggability is necessary for scalability, but, more elaborate (complicated) examples are needed.
Benefits
- 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
Key Insights
- 0D - No Dependencies
- FIFOs and LIFOs
- Pipelines
- Structured Message Passing
- "First Principles Thinking"
- Closures
- "Parallelism" is composed of more than one concept
Approach
Formulate questions
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?
Synthesize
- 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
- https://github.com/guitarvydas/das2json
- 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
- https://github.com/guitarvydas/das
- 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)
- https://github.com/guitarvydas/vsh
- 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)
- pipelines
- 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)
- micro-concurrency
- 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
Status
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.