Codingly

Le problème de la PDC, quand on y est pas et qu’on est curieux, c’est qu’il faut attendre les vidéos des sessions pour savoir ce qui s’est vraiment passé. Symptôme de naïveté : croire qu’on pourra s’en sortir grâce à la blogosphère. Sérieusement, et je reste sur l’exemple spécifique de C# 4.0, 80% des billets qui sont sortis jusqu’à présent à ce sujet ont simplement contribué à rendre l’écho plus pénible. Un peu partout on peut tomber sur des réactions constructives du genre :

The dynamic keyword is going be abused so much… C# is on its way to becoming PHP.

J’aurais carrément ajouté un « lol » à la place du point, moi. Difficile dans ces conditions de comprendre de quoi est fait C# 4.0, difficile d’anticiper à quoi pourront ressembler les prochaines versions. Pourtant, et c’est où je veux en venir, Anders Hejlsberg a été particulièrement clair dans sa présentation. Il a parlé du langage C#. Il a exposé sa vision, celle de l’équipe de conception du langage. Je vous invite donc tous à voir sa session si ce n’est déjà fait, en prenant bien soin de ne pas zapper l’introduction.

C# est né avec et pour la plateforme .NET. On peut être surpris de se faire rappeler que ça fait 8 ans qu’il a été annoncé pour la première fois, et presque 10 ans que sa conception a commencé. Pourtant, si on met de côté les spécificités héritées de la plateforme .NET elle-même, c’est un langage dont le vrai caractère n’a commencé à s’affirmer qu’à partir de la version 3.0, avec laquelle sont apparus, entres autres, les expressions lambda, les arbres syntaxiques, les méthodes d’extension, ou Linq – ce dernier reposant d’ailleurs essentiellement sur les précédentes features.

On a un peu tout vu et entendu à leur sujet : de la critique violente à l’apologie extatique. Pourtant, on ne parle que d’un langage de programmation. Il y a souvent plusieurs raisons de critiquer un langage, et bien évidemment, toutes ne se valent pas. Essayer de discuter les choix des concepteurs quant à l’implémentation de telle ou telle feature, pourquoi pas :

Ouais, mais tu vois, ça ils auraient dû le descendre au niveau du CLR au lieu de laisser le compilo interpréter des attributs pourris

Quoique déjà, il vaut mieux ne pas s’appeler Romain Verdier et avoir réfléchi un peu plus de 3 minutes à la pause café. Car remettre en cause aussi légèrement les décisions prises par une équipe qui ne ressemble pas exactement à un groupe de singes, ça revient à parler pour parler.

Attention, tout le monde peut avoir un avis, et l’équipe d’Anders n’est probablement pas infaillible. ce n’est pas parce qu’on ne sait pas peindre qu’on est obligé d’aimer tous les tableaux, hein. Je suis simplement bien placé pour savoir que les opinions-réflexes sont parfois assez dures à réfréner, et rarement pertinentes.

Bref, ne critiquez plus jamais C#, OK ?

OKAY ?

Hihi. Non, j’ai surtout envie d’insister sur un point précis, ou sur une critique particulière, celle qui consiste à regretter ouvertement l’extension du « périmètre C# », si possible avec condescendance. Critiquer un langage parce qu’il mêle différents concepts, parce qu’il s’enrichit et se diversifie en introduisant des fonctionnalités que l’on peut difficilement classifier ; ça n’a pas vraiment de sens pour moi.

Aujourd’hui, on peut considérer que C#, à l’instar d’autres langages, est un langage multi-paradigmes :

• Impératif
• Orienté objet
• Générique
• (Fonctionnel)
• (Dynamique)

Et, à la différence d’autres langages, il évolue très vite.

Je me permets de citer Eric Lippert :

The techniques are not good in of themselves, they’re good because they’re practical.

Perhaps surprisingly, our goal in making C# is not to make an object-oriented language. Our goal is to make a compelling and practical language for general-purpose application development on our platforms, and thereby enable our customers to be successful. Making an object-oriented language called C# is just a means to that end, not an end in of itself.

Le paragraphe est tiré de son article en plusieurs parties au sujet du futur de C#. (Je vous invite à le lire, évidemment.) Il y explique assez bien que le but du langage est d’être un langage pratique, puissant, efficace. Et si les méthodes d’extension rendent Linq possible, alors, même si elles n’ont rien à voir avec l’OOP, il serait peut-être bon de les ajouter au langage. De même, si l’inclusion du DLR dans .NET 4 et son exploitation à partir de C# via le mot clé dynamic permet de rendre l’interopérabilité entre C# et les langages dynamiques possible et même facile, alors ce n’est probablement pas complètement con. Python, Ruby, Javascript, COM, etc. Ce n’est pas comme si l’essence même du langage changeait pour que ce dernier supporte nativement, heu, le parsing des fichiers CSV par exemple.

Il y a aussi les alarmistes, qui pensent tout de suite que telle ou telle fonctionnalité, potentiellement dangereuse va être détournée. Les mauvais programmeurs vont en abuser et rendre la vie des bons programmeurs (ceux qui passent leur temps à corriger et maintenir le travail d’autrui) insupportable. Perso, je préfère reprendre un projet .NET 2.0 de 200K LOC, plutôt qu’un projet .NET 1.1 de 50K LOC. Et il y a fort à parier pour qu’en 2010, je préfère maintenir une solution .NET 4.0 plutôt qu’une solution .NET 2.0. L’inférence de type et les méthodes d’extensions faisaient peur en C# 3.0, mais je me demande dans quelle mesure on en a abusé dans les projets-du-monde-réel. Je n’ai pas assez d’éléments pour juger – vos retours d’expérience m’intéressent – mais je vais quand même y aller de mon pronostic : les exagérations doivent être minoritaires. En ce qui concerne le late-binding en C# 4.0, pour prendre un exemple plus récent, je ne vois pas qui serait prêt à perdre le confort de la complétion et du typage statique pour utiliser le mot clé dynamic sans raison. Mais peut-être me trompè-je ; nous verrons bien.

Quoi qu’il en soit, il est selon moi important de prendre un peu de recul. Le langage est un outil, un moyen. Il fut un temps où la meilleure façon d’arriver à de se faire tabasser dans la rue consistait à porter un t-shirt « I love JavaScript ». De nos jours, c’est devenu le meilleur moyen de choper. On se demande bien pourquoi…

Je crois qu’il faut vraiment voir ça comme un enrichissement du langage. Je ne parle pas des t-shirts, mais de l’apparition de toutes ces fonctionnalités a priori éloignées du couple OO/Imperative Programming dans un langage à accolades. Que penser alors de la possible promotion accordée à la métaprogrammation pour C# 5.0 ? OK, ce n’est pas nouveau et dans une certaine mesure il est déjà possible d’y recourir maintenant, mais exposer le « compiler as a service » comme l’a laissé entendre Anders à la fin de son talk, c’est un choix non-orthodoxe, et un peu plus ambitieux. Le ton semble avoir été donné : C# va probablement se décomplexer de plus en plus et surprendre encore en offrant ce que d’autres langages plus rigides s’interdiraient d’offrir. C’est en tout cas mon sentiment.

Jusqu’à présent, j’ai eu l’impression qu’à chaque nouvelle version du langage les évolutions s’inscrivaient avec une certaine cohérence dans ce qui semble être une vision pragmatique de C# et de la plateforme .NET. Au risque de paraitre complètement vendu, je n’ai pour l’instant pas été sérieusement contrarié ou déçu dans l’histoire C#.

Parmi ceux qui pouvaient crier au scandale en découvrant les expressions lambda ou Linq lors de la sortie de C# 3.0, j’aimerais bien avoir les noms de ceux qui ne peuvent plus s’en passer aujourd’hui, et qui commencent déjà à crier au scandale en voyant poindre le duck typing…