Ma petite entreprise

This sunday I took some time to watch Linus' Google Tech Talk video on Git. Like others, I've been interested in SCM for a long time (started with CVS, then used PRCS for a couple of years, tried Arch, Monotone used Darcs for a while, got poison-patched, tried Git and eventually settled on Mercurial) and seeing Git getting better documentation and easier CLI, I decided it was time to give it another chance (this being encouraged by the stated of Mercurial API).

Judging from Linus' reputation, I expected the talk to be fairly technical and to go directly to the "guts of git" . To my surprise, I found that instead of detailing the architecture and implementation of git, Linus was focusing much more on the use and the social impact of git and its fundamental concepts...

In the beginning, Linus talks about the concept of decentralized SCM, explaining briefly what it is, and then explaining in detail why he thinks every open-source projects should use a decentralized SCM model: because in the decentralized model it is so easy to create branches (each repo is a branch), everybody can contribute, even if the maintainers don't trust them. In centralized models, developers have to give credentialx to other developers, and as you usually don't want somebody to mess with the code in your project, you end up being conservative about contribution, spend a lot of time doing politics and only give commit access to a few people.

Because the decentralized model makes it easy to create your own branch and to keep track of changes coming from the "main line", it encourages a healthy evolution of the codebase: you can start working on a new feature on your own, without spending tons of time arguing about it with the lead devs, and once you're satisfied with it, simply advertise your repository URL. If you did a good job (and propaganda people will start to use it, and maybe use your repo as the new "main line" -- or maybe the maintainers will pull your changes from your repo.

Also, according to Linus, the notion of trust in a decentralized models follows very closely our "hard-wired" social patterns: we only have so many people that we can trust. In centralized model, you have to trust everyone with commit access. With decentralized model, you can trust a few people and pull from them. Each of these people may in turn trust a few people and pull from them too, resulting in cascading propagation of changes. For large projects like the kernel, this seems like a very democratic way of managing contributions.

One last interesting point that Linus makes is about performance. We may tend to think that Linus cares about performance because he's a geek and he just wants to brag about how fast his C-based implementation is compared to others -- it is absolutely not the case. Although Linus is proud (and confident) of Git's performance, he explains how having a fast SCM software makes operations cheap: it's easy to commit, branch and most importantly easy to merge.

According to Linus, merging is the most crucial feature of SCM systems -- in most existing systems, merging is a major pain, it is a slow, complicated process. By making it simpler (automatic resolution) and most importantly, fast, git encourages merging, and thus supports the decentralized model (you have to merge often to keep in sync with other "branches").

So why did I wrote "Linus is a designer" in the title ? Well, because in this talk, Linus does not really talks like the regular hacker: he does not only creates something to solve a technical problem (a tool), but he also tries to have an impact on people and change their perception of things. Linus' perspective on the decentralized model, and how it benefits open-source projects, or his perspective on performance and how it favors a specific type of usage (frequent merge) do not (only) stem from technical problems, but rather are the result of trying to create or evolve habits.

This is quite unusual in the world of software, and seeing that coming from Linus, one the world most respected hacker, is even more surprising. In the end, it shows us that there is a bright future for the term of "software design", where both the concepts and interface of a software not only serve their original purpose (help a user in a task) but also manage to make things change, and to make people look at things in a slightly different way... I guess this will probably remind some of you of previous discussions on programming language design

Voilà, that's all I had to say about that ! Now you can just watch the whole thing or read a pretty good summary here.

Un des articles les plus populaires de ce blog (si j'en crois les statistiques) est un article que j'ai écrit il y a un peu plus de deux ans sur le feng-shui et les interfaces graphiques.

Justement, ReadWriteWeb nous présente Feng-GUI qui semble utiliser une technique très similaire à celle que je présentais : en gros, il s'agit d'obtenir au moyen de transformations simples de l'image une représentation des zones qui vont naturellement attirer notre oeil.

D'après l'image ci-dessus (tirée de l'article de RWW, mais dont l'origine n'est pas précisée), les résultats sont surprennament proches de la technique de l'eye-tracking, beaucoup plus onéreuse et complexe a mettre en place. Maintenant, le problème c'est qu'aucune étude concrète et extensive n'est mentionnée...

Au fond, Feng-GUI rend accessible une technique qui est tout de même un brin fastidieuse pour qui n'a pas automatisé le processus : il faut faire des captures du site, les filtrer, et puis les interpréter. Une petite "bookmarklet" permettant de convertir la page courante en différentes "heatmaps" serait à mon avis idéale, puisque Feng-GUI ne permet que d'envoyer des images.

En tout cas, je suis content de voir qu'il y a de l'innovation au niveau des outils dans le domaine de l'ergonomie. Le renouveau du web a permis une prise de conscience croissante de l'importance des interfaces, et par conséquence de l'importance de leur conception. Nous avons atteint avec HTML et CSS une très grande plasticité, ce qui permet d'expérimenter, et ce qui implique aussi la naissance de nouvelles techniques et outils !

Pfeeewww... ça fait du bien de reparler d'interfaces

Il semblerait que je persévère dans la continuité émergente de ce blog : moins d'article sur les interfaces, et plus sur les langages -- ce qui curieusement, ne reflète absolument pas ce que je fais au quotidien. Cela dit, je pense qu'il y a ici l'occasion de jeter un pont entre ces deux domaines, grâce au design...

Je profite de l'ébullition qui se produit actuellement autour de Arc, et notamment de la réponse de Paul Graham "Take the Arc challenge" pour vous faire part de mes impressions... non pas sur le langage lui-même, mais sur le fait d'être la personne qui conçoit le langage : le "designer".

Si je parle de "design" ici, plutôt que de conception, c'est pour mettre l'accent sur le fait que Arc a réellement été conçu avec des valeurs fortes, par opposition à quelque chose qui a été pensé ou plutôt "intuitionné" et ensuite qui a évolué de manière organique. En regardant plus en détail le (vaste) ensemble des langages existants, on se rend compte assez rapidement qu'une bonne partie manque de principes de conception clairs -- ce qui témoigne de l'absence d'une volonté de design.

Bref, ce n'est manifestement pas le cas de Arc, et Paul Graham a même pris l'occasion d'exprimer plus en détail sa vision dans son dernier article. Petits extraits:

(...) I worked on things that would make programs shorter. Why would I do that? Because making programs short is what high level languages are for. It may not be 100% accurate to say the power of a programming language is in inverse proportion to the length of programs written in it, but it's damned close. Imagine how preposterous it would sound if someone said "The program is 10 lines of code in your language and 50 in my language, but my language is more powerful." You'd be thinking: what does he mean by power, then ?

et plus loin

This is not to say none of the stuff I did was hard. Some of it seemed hard to me. But in language design, solving problems, whether hard or easy, is not the goal. Making a good language is. The real test of Arc—and any other general-purpose high level language—is not whether it contains feature x or solves problem y, but how long programs are in it.

Ce qui résume relativement bien un aspect qui est souvent peu considéré : un langage n'est pas essentiellement quelque chose de technique, mais bel et bien un mode d'expression (et j'ajouterais : un mode d'expression qui structure la pensée en retour). Comme le rappelle Paul Graham en début de son article : chacun semble avoir son opinion à propos de Arc, et la plupart des premières réactions on été primaires et plutôt négatives... une des raisons étant qu'il faut du temps pour apprendre le langage et le pratiquer ; ce n'est donc que plus tard que des remarques "plus constructives" pourront émerger.

Ceci m'amène finalement à ce que je voulais vraiment dire dans cet article (hormis de sensibiliser mon lectorat - qui n'en a sûrement pas besoin - au concept de design de langage) : lorsque l'on fait (vraiment) du design, on essentiellement fait des choix qui ne sont pas des conséquences de contraintes techniques, mais des choix qui vont donner le coeur et la chair de ce que nous allons créer.

Bien souvent, ce coeur et cette chair ne s'expriment pas directement, et la forme l'emporte sur le fond dans l'esprit des gens : chacun a toujours quelque chose à dire sur la forme (et croyez moi, vous le voyez tous les jours quand vous bossez dans l'interface graphique mais très peu de gens sont capables de comprendre qu'il y a un fond... et dans ce cas restent en général très prudents en s'exprimant par rapport à lui.

Bref, être un designer n'est pas quelque chose de facile, parce que l'on met beaucoup de nous même dedans. Nous mettons beaucoup de choses qui ne sont pas le fruit d'une démarche problème -> solution, nous essayons plutôt de créer un esprit, de "donner une âme" aux choses si je puis dire.

Lorsque j'ai fait ma license de design, j'étais ingénieur en logiciel depuis deux ans... et j'ai vraiment compris que pratiquer l'ingénierie avait quelque chose de réconfortant : c'est un peu comme une série de puzzles logiques, où il y a certes beaucoup de solutions, mais où la part de créativité que l'on peut investir fait justement partie de ce fond invisible qui ne préoccupe pas tant les gens. Au final beaucoup de satisfaction (les puzzles assemblés) et peu de frustration (personne pour manifester son désaccord sur la forme).

Pour le design, c'est vraiment différent : on se retrouve littéralement à nu devant les autres, et il faut avoir le coeur bien accroché pour ne pas se laisser démonter par des critiques qui tiennent (bien souvent) plus du réflexe que d'une tentative de compréhension. Nos profs nous ont heureusement entraîné tout le long en nous confrontant à ce genre de situation, mais il reste que c'est quelque chose de vraiment éprouvant, car il n'y a pas d'abri possible : quelque chose que l'on a designé vient du fond de nous, et ne pas la comprendre, ou la remettre en question nous affecte directement en conséquence.

Bref, Paul Graham est quelque part victime de son succès : c'est quelqu'un de connu, et il a visiblement beaucoup investi de lui-même dans Arc... et peut-être n'était-il pas encore complètement prêt à entendre tant de critiques abruptes.

En tout cas, pour vous remercier d'avoir lu cet article jusqu'au bout, je vous invite à regarder ce fil de discussion où vous trouverez des versions dans beaucoup de langages d'un même programme... c'est très très intéressant de regarder les exemples de code en se demandant "quel est l'esprit de ce mode d'expression" ?