|
|
|
|
|
by marginalia_nu
1195 days ago
|
|
This type of well-defined language actually predates computers by several thousand years. Even way back in antiquity they used "programming languages" like these to get around the inherent ambiguities of natural language. Originally as formulaic syllogisms and Aristotelian logic, but then onto other forms of codified language, formal logic etc. Adding more words often makes things less clear, not more so. What you need is well-defined terms with no overloaded meaning. > (We already program in English, in a sense, when we tell humans what we want, and they go code it. Now we'll just be telling machines.) Humans get it wrong all the time though. A great many bugs arise from quite simply misinterpreting the requirements. Which leads to requirements becoming more formulaic and resembling a programming language. |
|
Plus also most math and logic is still communicated and developed in a mix of human languages (English etc) and ad-hoc, not rigoursly defined notation; it's nowhere near the precision of a programming language.
Though you CAN of course grind it out at that level, if you want, but it's very unwieldy and not how people actually work.
If you're looking to deduce some sort of proof from well-defined principles and you wish to eliminate the possibility of error, then sure well-defined terms (a rigorous language) is useful.
If you're looking to produce a sofwtare artifact, just saying what you want in high-level terms and providing iterative natural language feedback is going to work great and be way nicer than trying to formalize everything.
(Maybe not true for low-level plumbing and things that need to be secure. But for like "build an app", "build a game", "make a shell script that does x", I think it will certainly end up being true.)