Concepts need to be transposed from the application domain to the program domain. This process is called an abstraction. The important point is that an abstraction can be destructive. What appears in your code looks like the original concept, but it is not. This point bears repeating, because we programmers tend to forget it. Code is only a representation. Concepts live in the application domain. There are no concepts in the code, only concept representations. Or, as Magritte would say: This is not a pipe.
There are many popular methodologies today that help finding a way to abstract concepts: object-oriented design, design patterns, aspects or modelling languages. All these techniques, sometimes called paradigms are designed to guide you in the abstraction process.
Concept programming is not intended to displace any of these methodologies, but rather to explain the logic behind them, and to identify the base principles of abstraction that are common to all these techniques. Concept programming is a useful guide to apply these methodologies correctly, and get the best out of them.
FAQ: You are saying that abstractions are good, this is hardly news! On the contrary, the point of concept programming is to highlight that abstractions are always destructive. There is always something from the concept that doesn't appear in its code representation. Understanding this, and trying to minimize the differences, is key to writing good code.
How is this new or different?
Concept programming impacts how we analyze and design every component of the developers palette: programming languages, libraries, tools or code metrics. Analyzing existing practice using concept programming help us pinpoint flaws which, until now, were at best perceived by many programmers only intuitively. Taking concept programming into account during the design helps us avoid these flaws in the future.
As an illustration, concept programming guided the design of XL. One result is that XL is a very extensible language, so that it can accommodate the wide variety of concepts out there. This extensibility is a consequence of concept programming, not a goal in itself (this point was unfortunately very unclear in previous iterations of the web site). See the comparison with functional languages for a more in-depth discussion.
So is it new? The base idea might sound naive, and is probably not new. The term "concept programming" itself has been used in different contexts. But in practice, existing code shows very little attention being paid to concept representation. As long as this remains true, concept programming will be "new". The real question is: is it new for you?
FAQ: Isn't this another one of these much despised silver-bullet methodologies? Concept programming is not restricted to particular tools or methods. In that sense, it is "universal", or "silver bullet" if you wish. Concept programming can help you write better C code, better C++ code, better Lisp code, I have even applied concept programming ideas for assembly language. Concept programming can also guide you in your object-oriented designs, or when applying design patterns, or when using any other methodology.
On the other hand, concept programming will never fix the code for you. Since it relates to ideas, it cannot be quantified or measured precisely. Concept programming is more of an art or an expertise than a science.
Concepts programming compared to...
Designing a concept-oriented programming language
Using concepts to extend existing languages
Concept programming tools
Concept programming applications
Better optimizations based on concepts
Concept programming history