Generalizing Knuth's Pseudocode Architecture From Algorithms to Knowledge(researchgate.net)
researchgate.net
Generalizing Knuth's Pseudocode Architecture From Algorithms to Knowledge
https://www.researchgate.net/publication/401189185_Towards_a_Generalization_of_Knuth%27s_Pseudocode_Architecture_From_Algorithms_to_Knowledge
6 comments
Since turnabout is fair play, I asked Gemini Pro to save me some time on the obviously vibe-written paper:
> on a scale of 1 to 10, 1 being crackpot nonsense, 10 being genuine insight presented in a novel but accessible manner, where does this paper fall
The paper scores a 4 out of 10. It proposes Lingenic, a notation mixing formal logic and natural language to represent knowledge, much like Knuth's pseudocode does for algorithms. The author argues that modern AI is the first reader capable of understanding this hybrid.
The assessment is that the paper fails structurally. It assumes broad, general knowledge maps perfectly to the narrow logic of algorithms. Furthermore, the formal examples in the text are just plain words wrapped in pseudo-mathematical symbols. It is an aesthetic choice masquerading as a new architecture.I tried my best to get an introduction to using Lingenic, but this paper assumes you are already proficient with Lingenic. Lingenic.com: I spent time searching there, and managed to get everything except an introduction on how to read it. Why: that's documented. What didn't work: that's documented. How to read it: I'm still trying to find that.
It is hard for me to see how "formal structure combined with natural language content" can ever be different from "code with comments". Code often indeed requires comments but it's hard to see how any real generalization is possible from this.
The problem is semantic ambiguity, ie. which sense of a noun/verb (concept/operator/function/relation) is meant. The concepts inside the syntax in the paper are still ambiguous.
Also underspecification in general - having a formal syntax does nothing to address this. Both formal and natural language specifications can and commonly are incomplete.
Don't see anything in this proposal to address that. (and any solution probably applies to natural language syntax as well)
The only problem with (formal) natural language syntax these days is that it's a bit too verbose and harder to read (ironically) compared to more math-y/codey ones.