Some of my good friends liked to kid me this way: they show me a program they just wrote/discover and secretly bid if I will ask my favorite question: “do you really need this?” [1]. Before they told me this fact, I didn’t realized that I often ask that question. The bad thing is that it could sounds like “what useless is your work!” … I’m so sorry if some people understood that of me. The good thing is that now I take care not to say it again … but I keep remind the real meaning: what is the point which is really important in that? In fact the real question is not about the word “need”, but is about the word “this”.

To my mind, the real importance of this question is about distinguish “how” and “what” [2]: this point is useful for me in any area but let illustrate it with programming language.

When I learned to program I often thought in a problem-solving approach: I searched how to solve the problem. Perhaps because of the language I used: C. This is a perfect example of language to express not what you want to do but to express what you have to do to get this result: this is exactly how to do (and you can even set the register of the microprocessor because you know exactly how to do to obtain your result … and how the processor work, wow!). This is really efficient on nowadays machine … but with new processor instruction sets and hopefully new processor architectures (x86 is not really the best one!), with also concurrency in its way to be widespread everywhere, the compilation of C code may result in less efficient running code that compilation of high level language. OK OK, some times a cast in void** is easier and more efficient than anything else, but I’m really curious of what Haskell compiler developers will be able to do.

Another approach of problem is to concentrate on definition of what we try to solve (problem-defining approach?). The idea is that if you know exactly the prototype of the C function to write and its documentation, 80% of the work is done. The best example I can think of is a logical programming language: prolog. Those kind of programming give you an reasoning engine to which you just have to give facts and rules: he will search for you the result you want. You have to define what you know and what you want, he knows how to do, really! It’s so convenient to express complex reasoning system of AI.

More surprisingly (to me at least) another language which guides you to think about what you want is SQL. That’s only after having written some fairly complex queries (like mathematical integration of probability distributions) that I realized that I was completely focus on the data I have and on the data I want, and no way I can define how to proceed in SQL!
Those languages can be seen as declarative languages: express your knowledge of what you want, let the engine do it for you.

Another kind of language can help to problem-defining approach: the functional languages. Because the way to write functional code is to think about what is entry of function and what is the output: the “how to do” is replaced by “what is this function” (for example you don’t write how to loop, you call the function which solve the next problem after the first step (often recursion)). Main difference between logical and functional languages is the internal engine of logical system (backtracking) which enable in logical language to not make difference between the parameters of function and the return value: functional language let you define what is the result and what is the process (here the developer is happy) where you have to use (and tricks) the logical language process with languages like prolog.

All that to say that in most of the case a language focusing on defining data and their process should be more convenient to design robust solution to well defined problem. And so my next blog post will probably be on what is my next language (matz said it’s good to learn one language every year!).

[1] PAF used to call it the “coquellienne question”
[2] Lot of those ideas come from my studies/past experience at ENIB/CERV