> The problem of informal languages will not go away
...possibly because it isn't actually much of a "problem".
And of course it's also not actually "informal". Just because it's not the kind of formalism the author likes, does not make an implementation not a formalism.
And just because it isn't describable by the kind of formalism the author likes doesn't mean it is "an object of nature". It's as artificial as can get, and to get to the ground truth you can check the implementation, rather than the specification, as the implementation is the specification.
Or you can see how it operates "from the outside", which is what 99.99% of people will do with the "formally specified" language as well. Because the fact that there might be a discrepancy with a formal specification is of little to no relevance to somebody creating a program. What counts is how the machine actually behaves.
> What went wrong?
What went wrong is that the author's answer to "what went wrong" is largely irrelevant to producing useful software. I.e. if there is some evidence that formally specified languages provide significant practical benefits in that endeavour, I have yet to see them, whether in the field or in research. (So yes, there may be some conceivable or possibly even measurable benefit, but it's not in the top 5 of what makes a language useful)
Sort of unrelated to the original post, but... Wow, visited that page and... I legitimately can't tell if that is an actual project or the programming version of Time Cube. "Thanks" for sharing, I guess. :)
> can't tell if that is an actual project or the programming version of Time Cube
you and me both! you and me both!
no but seriously, lots of PL research is going on for small gains, while 2 and 3 dimensional languages are a complete blue ocean of opportunity. mostly right now it's me and a few others splashing around. but the crowds will figure it out eventually.
...possibly because it isn't actually much of a "problem".
And of course it's also not actually "informal". Just because it's not the kind of formalism the author likes, does not make an implementation not a formalism.
And just because it isn't describable by the kind of formalism the author likes doesn't mean it is "an object of nature". It's as artificial as can get, and to get to the ground truth you can check the implementation, rather than the specification, as the implementation is the specification.
Or you can see how it operates "from the outside", which is what 99.99% of people will do with the "formally specified" language as well. Because the fact that there might be a discrepancy with a formal specification is of little to no relevance to somebody creating a program. What counts is how the machine actually behaves.
> What went wrong?
What went wrong is that the author's answer to "what went wrong" is largely irrelevant to producing useful software. I.e. if there is some evidence that formally specified languages provide significant practical benefits in that endeavour, I have yet to see them, whether in the field or in research. (So yes, there may be some conceivable or possibly even measurable benefit, but it's not in the top 5 of what makes a language useful)