IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Google pourrait apporter la prise en charge du paramétrage de type à son langage Go plus tard cette année
Permettant aux développeurs de bénéficier d'une forme de programmation générique

Le , par Stéphane le calme

221PARTAGES

12  0 
Go pourrait enfin bénéficier des génériques, longtemps recherchés par de nombreux utilisateurs du langage de Google comme un mécanisme pour simplifier le langage. Une proposition de changement de langage Go déposée le 12 janvier dans GitHub appelle à l'ajout de la prise en charge des paramètres de type pour les types et les fonctions, permettant ainsi une forme de programmation générique. Les efforts pour ajouter des génériques à Go se poursuivent depuis des années, la prise en charge des génériques étant l'une des fonctionnalités les plus demandées depuis la sortie de Go en 2009. Désormais, les développeurs de Go peuvent espérer voir une implémentation d'ici la fin de cette année, peut-être inclus dans les versions bêta de Go 1.18. La mise en œuvre serait complète, mais peut-être pas entièrement optimisée.

En programmation, la généricité (ou programmation générique) consiste à définir des algorithmes identiques opérant sur des données de types différents. On définit de cette façon des procédures ou des types entiers génériques. On pourrait ainsi programmer une pile, ou une procédure qui prend l'élément supérieur de la pile, indépendamment du type de données contenues.

C'est donc une forme de polymorphisme, le « polymorphisme de type » dit aussi « paramétrage de type » : en effet, le type de donnée général (abstrait) apparaît comme un paramètre des algorithmes définis, avec la particularité que ce paramètre-là est un type. C'est un concept important pour un langage de haut niveau, car il permet d'écrire des algorithmes généraux opérant sur toute une série de types : la généricité augmente donc le niveau d'abstraction des programmes écrits dans un langage qui possède cette fonctionnalité. Divers mécanismes ont été conçus pour permettre la programmation générique.

Ian Lance Taylor a expliqué sur la page dédiée à Go :

« Nous avons déposé une proposition de changement de langage Go pour ajouter la prise en charge des paramètres de type pour les types et les fonctions, permettant une forme de programmation générique.

« Les génériques peuvent nous donner des blocs de construction puissants qui nous permettent de partager du code et de créer des programmes plus facilement. La programmation générique signifie écrire des fonctions et des structures de données où certains types doivent être spécifiés ultérieurement. Par exemple, vous pouvez écrire une fonction qui opère sur une tranche d'un type de données arbitraire, où le type de données réel n'est spécifié que lorsque la fonction est appelée. Vous pouvez également définir une structure de données qui stocke des valeurs de tout type, où le type réel à stocker est spécifié lorsque vous créez une instance de la structure de données.

« Depuis la sortie de Go pour la première fois en 2009, la prise en charge des génériques est l'une des fonctionnalités du langage les plus demandées.

« Bien que les génériques aient des cas d'utilisation clairs, les adapter proprement dans un langage comme Go est une tâche difficile. L'une des premières tentatives (erronées) d'ajouter des génériques à Go remonte à 2010. Il y en a eu plusieurs autres au cours de la dernière décennie.

« Depuis quelques années, nous travaillons sur une série de projets de conception qui ont abouti à une conception basée sur des paramètres de type. Ce projet de conception a reçu beaucoup de commentaires de la communauté de programmation Go, et de nombreuses personnes l'ont expérimenté en utilisant le terrain de jeu générique décrit dans un billet de blog précédent. Ian Lance Taylor a donné un discours à la GopherCon 2019 sur les raisons d'ajouter des génériques et la stratégie que nous suivons maintenant. Robert Griesemer a donné un discours de suivi sur les changements dans la conception et la mise en œuvre à GopherCon 2020. Les changements de langage sont entièrement rétrocompatibles, de sorte que les programmes Go existants continueront à fonctionner exactement comme ils le font aujourd'hui. Nous avons atteint le point où nous pensons que le projet de conception est assez bon et assez simple pour proposer de l'ajouter à Go ».


Les génériques peuvent fournir des blocs de construction puissants pour partager du code et créer plus facilement des programmes. Avec la programmation générique, l'écriture de fonctions et de structures de données peut être effectuée d'une manière où certains types sont spécifiés par la suite. Par exemple, un développeur pourrait écrire une fonction qui opère sur une tranche d'un type de données arbitraire, où le type de données réel est spécifié lorsque la fonction est appelée. Un développeur pourrait également définir une structure de données qui stocke des valeurs de tout type, dans laquelle le type réel à stocker est spécifié lorsqu'une instance de la structure de données est créée.

Les changements de haut niveau dans la proposition de programmation générique pour Go comprennent ceci :
  • Les fonctions peuvent avoir une liste de paramètres de type supplémentaire qui utilise des crochets, mais qui autrement ressemble à une liste de paramètres ordinaire: func F [T any] (p T) {...}
  • Ces paramètres de type peuvent être utilisés par les paramètres réguliers et dans le corps de la fonction.
  • Les types peuvent également avoir une liste de paramètres de type: type MySlice [T any] [] T
  • Chaque paramètre de type a une contrainte de type, tout comme chaque paramètre ordinaire a un type : func F [T Constraint] (p T) {...}
  • Les contraintes de type sont des types d'interface.
  • Le nouveau nom prédéclaré any est une contrainte de type qui autorise n'importe quel type.
  • Les types d'interface utilisés comme contraintes de type peuvent avoir une liste de types prédéclarés; seuls les arguments de type qui correspondent à l'un de ces types satisfont à la contrainte.
  • Les fonctions génériques ne peuvent utiliser que les opérations autorisées par leurs contraintes de type.
  • L'utilisation d'une fonction ou d'un type générique nécessite de passer des arguments de type.
  • L'inférence de type permet d'omettre les arguments de type d'un appel de fonction dans les cas courants.

Adapter les génériques à un langage tel que Go est une tâche difficile, comme l'indiquent des tentatives infructueuses datant de 2010. Au cours des deux dernières années, les développeurs de Go ont travaillé sur une série de projets de conception qui ont abouti à une conception basée sur des paramètres de type. Le projet a reçu la contribution de la communauté de programmation Go, et il y a eu quelques expériences avec lui via le terrain de jeu des génériques. Les changements de langage prévus pour la prise en charge des génériques sont rétrocompatibles, de sorte que les programmes Go existants continueraient à fonctionner.

« Le processus de proposition de changement dans le langage est la façon dont nous apportons des modifications au langage Go. Nous avons maintenant commencé ce processus pour ajouter des génériques à une future version de Go. Nous invitons les critiques et les commentaires de fond, mais essayez d'éviter de répéter les commentaires précédents et essayez d'éviter les simples commentaires plus un et moins un. Au lieu de cela, ajoutez des réactions emoji « pouce vers le haut / pouce vers le bas » aux commentaires avec lesquels vous êtes d'accord ou en désaccord, ou à la proposition dans son ensemble.

« Comme pour toutes les propositions de changement dans le langage, notre objectif est de parvenir à un consensus pour soit ajouter des génériques au langage, soit laisser tomber la proposition. Nous comprenons que pour un changement de cette ampleur, il sera impossible de rendre tout le monde heureux dans la communauté de Go, mais nous avons l'intention de prendre une décision que tout le monde est prêt à accepter.

« Si la proposition est acceptée, notre objectif sera d'avoir une implémentation complète, mais peut-être pas entièrement optimisée, que les gens pourront essayer d'ici la fin de l'année, peut-être dans le cadre des bêtas Go 1.18 ».

Source : billet de blog Go

Et vous ?

Utilisez-vous Go ? Si oui, qu'en pensez-vous ?
Que pensez-vous de la programmation générique dans l'absolu ?
Êtes-vous pour ou contre une forme de programmation générique dans Go ?

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de Uther
Expert éminent sénior https://www.developpez.com
Le 13/02/2021 à 18:14
Je pense que le Go n'a juste pas su tirer des leçons de ce qui est arrivé à Java.

Java est lui aussi né de la volonté de faire un C++ simplifié, débarrassé des problématiques un peu trop complexes comme la gestion mémoire, l’héritage multiple et les templates. Le type Object permettait en théorie de contourner le problème, mais à l'usage, ils se sont assez vite rendu compte qu'un support minimum de la généricité manquait vraiment pour avoir un code correctement contraint par le typage. Et ils ont finalement choisi d'introduire les génériques dans Java 1.4

Go a voulu essayer de faire plus ou moins la même chose (l'interface vide reprenant le rôle du type Object), en poussant encore plus loin dans la simplification du modèle objet, mais il a fini par arriver à la même conclusion que Java en ce qui concerne la généricité.
5  0 
Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 13/02/2021 à 20:02
Utilisez-vous Go ? Si oui, qu'en pensez-vous ?

Oui, quand je peux, mais surtout pour des WebServices ou des outils de maintenance en CLI.
J'en pense que c'est un très bon langage pour mes usages.
Il remplace facilement un langage de script, tout en étant beaucoup moins sujet aux erreurs que des langages de même niveau et beaucoup plus simple à déployer et rapide à compiler.
Après, je suis loin d'utiliser tous les outils du langage comme la cross-compilation native et autres.

Que pensez-vous de la programmation générique dans l'absolu ?

Tout ce qui peut me permettre d'écrire moins de code pour un résultat équivalent est la bienvenue .

Êtes-vous pour ou contre une forme de programmation générique dans Go ?

Pour, si c'est bien pensé, ce qui a l'air d'être le cas ici.
A voir à l'usage quand ça sera implémenté.

@Pyramidev : La citation de Mr Pike me fait furieusement pensé à Pascal pour le coup.
@Pyramidev & @Uther : Après c'est vrai que l'on peut reprocher le manque de fonctionnalité au langage, mais n'empêche ce côté simple et pratique manque dans tous les autre langages que vous cités.

- C++ est nait comme un sur-ensemble de C et à donc hérité de tous ces défauts en ajoutant beaucoup de complexités.
D'ailleurs à l'usage, la forme moderne la plus utilisé de C++, c'est Qt (d'après constatations en entreprise, mais je peut me tromper) qui rajoute pas mal de métaprogrammation / méta-compilation pour simplifier les liaisons entre instances et classes (Signal/Slot).
Mais bon pour moi le Go ne remplacera pas le C++ contrairement à Rust ou même ADA, Delphi, ...etc qui eux seraient dans la même niche.

- Java est lui aussi de plus en plus complexe, sans parlé du tooling qui gravite autour est qui nécessite sur chaque projet de ce renseigner sur le workflow à utilisé (la génération d'artefact s'est bien normalisé, mais après Ant, Maven et maintenant Gradle, s'aurait était bien d'avoir un outils standard pour ça comme avec Go).
[lol]La politique d'Oracle sur le support va bien finir par achever le langage de toute façon [/lol]

Et puis, ce sont tous les deux des langage Objet ce qui en sois ne les met pas dans la même catégorie que Go niveau complexité.
Sans compter que moi même je ne mettrais pas Java est C++ dans le même panier côté complexité.
Pour ce que j'en sais, Go ne remplacera pas Java, comme Java n'as pas remplacé C++, ils on tous leurs points fort et leur points faibles (et leurs bases de code installé surtout ).

Pour ce que j'en fait, Go est simple, compile vite, a une lib standard assez fournit et offre un tooling standard très largement satisfaisant.
J'ai plus tendance à l'utilisé à la place de script Perl/Python ou PHP (qui sont normalement beaucoup plus haut niveau) que pour remplacer une appli existante fonctionnel.
Enfin, quand vous faite du Go, vous ne bénéficiez pas du même support qu'avec Java ou C++ au niveau des lib fournit par les sociétés sur leurs outils propriétaire.
Donc, sauf à faire des outils standalone comme des Web Services ou de la CLI, vous êtes forcement plus limiter (pour l'instant, vu que tout ce "Cloudify" ).
3  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 13/02/2021 à 17:17
Dans sa philosophie même, Go est un langage qui cherche à n'avoir presque pas de fonctionnalités. C'est dans le but d'être facile à apprendre. Comme l'a dit Rob Pike, un des créateurs du Go :
Citation Envoyé par Rob Pike
The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt.
Normalement, cela devrait avoir tendance à repousser les développeurs qui aiment les fonctionnalités manquantes en Go.

Du coup, je me demande quels sont les profils de développeurs les plus courants qui aiment bénéficier de la programmation générique mais qui, malgré cela, programment actuellement en Go.
  • S'agit de développeurs qui, en suivant la hype, se sont mis au Go avant de se rendre compte que, n'avoir presque pas de fonctionnalités, finalement, ce n'est pas si fun que ça ?
  • S'agit de développeurs qui ne sont pas vraiment intéressés par ce langage, mais par des offres d'emploi intéressantes et bien payées dont Go fait partie des langages utilisés ?

Cela dit, si la programmation générique est ajoutée au langage Go, tant mieux.
2  0 
Avatar de
https://www.developpez.com
Le 14/02/2021 à 21:35
Quand je lis les discussions sur le Go je vois les gens comparer le langage principalement avec Java voir C# alors que de mon point de vue c'est les langages de script pour le web que ca va gratter. Dans le développement web on a depuis quelques années une tendance vers le typage fort dans les langages de script : Typescript gagne du terrain et PHP depuis la version 7.4 supporte nativement le typage fort.

Vu que nous sommes maintenant dans un monde d'API et que les vues sont de moins en moins générées par un backend, Go se présente comme un langage simple de prise en main et d'utilisation dont la seule vraie difficulté d'adoption venant de ces langages de scripts typés se situe dans la gestion des pointeurs. Ça a aussi l'avantage d'être extrêmement simple à déployer, plus tous les autres avantages d'un langage de plus bas niveau.
1  0 
Avatar de youtpout978
Expert confirmé https://www.developpez.com
Le 13/02/2021 à 20:57
Citation Envoyé par Pyramidev Voir le message
Dans sa philosophie même, Go est un langage qui cherche à n'avoir presque pas de fonctionnalités. C'est dans le but d'être facile à apprendre. Comme l'a dit Rob Pike, un des créateurs du Go :

Normalement, cela devrait avoir tendance à repousser les développeurs qui aiment les fonctionnalités manquantes en Go.

Du coup, je me demande quels sont les profils de développeurs les plus courants qui aiment bénéficier de la programmation générique mais qui, malgré cela, programment actuellement en Go.
  • S'agit de développeurs qui, en suivant la hype, se sont mis au Go avant de se rendre compte que, n'avoir presque pas de fonctionnalités, finalement, ce n'est pas si fun que ça ?
  • S'agit de développeurs qui ne sont pas vraiment intéressés par ce langage, mais par des offres d'emploi intéressantes et bien payées dont Go fait partie des langages utilisés ?

Cela dit, si la programmation générique est ajoutée au langage Go, tant mieux.
J'ai l'impression que c'est beaucoup utilisé sur des projets où on a besoin de WebServices performants.
0  0 
Avatar de dolanor
Membre habitué https://www.developpez.com
Le 16/02/2022 à 16:43
Citation Envoyé par Uther Voir le message
Je pense que le Go n'a juste pas su tirer des leçons de ce qui est arrivé à Java.

Java est lui aussi né de la volonté de faire un C++ simplifié, débarrassé des problématiques un peu trop complexes comme la gestion mémoire, l’héritage multiple et les templates. Le type Object permettait en théorie de contourner le problème, mais à l'usage, ils se sont assez vite rendu compte qu'un support minimum de la généricité manquait vraiment pour avoir un code correctement contraint par le typage. Et ils ont finalement choisi d'introduire les génériques dans Java 1.4

Go a voulu essayer de faire plus ou moins la même chose (l'interface vide reprenant le rôle du type Object), en poussant encore plus loin dans la simplification du modèle objet, mais il a fini par arriver à la même conclusion que Java en ce qui concerne la généricité.
Ce n'est pas vraiment exactement ce qui s'est passé.
En effet, ils avaient toujours la vision de la simplification, et que le code générique est en général plus complexe à lire.
Par contre, ils voulaient malgré tout l'ajouter pour tout le monde, mais ils n'avaient pas trouvé la bonne manière de le faire correctement. En attendant, interface{} faisait assez de chose pour pas mal de cas. Plutôt que d'ajouter les génériques dans une mauvaise version et faire machine arrière plus tard, ils ont préféré trouver la bonne manière. Cela leur a pris des années, et plusieurs tentatives avant de trouver un bon compromis (temps de compilation, taille de binaire, temps d'execution, lisibilité du code, facilité d'écriture du code, etc).
Donc finalement, après toutes ces années d'effort, on a le meilleur résultats qu'ils ont pu atteindre. (je pense qu'il y a eu plus de 7 implémentations).
0  0