5 ms·

These all sound like things that are plausible within the next 10 years, not 100. In 100 years, I expect programming languages will be mostly obsolete, since c

These all sound like things that are plausible within the next 10 years, not 100. 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.

eterps 4y ago
How would you prevent errors?
- MontyCarloHall 4y ago
  The same way an engineering manager prevents errors when telling a very talented individual contributor what to code. If a natural language statement is ambiguous, the computer (AKA talented IC) would ask you to clarify it. Unlike the IC, however, the computer would always be aware of things like time complexity, edge cases, etc. of the code it writes, and could alert the user accordingly.
AstixAndBelix 4y ago
After more than 50 years, programmers of all skill levels still make the same mistakes. I wouldn't bet any of this stuff will become mainstream in 10 years. The tech has to mature to a level where it's as easy to create an ironclad function as it is to make something in Scratch.
- 082349872349872 4y ago
  People who think we've made serious qualitative advances in debugging would do well to reread H.H. Goldstine's and J. von Neumann's thoughts on the topic from 1947. 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)
  - ben_w 4y ago
    > reread H.H. Goldstine's and J. von Neumann's thoughts on the topic from 1947. Do you have a link? Searching only gave me irrelevant results.
    - 082349872349872 4y ago
      IIRC it was https://www.sothebys.com/en/auctions/ecatalogue/2018/the-library-of-erwin-tomash-l18409/lot.937.html https://www.sothebys.com/en/auctions/ecatalogue/2018/the-lib... (or at least in that series) and finding a samizdat'ed scan took a good deal of work (and maybe even some поиск'ing). Best I can do at the moment is to recommend searching from http://www.cs.tau.ac.il/~nachumd/term/EarlyProof.pdf 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.]
      - ben_w 4y ago
        Thanks, interesting link and also interesting commentary on your part.
- ben_w 4y ago
  50 years ago some of the mistakes was "I forgot to label my punched cards and now they're in the wrong order", or "we have a new computer and we now have to rewrite everything from scratch, because C has only just been invented 6 months ago and the book about it hasn't reached our physical library yet so of course we didn't use that for the previous version". 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.
  - pwinnski 4y ago
    Putting functions in the wrong place is still a thing. Having to refactor or rewrite things because of decisions made at an executive level is still a thing. 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.
082349872349872 4y ago
Similar reasoning might suggest the mathematicians of 2022 are 100% effective in writing proofs when compared to the mathematicians of 1922?
codethief 4y ago
> 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.
- MontyCarloHall 4y ago
  >That spec will then become the source of truth, i.e. the thing to version-control. 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.
  - codethief 4y ago
    > How is this a problem? 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.
Beldin 4y ago
The vision of computer-supported and -verified proofs of maths was old when i studied. And I'm old nowadays - or, at least, not young anymore. 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.
otabdeveloper4 4y ago
> computers will be able to translate natural language into machine instructions with 100% effectiveness 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.
pjmorris 4y ago
I feel like I've heard "In 10 years, I expect programming languages will be mostly obsolete, since computers will be able to translate natural language into machine instructions with 100% effectiveness." every decade for the last four decades. I feel like the problem with such predictions is that imprecision is a featured of natural languages that is incompatible not only with precision required by our current computing hardware and programming languages but incompatible with the precision required for understanding. If you could translate natural language into machine language with 100% effectiveness, you could get rid of lawyers, judges, juries, and courts, not just programmers. I don't see that happening.
- ryanklee 4y ago
  It's a ridiculous assertion. There is no correct, deterministic path from natural language expressions to directed machine behavior, as there is no correct, deterministic natural language expression in the first place. It's not static, it has varying levels of precision, meaning is context and listener dependent, natural grammars are descriptive not prescriptive, speaker perspectives are regional, historical, fluid, metacognitive, and full of ambiguity as feature, and always in need of hermeneutic methods to adjust and adjudicate interpretations. 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.
ebjaas_2022 4y ago
That's a prediction you'll make only if you're not a programmer yourself. The entire purpose of a programming language, as opposed to a natural language, is to be able to communicate precise intent to a computer. A programming language is designed to be able to communicate precise intent, and a natural language isn't. 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.
weakfortress 4y ago
I can't wait for the next round of space-MBAs to suggest that COBOL 2122 will solve all no-code problems and finally allow them to reduce developer salaries to blue collar levels.
Existenceblinks 4y ago
I would instead obsolete natural language and have a few proper precise specs on how to call things, behaviors etc.

eterps 4y ago

How would you prevent errors?

MontyCarloHall 4y ago
The same way an engineering manager prevents errors when telling a very talented individual contributor what to code. If a natural language statement is ambiguous, the computer (AKA talented IC) would ask you to clarify it. Unlike the IC, however, the computer would always be aware of things like time complexity, edge cases, etc. of the code it writes, and could alert the user accordingly.

AstixAndBelix 4y ago

After more than 50 years, programmers of all skill levels still make the same mistakes. I wouldn't bet any of this stuff will become mainstream in 10 years. The tech has to mature to a level where it's as easy to create an ironclad function as it is to make something in Scratch.

082349872349872 4y ago
People who think we've made serious qualitative advances in debugging would do well to reread H.H. Goldstine's and J. von Neumann's thoughts on the topic from 1947. 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)
- ben_w 4y ago
  > reread H.H. Goldstine's and J. von Neumann's thoughts on the topic from 1947. Do you have a link? Searching only gave me irrelevant results.
  - 082349872349872 4y ago
    IIRC it was https://www.sothebys.com/en/auctions/ecatalogue/2018/the-library-of-erwin-tomash-l18409/lot.937.html https://www.sothebys.com/en/auctions/ecatalogue/2018/the-lib... (or at least in that series) and finding a samizdat'ed scan took a good deal of work (and maybe even some поиск'ing). Best I can do at the moment is to recommend searching from http://www.cs.tau.ac.il/~nachumd/term/EarlyProof.pdf 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.]
    - ben_w 4y ago
      Thanks, interesting link and also interesting commentary on your part.
ben_w 4y ago
50 years ago some of the mistakes was "I forgot to label my punched cards and now they're in the wrong order", or "we have a new computer and we now have to rewrite everything from scratch, because C has only just been invented 6 months ago and the book about it hasn't reached our physical library yet so of course we didn't use that for the previous version". 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.
- pwinnski 4y ago
  Putting functions in the wrong place is still a thing. Having to refactor or rewrite things because of decisions made at an executive level is still a thing. 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.

082349872349872 4y ago

Similar reasoning might suggest the mathematicians of 2022 are 100% effective in writing proofs when compared to the mathematicians of 1922?

codethief 4y ago

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

MontyCarloHall 4y ago
>That spec will then become the source of truth, i.e. the thing to version-control. 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.
- codethief 4y ago
  > How is this a problem? 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.

Beldin 4y ago

The vision of computer-supported and -verified proofs of maths was old when i studied. And I'm old nowadays - or, at least, not young anymore. 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.

otabdeveloper4 4y ago

> computers will be able to translate natural language into machine instructions with 100% effectiveness 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.

pjmorris 4y ago

I feel like I've heard "In 10 years, I expect programming languages will be mostly obsolete, since computers will be able to translate natural language into machine instructions with 100% effectiveness." every decade for the last four decades. I feel like the problem with such predictions is that imprecision is a featured of natural languages that is incompatible not only with precision required by our current computing hardware and programming languages but incompatible with the precision required for understanding. If you could translate natural language into machine language with 100% effectiveness, you could get rid of lawyers, judges, juries, and courts, not just programmers. I don't see that happening.

ryanklee 4y ago
It's a ridiculous assertion. There is no correct, deterministic path from natural language expressions to directed machine behavior, as there is no correct, deterministic natural language expression in the first place. It's not static, it has varying levels of precision, meaning is context and listener dependent, natural grammars are descriptive not prescriptive, speaker perspectives are regional, historical, fluid, metacognitive, and full of ambiguity as feature, and always in need of hermeneutic methods to adjust and adjudicate interpretations. 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.

ebjaas_2022 4y ago

That's a prediction you'll make only if you're not a programmer yourself. The entire purpose of a programming language, as opposed to a natural language, is to be able to communicate precise intent to a computer. A programming language is designed to be able to communicate precise intent, and a natural language isn't. 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.

weakfortress 4y ago

I can't wait for the next round of space-MBAs to suggest that COBOL 2122 will solve all no-code problems and finally allow them to reduce developer salaries to blue collar levels.

Existenceblinks 4y ago

I would instead obsolete natural language and have a few proper precise specs on how to call things, behaviors etc.