Yes! I’m happy that at least one person clicks on that.
The software industry is currently held back by a conception of programming-as-manual-labor, consisting of semi-mechanically turning a specification document into executable code. In fact it’s much closer to “the art of improving your understanding of some business domain by expressing the details of that domain in a formal notation”. The resulting program isn’t quite a by-product of that activity—it’s important, though not nearly as important as distilling the domain understanding.
Yes, I agree. The real test of AI is not the automation of “formal specification → working code”—if the client could formalize it to that level, they could write the code themselves. Rather, the real test is whether an AI could talk to an extroverted MBA, figure out what they want, and then produce the working code. But so far, only humans programmers can do that.
And by the same token, we’ll know we’ve nailed AI not when we have written a program that can have that conversation… but when we have written down an account of how we are able to have that conversation, to such a level of detail that there’s nothing left to explain.
Writing a program which solves the Towers of Hanoi is not too hard. Proving, given a formalization of the ToH, various properties of a program that solves it, isn’t too hard. But looking at a bunch of wooden disks slotted on pegs and coming up with an interpretation of that situation which corresponds to the abstract scheme we know as “Towers of Hanoi”… That’s where the fun is.
While that’s basically true, a significant part of any large program consists of dealing with “accidental complexity” that isn’t really part of the “business logic”. Of course in many cases that only makes the programming even less mechanical.
Yes! I’m happy that at least one person clicks on that.
The software industry is currently held back by a conception of programming-as-manual-labor, consisting of semi-mechanically turning a specification document into executable code. In fact it’s much closer to “the art of improving your understanding of some business domain by expressing the details of that domain in a formal notation”. The resulting program isn’t quite a by-product of that activity—it’s important, though not nearly as important as distilling the domain understanding.
Programming is the art of figuring out what you want so precisely that you can tell even a machine how to do it.
Yes, I agree. The real test of AI is not the automation of “formal specification → working code”—if the client could formalize it to that level, they could write the code themselves. Rather, the real test is whether an AI could talk to an extroverted MBA, figure out what they want, and then produce the working code. But so far, only humans programmers can do that.
And by the same token, we’ll know we’ve nailed AI not when we have written a program that can have that conversation… but when we have written down an account of how we are able to have that conversation, to such a level of detail that there’s nothing left to explain.
Writing a program which solves the Towers of Hanoi is not too hard. Proving, given a formalization of the ToH, various properties of a program that solves it, isn’t too hard. But looking at a bunch of wooden disks slotted on pegs and coming up with an interpretation of that situation which corresponds to the abstract scheme we know as “Towers of Hanoi”… That’s where the fun is.
One can’t proceed from the informal to the formal by formal means. Yet.
(Apologies to Alan Perlis etc)
While that’s basically true, a significant part of any large program consists of dealing with “accidental complexity” that isn’t really part of the “business logic”. Of course in many cases that only makes the programming even less mechanical.