Eli Bendersky's website As a programmer, I often find the marketing tricks of salespeople annoying. I find them most annoying when they try to market programming tools which are based on fallacious foundations. Recently, a lot of hype is being pumped about "automatically generating programs". The idea of generating code from a UML diagram is not new, but I feel that in the past couple of years the hype has reached intolerable proportions.
Examples are easy to find by googling. Often you don't even have to look, the advertisements find you in forms of Google's ad-words. "The end of programming", they proclaim, "no more need in programmers, now all code will be automatically generated from nicely written Word specs and pretty UML diagrams, billions in savings, hurray!!".
Ridiculous, blasphemous, disgusting. No one with even the basic understanding in programming can believe such gibberish. As always, it is good to quote someone who knows how to express ideas lucidly. In this case, from Joel:
In fact what you’ll see is that the hard-core geeks tend to give up on all kinds of useful measures of quality, and basically they get left with the only one they can prove mechanically, which is, does the program behave according to specification. And so we get a very narrow, geeky definition of quality: how closely does the program correspond to the spec. Does it produce the defined outputs given the defined inputs.
The problem, here, is very fundamental. In order to mechanically prove that a program corresponds to some spec, the spec itself needs to be extremely detailed. In fact the spec has to define everything about the program, otherwise, nothing can be proven automatically and mechanically. Now, if the spec does define everything about how the program is going to behave, then, lo and behold, it contains all the information necessary to generate the program! And now certain geeks go off to a very dark place where they start thinking about automatically compiling specs into programs, and they start to think that they’ve just invented a way to program computers without programming.
Now, this is the software engineering equivalent of a perpetual motion machine. It’s one of those things that crackpots keep trying to do, no matter how much you tell them it could never work. If the spec defines precisely what a program will do, with enough detail that it can be used to generate the program itself, this just begs the question: how do you write the spec? Such a complete spec is just as hard to write as the underlying computer program, because just as many details have to be answered by spec writer as the programmer. To use terminology from information theory: the spec needs just as many bits of Shannon entropy as the computer program itself would have. Each bit of entropy is a decision taken by the spec-writer or the programmer.
So, the bottom line is that if there really were a mechanical way to prove things about the correctness of a program, all you’d be able to prove is whether that program is identical to some other program that must contain the same amount of entropy as the first program, otherwise some of the behaviors are going to be undefined, and thus unproven. So now the spec writing is just as hard as writing a program, and all you’ve done is moved one problem from over here to over there, and accomplished nothing whatsoever.