Concept Programming

Concept programming is initially a very simple idea: Your code should reflect the concepts in your application.

As simple as this idea is, it is not easy to implement, nor is it easy to fully understand the implications. As a matter of fact, I believe that this would give well enough material for an entire book. But I will try to quickly brush over the subject here.

What is a concept?

A concept is something from the application environment that matters to your program. A "window" displaying some information may be a concept. Most algorithms are derived from some mathematical concept. A "function" may be a concept. Programming is the art of turning concepts into code.

Consider the concept of addition as an example. Across different languages, not only can the addition of A and B can be written in a variety of ways (different syntax), but it can also behave very differently (different semantics).

Assembly	ADD A, B	A mnemonic for a processor operation
C	A+B	A built-in operator on built-in types, normally implemented using one of the processor operations
Java	A+B	A built-in operator on built-in types, with identical results irrespective of the processor operation
C, Java	Add(A, B)	For user-defined types, many languages require a function call
C++	A+B A.operator+(B)	C++ operators are similar to C for built-in types, but can be extended for user-defined types
SmallTalk	A+B	Send to object A the message "+" with B as an argument.
XL	A+B*C MulAdd(A,B,C)	XL operators are reduced to function calls using pattern matching. The standard library includes functions or types to represent native processor operations or types.

All these notations and semantics for the addition are different representations of the same concept. Because they are different, these representations don't have the same properties for the programmer. For example, C programmers need to worry about changes in the number of bits used to compute the addition when the code moves from platform to platform, while Java or XL programmers don't.

The syntax itself generally matters very little in the long term, as long as it is not completely inane or ambiguous. But the semantics may have a profound effect on how well the code represents the concept, or on how easy it is to maintain or understand. This is true for any concept, from the simplest to the most complicated.

What is not a concept?

Obviously, the definition of a concept given above is quite broad in scope. So it begs the question: what is not a concept? Well, by definition, it is either something from the environment that doesn't matter to your program, or it is something that matters to your program but is not from the application environment.

What doesn't matter is a large set of the application domain, but it's a difficult lesson to learn for programmers. For instance, a car racing game program doesn't need to have much code dealing with the behavior of the cigarette lighter. The cigarette lighter is not a concept for that program. This example is trivial. But how simplified can the engine model be? Should tires wear out? Can the windshield be damaged? All these are non-trivial decisions.

What is program-specific includes things like the particular syntax to use. It may also contain elements of the design that are mandated by a particular methodology. These elements can be recognized because they don't translate back. There is no word in the mechanics vocabulary for that semi-colon that terminates statements in C.

Abstractions

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.

Learn more...

Concepts programming compared to...

• Objects
• Lisp and other functional languages
• Intentional Programming
• Patterns
• Aspects
• .NET
• UML

Some terminology
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