In other words: constraint-based design, in an interactive context-sensitive dialogue, with the machine-agent able to resolve change requests by—among other strategies—discovering and consuming new third-party components it was previously unaware of. Such a tool essentially presents the same interface that a contract programmer presents to their client: tell me what you want, I'll build it; tell me how it's wrong, I'll fix it.
The article brushes the concept of such a level of automation aside as requiring near-human intelligence. But, unlike a human programmer, said tool wouldn't need do the hard part—requirements-gathering—for you, or have any sense of what "sensible" requirements would be. Where human software architects guide their clients into specifying requirements, this sort of tool would be much like the compilers of today: it would take you literally and give you what you asked for, rather than what you wanted, until you ask for exactly the right thing. It would just do it very fast, such that this could be the basis of an effective feedback loop.
I think that scene shows the ridiculousness of the concept; there is NO WAY the computer could have gotten that close to the actual table they were talking about based on those descriptions. It made all sorts of assumptions about the table that just happened to be right in order to move the plot along.
Just imagine trying to describe how to draw that table to a human artist. It would take forever, with a ridiculous amount of iteration.
If you want to program like this, you would have to get VERY good at describing the thing in an unambiguous way, and the skill to do that is going to become the new 'programming' skill.
> Just imagine trying to describe how to draw that table to a human artist. It would take forever, with a ridiculous amount of iteration.
Right, that's more what I was picturing: in reality, interacting with this kind of software would be like interacting with a sketch artist. It would be a very exhaustive (and exhausting) process.
(Though, it'd essentially be the same effect you get by outsourcing piece-work to a service like Mechanical Turk—just with instantaneous response-time.)
> If you want to program like this, you would have to get VERY good at describing the thing in an unambiguous way
Today, the intelligence/intuition/common sense of the programmer "allows" the client to avoid ever having to develop the skill of requirements analysis for themselves. Thus, even though it doesn't take any special aptitude to learn this skill, it's currently rare.
On the other hand, the naivety and short iteration time of an interactive constraint programming system would, I think, make it likely that anyone who used it would quickly/easily develop the ability to do requirements analysis. Perhaps not without being "lead by the hand" in a person-machine conversation, but certainly with it. (Much like how people who have only ever used CAD software can't necessarily do mechanical drawing by hand.)
Sure, once we have a holodeck that can understand arbitrary requests and make them physical reality, I might be worried about finding work as a programmer.
But even on Star Trek the crew is often portrayed as writing some form of code. I don't know how accurate that would be once you can have computers that do such a fantastic job of extrapolating simple requests into extremely realistic world settings, but then again, stuff seems to go wrong often enough on the holodeck, or with the transporter, or some spatial anomaly requiring tweaking of the deflector dish, so maybe you still need programmers in the 24th century.
I do like how just telling the holodeck computer to make an opponent challenging for Data in the Sherlock setting was enough to grant sentience to the Moriarty character. That's pretty impressive.
In other words: constraint-based design, in an interactive context-sensitive dialogue, with the machine-agent able to resolve change requests by—among other strategies—discovering and consuming new third-party components it was previously unaware of. Such a tool essentially presents the same interface that a contract programmer presents to their client: tell me what you want, I'll build it; tell me how it's wrong, I'll fix it.
The article brushes the concept of such a level of automation aside as requiring near-human intelligence. But, unlike a human programmer, said tool wouldn't need do the hard part—requirements-gathering—for you, or have any sense of what "sensible" requirements would be. Where human software architects guide their clients into specifying requirements, this sort of tool would be much like the compilers of today: it would take you literally and give you what you asked for, rather than what you wanted, until you ask for exactly the right thing. It would just do it very fast, such that this could be the basis of an effective feedback loop.