L’évolution de C #: le concepteur principal décrit le parcours de modernisation, explique comment devenir fonctionnel

  • FrançaisFrançais


  • Entrevue Le concepteur principal C # Mads Torgersen a ouvert une fenêtre sur l’évolution du langage lors de sa participation à la conférence virtuelle des développeurs QCon Plus la semaine dernière, et a été assez franc sur ce qui a fonctionné et ce qui n’a pas fonctionné.

    Le langage de programmation a “environ deux décennies”, a déclaré Torgersen, “et pendant ce temps [gone] à travers un voyage de transformation… il a commencé comme un langage orienté objet très classique du début du siècle. “

    C # a été créé par Anders Hejlsberg (dont les autres réalisations incluent Borland Delphi et plus récemment Microsoft TypeScript); mais Torgersen travaille sur C # depuis environ 15 ans et en est le concepteur principal depuis cinq ans.

    Les enregistrements en C # 9.0 sont considérés comme égaux s’ils sont du même type et ont des propriétés identiques

    Comment cela a-t-il changé? Torgersen a parlé aux participants de QCon de son adoption progressive des fonctionnalités de la programmation fonctionnelle. Même C # 1.0 avait des types de délégués: «Ce sont des types de fonctions, ils sont vraiment merdiques à bien des égards… mais ils font le travail», dit-il.

    Cependant, C # a rapidement évolué. Génériques (C # 2.0); inférence de type (le mot-clé var) (C # 3.0); Expressions lambda (C # 3.0). En fait, C # 3.0 à la fin de 2007 était une grande version, avec des types anonymes, des méthodes d’extension et des expressions de requête, cette dernière également connue sous le nom de requête intégrée au langage (LINQ).

    «Beaucoup de choses qui se sont produites ont été inspirées / empruntées / volées au monde fonctionnel», a reconnu Torgersen.

    Comment C # se compare-t-il à Scala en tant que langage fonctionnel? «Je ne pense pas que nous arriverons là où C # est un équilibre complet entre fonctionnel et orienté objet», a déclaré Torgersen. «Nous sommes toujours l’objet d’abord, donc nous n’allons jamais rivaliser avec un premier langage fonctionnel … il y a tellement de choses de la programmation fonctionnelle, tellement d’idiomes, une telle quantité d’inférence de type que nous ne pourrons jamais y arriver d’ici . “

    Torgersen a déclaré qu’une grande tendance ces dernières années a été la correspondance de modèles, tirée par le cloud computing où «vos données sont dans le cloud et sont partagées entre de nombreuses applications différentes».

    L’orientation objet, dit-il, n’est pas bien adaptée à ce scénario. “La programmation orientée objet se concentre sur l’encapsulation des fonctionnalités et des données ensemble,” mais dans ce nouveau monde, “empaqueter la fonctionnalité avec les données n’a plus de sens. Vous devez avoir les fonctions à l’extérieur”, ce par quoi il voulait dire , “vous devez écrire une fonction qui prend un objet, l’objet ne connaît pas la fonction, mais la fonction fait des choses différentes selon le type de l’objet. C’est à cela que sert la correspondance de motifs.”

    La correspondance de modèles est arrivée dans C # 7.0, publiée en mars 2017, et a été régulièrement améliorée depuis. C # 9.0, publié cette semaine avec .NET 5.0, a ajouté 6 autres améliorations de modèle, y compris des modèles de type qui correspondent au type d’une variable.

    C # 9.0 introduit également les types d’enregistrement. “La principale chose qu’ils vous donnent est la sémantique des valeurs par défaut”, a déclaré Torgersen. Ce qu’il a à l’esprit est la question apparemment simple de A égal à B. L’orientation objet nécessite normalement d’écrire des méthodes d’égalité pour remplacer les valeurs par défaut, ce qui est “un cauchemar de maintenance”, a-t-il déclaré. Maintenant, avec les types d’enregistrements, «les méthodes synthétisées pour l’égalité et les codes de hachage considèrent deux enregistrements égaux si leurs propriétés sont toutes égales», comme l’expliquent les documents (ils doivent aussi être du même type bien sûr). «C’est une autre étape vers la programmation fonctionnelle», a déclaré Torgersen.

    À quoi sert C #?

    Le C # peut-il être tout pour tout le monde, ou sinon quelle est sa niche, sa valeur particulière par rapport aux autres choix de langage, avons-nous demandé.

    “C # a commencé parce que Windows avait besoin d’un bon langage d’application moderne qui ressemblait un peu à C ++ et Java”, a déclaré Torgersen. “Il était très spécifique dans son ciblage initial. Il avait des types de fonctions qui étaient là presque par erreur, pour des scénarios qui n’avaient rien à voir avec la programmation fonctionnelle. Nous avons poussé dans d’autres scénarios parce que nous avons réussi et que les gens ont aimé, mais il se propage aussi tout seul. Si vous regardez le monde des jeux, la majorité sont écrits dans Unity qui est basé sur un moteur C # qui a été construit en dehors de Microsoft, en partie parce que Mono était open source et facile à bricoler, mais aussi parce qu’ils aimaient C # pour ça.

    Mads Torgersen, concepteur principal C #

    Mads Torgersen, concepteur principal C #

    “L’une des choses que nous avons faites avec chaque version de C # au cours des cinq dernières années a été d’avoir plus de fonctionnalités de bas niveau. C # a toujours pris en charge le code non sécurisé, mais ils ont des codes de bas niveau plus sûrs, efficaces et de bas niveau. C’est un domaine dans lequel nous avons beaucoup investi, même si la plupart des gens ne l’utilisent pas, car cela signifie que la plupart des niveaux inférieurs de votre architecture peuvent être construits en C # et fonctionner sur .NET et être portables. Mais de cela à dire que C # est un langage de programmation système, ce n’est pas quelque chose que nous dirions, et chasser cela serait au détriment du reste du langage. Il y a donc des limites. Nous essayons simplement de le laisser croître de manière organique et chasser des choses qui ont de la valeur maintenant. “

    Il y a dix ans, C # 4.0 a introduit le type dynamique, où le type est résolu au moment de l’exécution. Était-ce un gros problème pour C #?

    «C’était une fonctionnalité de langage intéressante et cela faisait partie d’un refoulement dynamique qui ne s’est pas produit autant que nous l’avions ressenti. Nous faisions IronPython et IronRUby à l’époque, qui étaient des implémentations de Python et Ruby en plus de. NET, et nous voulions avoir une excellente interopérabilité entre ceux-ci ainsi qu’avec JavaScript.Nous avons donc construit toute une infrastructure pour résoudre la dynamique sur .NET.

    «J’ai quelques regrets sur la façon dont nous l’avons construit, car c’est cher à l’exécution. C’est beau, il exécute toutes les fonctionnalités du compilateur pour faire une résolution de surcharge au moment de l’exécution au lieu de la compilation… d’un point de vue théorique qui est super élégant et je J’en suis fier. Mais le coût et les frais généraux sont prohibitifs dans certains scénarios, alors [the] la dynamique ne se marie pas bien avec les performances.

    “Ce n’est pas une fonctionnalité à succès pour C # et parfois je le regrette un peu, mais parfois c’est juste ce qui vous permet d’assembler des choses qui ne seraient pas assemblées autrement… qui me rend heureuse.”

    Qu’en est-il de la sécurité NULL, où le travail a été effectué en C # 8.0 pour ajouter un contexte compatible Nullable au compilateur, dans le but d’éviter les exceptions de référence Null au moment de l’exécution, mais désactivé par défaut. Si cette option est activée, les types de référence ne sont pas Nullable par défaut, mais peuvent être spécifiquement déclarés Nullable si nécessaire, bien qu’il s’agisse d’une fonctionnalité de compilateur et non appliquée par le runtime. C # est-il là où il devrait être à cet égard?

    “C’était une fonctionnalité très importante et épouvantable à faire. La surcharge conceptuelle n’est pas si grande, mais le travail d’ingénierie et les détails sont immenses”, a déclaré Torgersen. «Cela a été similaire à l’expérience de conception TypeScript…. Là où ils ont ce système de type très compliqué qui est conçu pour ne pas se sentir compliqué. Pour null en particulier, nous avons essayé de faire la même chose. Nous voulions vous laisser déposer ces petites annotations en point d’interrogation ici et là, et cela coulerait à merveille dans votre scénario.

    “Nous nous sommes donné du temps avec C # 9.0, peut-être un peu plus longtemps, pour dire OK, il ne s’agit que d’avertissements, pas d’erreurs. Nous allons nous permettre de le bricoler. Je pense que nous sommes dans la longue traîne maintenant. Je pense nous avons pratiquement terminé. “

    Lorsqu’on lui a demandé s’il y avait quelque chose en C # qu’il aimerait retirer, Torgersen a déclaré: “Ce premier coup de feu sur les littéraux de fonction, les méthodes anonymes, était une erreur maladroite. Nous l’avons écrasé immédiatement en C # 3.0. Bien sûr, nous ne pouvons pas le supprimer. . “

    C’est la chose, vous pouvez ajouter des choses à un langage de programmation, mais pas les supprimer. «Les gens… ont du code qu’ils ont commis et si vous retirez quelque chose ou changez ce que cela signifie, vous cassez beaucoup: nous ne pouvons pas faire ça», dit-il.

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *