3 ms·

I think what we're looking at in about a decade are interactive natural language development, in which one 'architect' will replace an entire team of programmer

I think what we're looking at in about a decade are interactive natural language development, in which one 'architect' will replace an entire team of programmers, designers, testers, etc. "When I tap on this thing " - put the finger on the control "Go ahead and get the latest articles from HackerNews" The System contacts "Hacker News" and queries for "latest articles" API. The systems negotiate an API key, account, etc and is good to go. The result is a list of articles with title and number of comments. "Now use a nice table. " System formats output. "Show me other styles" Lists table styles. "This one. Now if the number of comments is more than 100, show them in red" And so on. In the end, the System can generate source code in a multitude of languages (why?), some kind of pseudo code and of course an interactive, editable video of the "programming" session which others can watch and fix if necessary. So basically, one person can design the whole "application" in a couple of hours. We're not that far from that. And as we get closer, it will become better and better and it will be a lot easier to extend and modify this "System". Imagine developing the System using the System. Programming as we know it will remain a thing of the distant past as is the case with all things that evolve over time.

waitForCompiler 11y ago
That is highly optimistic and I do not buy into this. This would require an understanding of the human language and here we are FAR off, considering that it is currently even hard for engineers to grasp a user's requirements.
- seanmcdirmid 11y ago
  RNNs can already write what looks like viable code without any human intervention. Of course, the code doesn't do anything useful and is just a reflection of its training, but all we have to do is figure how to guide that. We are doing OK in human language recognition as well as understanding in simple dialogue frames. The technology is also moving awfully fast at the moment. You are thinking in terms of human level intelligence, but it really doesn't have to be that good. It only has to provide enough random-but-feedback guided choices until the user finds what they are really looking for. Put it this way: if the user could get what they wanted from the computer directly just by "searching", the process would be more efficient since the most inefficient part about programming is human-to-human communication and coordination.
  - LnxPrgr3 11y ago
    RNNs are good at learning the structure of their training input—even character-level networks can output vaguely plausible English. Of course, what you end up with often looks like a computational model of a thought disorder. They have seemingly lucid moments, but so do Markov chain generators. As far as code goes, we've already solved the problem of modeling the structure of any programming language with an implementation. That's not the hard part.
- duaneb 11y ago
  Semantics may not be a solvable problem, but the system doesn't exactly have to answer existential identity questions to render a list. A restricted subset of English would probably be necessary to deal with abstract algorithms.
- codeshaman 11y ago
  > considering that it is currently even hard for engineers to grasp a user's requirements. That's because users don't know exactly what they want. They know it when they see it, but they don't know how to explain it. They expect the engineers to guide them through to their idea. But as per example above, that could be done by an app - guiding a user from nothing to whatever he wants by interactively experimenting with features. Think of a REPL with access to a huge number of libraries, which is searchable by voice input.
bitwize 11y ago
Now this sounds familiar. I still remember books about software engineering written in the 80s (mainly intended for manager types) which, in their opening chapters after an explanation of how the discipline of "software engineering" evolved to the present day, painted a rosy-ass picture of the future by describing the year 2010 in which software architects lounged about in easy chairs and gave plain-English directions to HAL 9000 workstations -- replete with line drawings of retrofuturistic offices straight out of The Jetsons, The Incredibles, or Logan's Run. Needless to say, 2010 came and went and the state of the craft had evolved microscopically compared to anticipated advances despite having plenty more CPU cycles to burn on ever more complicated tooling. In some ways it has regressed. The know-how which produced Unix and ARPANET on limited hardware with limited resources, inside academic, industrial, and government departments which got little recognition or respect, is in short enough supply that we may not be able to repeat the feat if we had to do it all over again. Alan Kay maintains that programming is pop culture because we don't remember our history but it's worse than that. We're like a primitive Mesopotamian tribe from antiquity who had a history but forgot it except for bits and pieces which got written down and became Religion. Things like "GO TO considered harmful", "object-oriented programming is good", "DRY", "refactoring", "design patterns", etc. We're saddled with object-oriented programming -- and its attendant complexity -- for life. But most of us don't understand how OO came to be, why it might be good, or what the tradeoffs are vs. other programming methods because we don't ask ourselves these questions. Design patterns should be treated like TV Tropes, replete with having maybe a great wiki describing them all, and allowing the addition of new ones as well as admitting variations and inversions. Instead we treat them like nam-shubs, strict instructions handed down from the gods on what to do under these circumstances to achieve this result. And in this culture we await the day when, magically, the Machines will spontaneously evolve the intelligence to relieve us of the burden of software design specifics!
- codeshaman 11y ago
  Maybe you're missing the fact that in 2015 we have super computers (by 80s standards) in our pockets which are always connected to the Internet to which we actually issue verbal commands.. In fact, most of the tasks described in those futuristic books didn't involve programming, I suspect they were examples of how you could ask your HAL 9000 to tell you how much is 9999 * 9999 and it would give you the answer in human voice. A lot of the tasks which would have required programming in the 80s are now solved by one of the millions of apps, so that's another angle. Maybe we're not exactly were sci-fi predicted we'd be at, but there are a lot of things that sci-fi didn't even dream of that we take for granted. Even the dev environments of today. You'd think they only include the text editor/IDE, but you've also got the browser, google and stackoverflow, github and a myriad of tools and libraries to help use build more and more complex apps. The fact is, today's programmer-for-hire is an interface between the client (app inventor/architect) and the machine, just like secretaries were interfaces between their boss' spoken messages and the typewritten letters. And if something can be optimized away by technology someday it will. Maybe it won't involve spoken language (although, why not, if it's done right?), but my bet is that programming will be less of a profession and more of a skill that you learn by using powerful tools.

waitForCompiler 11y ago

That is highly optimistic and I do not buy into this. This would require an understanding of the human language and here we are FAR off, considering that it is currently even hard for engineers to grasp a user's requirements.

seanmcdirmid 11y ago
RNNs can already write what looks like viable code without any human intervention. Of course, the code doesn't do anything useful and is just a reflection of its training, but all we have to do is figure how to guide that. We are doing OK in human language recognition as well as understanding in simple dialogue frames. The technology is also moving awfully fast at the moment. You are thinking in terms of human level intelligence, but it really doesn't have to be that good. It only has to provide enough random-but-feedback guided choices until the user finds what they are really looking for. Put it this way: if the user could get what they wanted from the computer directly just by "searching", the process would be more efficient since the most inefficient part about programming is human-to-human communication and coordination.
- LnxPrgr3 11y ago
  RNNs are good at learning the structure of their training input—even character-level networks can output vaguely plausible English. Of course, what you end up with often looks like a computational model of a thought disorder. They have seemingly lucid moments, but so do Markov chain generators. As far as code goes, we've already solved the problem of modeling the structure of any programming language with an implementation. That's not the hard part.
duaneb 11y ago
Semantics may not be a solvable problem, but the system doesn't exactly have to answer existential identity questions to render a list. A restricted subset of English would probably be necessary to deal with abstract algorithms.
codeshaman 11y ago
> considering that it is currently even hard for engineers to grasp a user's requirements. That's because users don't know exactly what they want. They know it when they see it, but they don't know how to explain it. They expect the engineers to guide them through to their idea. But as per example above, that could be done by an app - guiding a user from nothing to whatever he wants by interactively experimenting with features. Think of a REPL with access to a huge number of libraries, which is searchable by voice input.

bitwize 11y ago

Now this sounds familiar. I still remember books about software engineering written in the 80s (mainly intended for manager types) which, in their opening chapters after an explanation of how the discipline of "software engineering" evolved to the present day, painted a rosy-ass picture of the future by describing the year 2010 in which software architects lounged about in easy chairs and gave plain-English directions to HAL 9000 workstations -- replete with line drawings of retrofuturistic offices straight out of The Jetsons, The Incredibles, or Logan's Run. Needless to say, 2010 came and went and the state of the craft had evolved microscopically compared to anticipated advances despite having plenty more CPU cycles to burn on ever more complicated tooling. In some ways it has regressed. The know-how which produced Unix and ARPANET on limited hardware with limited resources, inside academic, industrial, and government departments which got little recognition or respect, is in short enough supply that we may not be able to repeat the feat if we had to do it all over again. Alan Kay maintains that programming is pop culture because we don't remember our history but it's worse than that. We're like a primitive Mesopotamian tribe from antiquity who had a history but forgot it except for bits and pieces which got written down and became Religion. Things like "GO TO considered harmful", "object-oriented programming is good", "DRY", "refactoring", "design patterns", etc. We're saddled with object-oriented programming -- and its attendant complexity -- for life. But most of us don't understand how OO came to be, why it might be good, or what the tradeoffs are vs. other programming methods because we don't ask ourselves these questions. Design patterns should be treated like TV Tropes, replete with having maybe a great wiki describing them all, and allowing the addition of new ones as well as admitting variations and inversions. Instead we treat them like nam-shubs, strict instructions handed down from the gods on what to do under these circumstances to achieve this result. And in this culture we await the day when, magically, the Machines will spontaneously evolve the intelligence to relieve us of the burden of software design specifics!

codeshaman 11y ago
Maybe you're missing the fact that in 2015 we have super computers (by 80s standards) in our pockets which are always connected to the Internet to which we actually issue verbal commands.. In fact, most of the tasks described in those futuristic books didn't involve programming, I suspect they were examples of how you could ask your HAL 9000 to tell you how much is 9999 * 9999 and it would give you the answer in human voice. A lot of the tasks which would have required programming in the 80s are now solved by one of the millions of apps, so that's another angle. Maybe we're not exactly were sci-fi predicted we'd be at, but there are a lot of things that sci-fi didn't even dream of that we take for granted. Even the dev environments of today. You'd think they only include the text editor/IDE, but you've also got the browser, google and stackoverflow, github and a myriad of tools and libraries to help use build more and more complex apps. The fact is, today's programmer-for-hire is an interface between the client (app inventor/architect) and the machine, just like secretaries were interfaces between their boss' spoken messages and the typewritten letters. And if something can be optimized away by technology someday it will. Maybe it won't involve spoken language (although, why not, if it's done right?), but my bet is that programming will be less of a profession and more of a skill that you learn by using powerful tools.