|
|
|
|
|
by dgreensp
4345 days ago
|
|
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. |
|