In 100 years, I expect programming languages will be mostly obsolete, since computers will be able to translate natural language into machine instructions with 100% effectiveness.
So they will translate imprecise natural language to buggy business logic, great. :)
In my experience, between envisioning a new product/feature (at the product management level) and actually implementing it (at the engineering level) there's always the stage where the engineers discover that the PM's requirements and acceptance criteria are not precise enough and there are dozens of edge cases where additional input by the PM is needed in order to decide how the software should behave.
Sure, the AI could recognize those edge cases, ask the PM for what they want, and therefore help them spec out the entire application in natural language. That spec will then become the source of truth, i.e. the thing to version-control. I'm not sure this would be a very efficient process, though. At the end of the day, natural language will always be ambiguous and so, in the same way as the language of RFCs is regulated, one might need to restrict oneself to a more well-defined subset of natural language that avoids ambiguities as far as possible. But then you're essentially back to programming.
How is this a problem? This is already how PMs and engineering managers work: they tell individual contributors what to implement, hashing out any ambiguities or edge cases via natural language dialogs. They have no need to use version control on the code level; simply tracking changes to their high level spec works fine.
>one might need to restrict oneself to a more well-defined subset of natural language that avoids ambiguities as far as possible. But then you're essentially back to programming.
Again, PMs and engineering managers get by just fine with standard natural language.
I never said this was a problem.
> Again, PMs and engineering managers get by just fine with standard natural language.
I agree only to some extent. At least in my experience, edge cases are often hashed out between the PM and engineers in spontaneous meetings, Slack conversations, or <insert medium of choice>. If ticket descriptions / acceptance criteria then get adapted accordingly, great. (Most of the time they don't – since we're so fucking agile.) Though, even if the descriptions/criteria do get updated, they often still lack precision and require interpretation – which is no problem, since all engineers now know what is meant by the ticket description and how to handle the edge case. However, if your entire spec is natural-language-based and you want your AI to reliably generate the same code every single time without needing to provide additional context, you better make sure to remove any ambiguity from the spec. But removing ambiguity from natural language basically comes down to speaking like a mathematicion / programmer, so the natural language spec will end up being rather similar to (pseudo) code again. So you're essentially back to programming.
Actually, they often have lots of problems with “standard natural language”, which is why large projects tend to develop considerable volumes of specialized jargon (often multiple layers, such as project-specific, organization-specific, etc.), which is either subject to extensive documentation (which often becomes a maintenance issue) or which becomes a contributor itself to miscommunication as understanding gaps emerge as turnover and communications silos lead to differing understands among project team members and between the project team and other stakeholders.
In fact, there is a lot of specialized, formalized, controlled language that is standardized beyond the organizational level (including visual languages), which is designed to mitigate parts of this problem (though it often fails, in part because usage in practice doesn’t consistently follow the formal standard.)
...do they? Poorly defined requirements done through natural language could possibly be the most costly and wasteful aspect of any business.
There is almost nothing about natural language use that ought to lead anyone to believe we are going to get computers to understand our requirements any better than we do, which often, is very poorly even when we try very hard.
There has been some progress in the last couple of decades, but not so much that you'd expect this to be completely solved in the next decade.
People have been saying this since 1960 at the very least.
In reality, it is vastly more likely that humans will finally learn to speak computer.
Even if you could, you would not want to use natural language to instruct a computer. You don't want the AI, or the computer, to guess your intent.
What we have done well is to quantitatively scale so that we're applying the classical debugging techniques to Big Balls of Mud, and not just a few lines of assembly.
(the record among my colleagues was writing, then fixing, 3 bugs in a single line of assembly)
Do you have a link? Searching only gave me irrelevant results.
Best I can do at the moment is to recommend searching from http://www.cs.tau.ac.il/~nachumd/term/EarlyProof.pdf which was one of the papers I passed on the way... (IIRC Goldstine and von Neumann has diagrams resembling Figure 2; I don't recall if Figure A had been anticipated or not — remember all these people had been attending the same conferences, so it's very likely)
Basically, back in the rosy-fingered dawn of electronic computation, they already had in mind "know what your state should look like at all points, so you can binary chop to find what control flow first made it go wonky".
(a question I have not investigated: how well developed were debugging techniques in the card computing era? I've read horror stories of Los Alamos computations being corrected on-the-fly, with "new code" cards on a different coloured stock being run at the same time through machines that were still busy processing "old code" cards on normal coloured stock.
And in terms of "know what your state should look like", card machines did have facilities to abort jobs if the input card deck should fail simple sanity check logic, implying that's been a thing since, probably, Hollerith ca. 1890.)
[Edit: I'll have to dig it out of my library, but an old book my spouse got me on Naval computation, from back when "computer" was a job title, not an object, talks about how to organise jobs that would take a week or two to run. I'm sure they had plenty of double-checking going on to make sure a slipup on Wednesday wouldn't result in complete garbage by the following Monday.]
Conversely, one of the problems I had in a previous place was the code being unclear because another developer kept all the obsolete code in the code base "for reference", and also put 1000 lines inside a single if clause, and duplicated class files because he didn't want to change some private: access modifiers to public:. Those kinds of problems weren't possible on such limited hardware and languages.
Over-complicating code has always been a thing, too. Admittedly, "Information Hiding" has only really been a thing since Parnas, but I think it's more true than not that most developers are making the same categories of mistakes developers have always made, and when new programming languages and paradigms are created specifically to avoid those errors, they bring with them new categories of errors.
Syntactically, the majority of code today looks completely different from 50-year-old code, of course. But I'm not sure things have really changed all that much on the human side.