Programming Languages as Objects in Nature

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