The underlying software architecture and the motivation behind it are outlined in the whitepaper of the (more complex) gov4git project: https://github.com/gov4git/doc/blob/main/whitepaper/whitepap...

Have you looked at gocircuit.org and the accompanying language for connecting templates Escher.io? They are still not production ready, but aiming to solve your problem in a general way. The circuit simply says you should be able to write the logics that build out your software as programs against a simple live Cluster API, provided by the circuit. Escher helps mix and math such functional logics. But the bottom line is this. Every framework is a language. Adding frameworks adds complexity. This is why circuit reuses the go language for its concurrency and abstracts your cluster into a programmable dynamic data structure

Escher can have circuits with any number of communication "valves", so ternary is ok.

Yes, the handbook is a complete Escher application. It simply creates a static file hierarchy while patching snippets of things together. Escher is experimental and I am iterating on other variations too. This one however is stable and complete and people are welcome to play with it.

You can exercise the option to buy the Seaboard right away.

because it disturbs the visual perception and prevents people from glossing.

The language for expressing constraints is what different, not the meaning. People are confused because they properly evaluate that you can do with this language what you can do with any other. But only up to a point of scale. Then the bugs that other languages make you introduce catch up with you. And you can't produce more software because you have to spend too much time fixing bugs of old software. In Escher, every circuit without valves is forever closed as design: for the same reason electrical circuits are rarely recalled. Did you ever wonder why that is?

Thanks for the link!

There is a language called Escher already - http://en.wikipedia.org/wiki/Escher_(programming_language)

(Someone else just posted this information, but that comment was auto-killed.)

Choiceless Computation is how the "outside" world looks to an Escher program. This is easier to understand, if you study go circuit.org because it is a concrete product not just a semantic. There:

A program starts and sees nothingness. Then a host emerges out of nowhere. (A human provisioning engineer must have turned it on in the data center.) Then the program can do something with it (like start a database) or it can wait (indefinitely) for another emergence of a host (before it sets up an elastic DB, say). The point is that objects emerge in your "sight" and they are nameless. The namelessness is the choicelessness. And this might seem like a small difference, but it is huge.

Chomsky tells Linguists: Try to imagine the world from the new-born baby's point of view; and trust me that the baby is born knowing nothing. The only difference is that the baby sees a "blooming buzzing confusion" (i.e. many hosts are online already). But the connection is that everything is nameless (at first). The baby sees many visual pixels. They have no meaning (i.e. no linguistic names). Later the baby sorts out the confusion and assigns names to all phenomena in its sight. Same for circuit programs. They see a nameless army of live hosts. They are all equally good, hence nameless. Then the program start purposing them differently (some are dbs, some are https, etc.). This is the same as the baby assigning names to pixels in its sight until it wakes up one day at age 5, thinking it understands the world. Ha :)

Interesting. I'd love to hear some problems that this is good at solving to put it in context

That's correct. For instance, I discovered the link to Choiceless Computation AFTER I invented Escher. It is a real mathematical connection, and I only bothered with it, because academics will not look at my work unless you shove some terms of their own into it. So I do, and it is real, because you can go and verify that Shelah's paper exactly matches the sematics of Escher. And the conclusion is that Shelah's paper wasn't necessary for my invention. It was necessary to convince an audience of a specific kind. (Not that this is accomplished yet. But it will. With time.)

I say this out of genuine concern for your project: you would do well to never say "my invention" again. See: reactions to Stephen Wolfram.

I will definitely consider your comments on "speech grandiosity"! They are good points. Thank you.

Academics might look at your work, but you'll have to make lots of effort in explanation and providing context via comparisons with existing and previous work. It may or may not be worth it to you, but we aren't as unapproachable as you think; we even have a conference called Onward! for these kinds if ideas.

You never actually explain the semantics of Escher. I think this is why reading the README feels like a great setup with no payoff. Or maybe it's there, just not explained well enough.

For example, there's no comprehensible relationship to me between the "inputs" and "outputs" (if that's even what they are) in the diagrams labeled "project" and "Generalize." It looks a little like a spoof, like saying we combine {animal: cat} and {tail: orange} to get {animal: orange} and have a syllogism. Well, what is mechanically going on?

Also, you should be able to situation the programming paradigm of Escher among the vast universe of programming paradigms that have been explored. Otherwise, programmers are lost. For example, if there's no directionality to the "circle" gates, is that because they are relations, and the connections between the circles are joins? Or are they perhaps declarative constraints? There are many existing programming languages that you could be describing, most of the time, and drawing things as nested circles or giving them wacky names doesn't explain how Escher differs from other programming languages.

So it reads like Wolfram's "A New Kind of Science" -- this is "A New Kind of Programming," but reading it doesn't give me a new way to look at programming, the way it promises to.