petar

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.

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

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!

Yes. Be patient a few more weeks, as I have other obligations too. I will have demos how you can make your own gesture-controlled robotics at home, using Escher bindings for the gobot.io library

I apologize, if it's a little over the top. But being over the top is the only way to get people to really think: out of anger to prove you wrong. It's just true. But I have no intention to offend anyone.

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 :)

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.)

Thanks for the link! It's time to meet my peers. I will say to all people who find similarities between my work and cognitive scientists or neuroscientists: I have never read a line of text on either of these subjects, nor have I ever read anything written by Chomsky (other than email exchanges). I've only listened to Chomsky's you tube vides and skimmed the titles of his book. This was suggestive enough.

I am glad. The truth is: Eventually every mind, in trying to save itself from "repetitive" work, reaches the same conclusion: recursive metaphorical programming. It comes out in different buzz words "flow-programming", "metaphor mechanics", etc. They are all fuzzy but roughly correct. The only way to propose a theory of 1st-person consciousness, which is not ambiguous (the theory as communicated to others), is to give a programming language. This supersedes a philosophy paper that no one reads and is predicated on the author's "knowledge". And if the author is an academic, they can just assume "people don't know math" and people assume "we don't know math", so no knowledge is transferred at all.

Yes. All the functional programming language had the right idea (as you point out). But not the right grammar. Escher has 3 grammar rules (reflex, circuit and valve). All these other languages have much much more. That's the point.

The whole point is that the gate-designer decides if their gate works in various directions (there are usually much more than 2 or 3). And this simply means that if they get a stream of events coming in in the wrong order, they can choose how to "complain": They can stay silent and ignore the broken language sent to them. Or they can throw a panic and halt the entire program. You decide. The NAND gate makes little sense to go in anything but one direction. But a PLUS gate or the REASON gate make sense in multiple directions. You can read more about this here: http://www.maymounkov.org/memex/abstract

It looks familiar to every other language you know and yet to no one in specific. That's the point: It unifies them all as a common denominator and you have to break out of your conventional thinking to see the differences. Alternatively, you have to try to write many programs in Escher and then you will gradually start "getting it"

Yes: At a smentic linguistic level. Not as a physical substance. At which point you ask: What is a physical substance formally? Well, that depends on your dictionary of the world. Cognition is relative, people don't get that :) There is no absolute knowledge. There are only interpretations of individual participants. And our programming languages have to reflect that.

Not incidentally. The Voynich manuscript simply demonstrates that if you mix concepts at all scales of visual perception (color, texture, page organization, etc.) the document looks un-intelligible yet familiar. Incidentally, so do Escher's painting, and so does my documentation (to you). Now think about why? Think about Escher-Godel-Bach, think think :)

Time is my only limited resource. Which is why it is poorly presented. Don't forget to notice that along-side Escher (which took 2 years to invent) I am maintaining

  https://github.com/gocircuit/circuit

Which is a major piece of software that earns me my salary. if you kickstart what I want to be a non-profit software research foundation, gocircuit.org and escher.io, then the doc would be brilliant and interactive in no time flat :)

I am the guy. And this is not a joke. And the fact that I am making fun of academia is not co-incidental. The point is that I am using academia's own insights to bridge a major gap. Academia (say Theoretical Computer Scientists) don't take their next-door neighbors (the Linguists) seriously. This is why they can never invent what they want: the mind. If they ever collaborated, the singularity would be long behind us.

This discussion is about standards of presentation. Not technologies for rendering. An HTML document written today, will benefit retro-actively from better font rendering in your browser in 1 year. However, a Latex paper written today, will not benefit in any way from technologies invented after you typeset the paper.

(The author:) This issue is all about interfaces. To "use HTML" does not mean "write your papers in HTML". It means "present the final result in an HTML-compatible format", so that any user could view it seamlessly and fluidly. Fluidly means they should be able to click on a citation and see it appear e.g.

The HTML standard, which expressly makes room for foreign technologies, when viewed as a standard is immensely more powerful than good old Latex. And in fact, if typesetting is your concern, you will already find JS libraries addressing this.

The big thing is: the HTML standard allows for future technologies to be embedded in your docs. The Latex linguistic ecosystem does not.

This point is only made clearer when one realizes that the end goal "to have a paper in my hand" is an artifact of past technologies. Going forward, "having a paper in your hands" will not stand as the end-goal of intellectual effort. Most certainly, intellectual work will have to be presented in a (a) standardized and (b) highly accessible and (c) highly interactive manner. Only HTML fits the bill.

It is clear that academia will switch to HTML. I am just saying: Get on with it. Why wait.

Let's just say that Ronald Rivest cannot answer your question, so the claim here is "If you believe the soundness of RSA (or any crypto for that matter), then you should believe TripleSec." This, of course, is because they are all based on the same axiomatic assumptions, which should leave you wanting to crack a book open.

Consider using the gocircuit.org

It was expressly designed to avoid non-essential technical problems that come in the way of cloud application developers, when they try to orchestrate algorithms across multiple machines.

Identical HBASE SQL queries and their respective counterparts implemented in the Circuit Language are: Approximately equally long in code, and orders of magnitude faster than HBASE. In both cases, the data is pulled out of the same HBASE cluster for fair comparison.

NYC and Washington, DC. Full-time and internship.

The Go Circuit (http://gocircuit.org) is hiring Systems Engineers.

Original job posting: http://blog.gocircuit.org/job-system-engineer

PROJECT

The Go Circuit is a development, distribution and execution environment for a new generation of self-sustained distributed applications. The circuit is built almost entirely in the Go language with occasional appearances of C and C++. It spans the entire lifecycle of an application, from development to execution and sustanance. It comprises technologies like compilers, interpreters, optimizers, low-level operating system management, distributed resource sharing, information flow, security, and many others. The Go Circuit is, by design, open source.

The goal of the circuit is to enable the possibility of encoding an entire Internet company's infrastructure in a single executable, which can be revived with a single click on an ice-cold cluster of empty hardware and can sustain itself indefinitely, without human involvement, short of the requisite replacement of hardware now and again.

The demonstrated, over the past year, power of the circuit environment has compelled industry, academic and government institutions to sponsor the project and become involved with large-scale deployments. We are, henceforth, expanding.

RESPONSIBILITIES

Full-time and internship candidates have identical responsibilities.

Systems Engineers will work alongside the founding system architect on all aspects of the technology: design, implementation, testing, fixing bugs, writing integration drivers, documentation and research. All of their work will be open-sourced. Almost all code will be written in Go, however, other languages like Python, C, C++, Lua, JavaScript, etc. will make a presence.

System Engineers will be researchers as well. In designing the semantic and linguistic interfaces of the circuit, we investigate past and present, scientific and industrial, literature and software on a wide range of algorithmic topics to help us inform and verify our choices.

QUALIFICATIONS

The ideal candidate, full-time and internship, would meet the following criteria, or demonstrate an equivalent level of technical sophistication:

* Full-time candidates should have B.A./B.Sc., M.A./M.Sc. or Ph.D. in some hard science. Internship candidates, who are near the completion of their studies towards the mentioned degrees, are also elligible.

* Four or more years of experience with a low-level/systems programming language like C, C++, or Java as well as some experience in building systems, small or big alike, is quite desirable. Altenratively, a serious involvement with a more exotic concurrent or research language, like Haskell or Erlang, would work as well.

* Having a non-trivial open-source project (in any language) would be highly valued.

* Some understanding of how UNIX operating kernels and systems work on the inside. (You don't need to be a specialist.)

* Knowledge of current industrial open-source technologies is good albeit not a deal-breaker. However, interest and desire to learn and hack some of them will be needed.

* Ability to read academic publications in Computer Science

Most importantly, we are looking for individuals who are able and willing to learn fast and have open flexible minds. On that note, we do not expect that you have prior Go experience, however we do expect that

* Candidates will come prepared to carry out the interview in Go.

We are not going to test your Go-intricacies skills. We simply expect that you be able to implement your solutions to our programming riddles in Go.

COMPENSATION

Compensation will vary based on experience as we welcome both out-of-college engineers and seasoned industry scientists. That said, compensation and benefits will be on par with the standard amongst institutions like Google, IBM, Microsoft and such. Location

To apply, please, send your vitae and anything else you want to say to Petar at p@gocircuit.org.

Just remove this word from the article. Everything should make sense fine without it.

Reference for which? The meaning of "tinkling" or the claim made in the sentence that contains it?

faintly entlightening