ė - 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

Leaf

Container

Container

Re-Architecting

Container With Different Routing

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.

much more detail, discussion, references