Programming is not about algorithms
> Also, most of the programming effort is
> not in designing new algorithms, but in
> choosing and mixing (i.e. combining)
> existing algorithms. Here, a reflective
Spoken like a true academic! Or, perhaps, a pointy haired boss. "Algorithm" is in itself an academic word, referring to canned procedures like sorting, searching, compression, etc. All of them form a truly miniscule portion of any software project, and are usually just copied from some textbook when required. I have a few myself, from my ancient college CS texts, to the more modern compendiums like "Numerical Recipies in C". It takes maybe an hour to type one in. The bulk of the code, however, is usually about the UI, "business logic", and sundry "glue" code. Choosing algorithms is for portions of the program that need to be fast. That used to be graphics, when software rendering was the rule and you had to implement textured polygon rendering in nine cycles per texel or die. With the modern GPUs and DirectX, nobody does that anymore (except on Linux, where only OpenGL on X is allowed to use the GPU) It also applies to search, if you are Google, or have a billion-record database, both of which usually require a task-specific solution.
In the rest of the code cleanliness and maintainability are far more important that what algorithm you are using. When you're sorting a 100-element array, bubble sort will do just as well as heapsort, but can be coded in a dozen lines (yeah, STL has the sort algorithm, but I'm trying to give an example here :) which any idiot can understand.
When you take someone else's code, it is almost never possible to just drop it in and have it work. Chances are, it uses different argument types, like QString instead of std::string, or requires malloc-allocated memory (*gasp*). Chances are it is written in C and has some horrible garbage hung on it that every C program can't live without, like running the algorithm on a file (zlib, graphics format libs, etc.) or reporting errors via callbacks (libjpeg). When you put something like that into your nice and clean C++ design, it looks like an open sore begging to be wrapped.
So you spend some time on an object wrapper, with the intention of hiding all the unpalatable stuff in one bloated object. Then you spend time debugging the wrapper, since all those translations always go wrong somewhere, exception handling doesn't go through a C callstack (requring a state machine modified from the callback [see Xlib, the vilest and the most hostile UI library in existence]), and thread safety is just not there. And then you stop, throw up your hands in disguist, and rewrite the whole bloody thing from scratch in a day or so. The next time you won't even bother doing the wrapper. It's just not worth it.
This was about the algorithms. The rest of the code is usually not reusable. The UI portions are specific to the UI package you are using. Anyone writing a similar program would probably be doing it for a different UI (or else, why not just use your program?). Even if they use the same UI, their programming environment may differ markedly from yours. For example, I use STL for containers, while another programmer may be stuck with Qt, out of preference or because of legacy code. He'd have to wrap or modify to fit. But even that is an ideal scenario. One program's UI often has no relation to another program's UI at all. The structure may be completely different, preventing any code reuse at all. Finally, there's the "business logic" code, which is seldom logical, depends entirely on the customer's whim, and is completely useless to anyone but him.
> But generating code by knowledge system
> is in my opinion a very interesting and
> fruitful idea (but it is hard
Trying to replace programmers with a machine again? :) Not gonna work. The problem domain is just too wide. You can write specialty code generators for simple, well-defined tasks. Visual Studio has a whole bunch of Wizards like that. But for general purpose programming, you can forget it. Programming is not about implementing algorithms, contrary to what ivory tower academics think; it's about figuring out what the user wants and about designing components with good interfaces. It's an art, not a science, since it is about people as much as about computers. That's why it requires a human mind, human thought, and human experience. Yes, it may be possible to create an AI programmer some day, but it would not be some mindless "database". It would have to be a true sentient being just like us.
A fine example of what not to do
This article provides the perfect illustration why algorithms are seldom reused. The author takes simple algorithms like a+b which can literally be implemented in three characters and blows them up into an object-oriented API a few hundred lines long. I doubt he will find any programmer who would want to use it. They will take one look at it, snort with contempt, and write their own. You see, it is not enough to abstract your algorithms; you have to know how to design a good API, and the first criteria for the latter is simplicity. If a programmer thinks he can write something smaller and simpler, he will do so. The desire to optimize is ingrained deeply, and it takes a lot of talent to design reusable code that will impress its intended users enough for them to accept it. It is a talent that the article's author obviously does not possess yet. I would like to end with the immortal words of John Carmack: "Get your fat API out of the way and let me at the iron!" and a friendly admonition to the author to take his ugly bloated API elsewhere until he gets a few more years of experience and learns the skill of good design.