Codingly

Le futur de C# ?

Posted in Posts by Romain Verdier on novembre 15, 2008

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.

anders hejlsberg as austin powersIl 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…

Tagged with: ,

5 Réponses

Subscribe to comments with RSS.

  1. Olivier said, on novembre 16, 2008 at 10:25

    Je suis partagé entre 2 sentiments quant aux versions qui s’enchaînent : admiration et lassitude.

    J’admire les innovations et la réactivité de Microsoft dans ces différentes sorties de .NET et C# : Linq, extensions, lambda, sans compter les WCF, WPF, WWF, ASP.NET MVC & co et voilà qu’on nous parle de C# 4 avec notamment les dynamics, les paramètres optionnels et j’en passe (http://tinyurl.com/5lcz5w). Oui, j’admire la machine, la force de développement de Microsoft pour répondre aux besoins des développeurs [de façon itérative et incrémentale], MS a bien changé depuis ~2003 et en bien, pratique agile quand tu nous tiens. On ne peut que remercier les équipes de Redmond pour toutes ces améliorations qui nous facilitent (quand même) bien la vie, et qui répondent à un périmètre de besoins toujours plus large (trop ?).

    Mais, car il y a un mais, pour les clients finaux, cela devient dur, très dur de suivre le rythme que MS nous impose. Dit changement de version, dit migration, et ce n’est jamais trivial comme chantier, sans compter les coûts indirects que cela engendre. Ensuite, après un changement de version, il reste également une courbe d’apprentissage non négligeable pour appréhender toutes les nouveautés plus ou moins ardues parfois, une journée ne dure que 24 h ;) Alors je me pose souvent la question : est-ce pour concurrencer des frameworks de type RoR (et donc Ruby avec le Duck Typing par exemple), aspect marketing ou est-ce des innovations pour tenter d’être leader et non plus suiveur sur certains paradigmes et faciliter réellement la vie aux développeurs, et est-ce vraiment in fine *vraiment* utile.

    A peine migré [notre plateforme] vers .NET 3.5, que les blogs nous parlent déjà de C# 4.0, et nous donnent envie de découvrir cette nouvelle version, quelle teasing ! Il y a à peine 2 mois, notre DSI me posait la question suivante : « quel gain pour les utilisateurs [au sujet de la migration vers 3.5] »…sic…prends ça dans ta face…pas préparé, j’ai juste répondu un gain de performances, et une productivité accrue, je ne sais pas s’il a été convaincu.

    Innover, évoluer, oui, bien entendu que cela reste positif, surtout lorsque l’on voit les réussites que MS a produit jusqu’à présent. Mais on a juste du mal à suivre par moment et à se justifier auprès de nos décideurs, qui ont des objectifs bien différents des nôtres, souvent budgétaires ou de stabilisation du S.I. Alors merci MS de nous donner quelques arguments SVP, au-delà de la technique ;)

    Merci pour le blog sur les entrailles de C#, vraiment intéressant !

  2. […] : C#4 ou Oxygene (Delphi) novembre 29, 2008 — grozeille Suite au post de Romain sur l’avenir du langage C#, je voulais non seulement répondre, mais en profiter pour parler brièvement d’un autre […]

  3. grozeille said, on novembre 29, 2008 at 1:35

    Puisque j’ai commencé à faire une réponse trop longue, et que je dévire souvent de sujet -_-‘, la voici

  4. EVilz said, on décembre 15, 2008 at 12:56

    Hello,

    Si tes poses café durent 3min, combien de poses tu as pris pour écrire tout ça ?

    Par rapport à la question du DSI d’Olivier, j’aurais répondu la phrase magique :
    « Ca dépend »

    Pour une appli qui marche déjà bien … je ne vois pas l’intéret d’y toucher
    Pour une nouvelle appli un gain de productivité, Quand on voit que maintenant on utilise facilement Linq To Sql (ou EF) et qu’il y a encore quelques années on ecrivait nos procédures SQL et notre couche de DAL et même nos collections Typé …

    Moi je regrette juste que MS parle trop tôt de leurs nouveautés, je préfère la stratégie d’apple … mais bon

  5. olive said, on mai 20, 2010 at 1:25

    hi,mais c’est vrai hein,ca va super vite la bande à Redmond,faut ralentir on arrive pas trop à suivre,me bon je pense qu’ils ne veulent pas se faire rattraper quoi.


Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :