[petar]

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

[msutherl]

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.

[petar]

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

[seanmcdirmid]

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.

[dgreensp]

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.