Ce que tu dis est vrai mais s'applique à toutes les fonctionnalités d'un langage de programmation. C'est pareil pour les booléens (qui sont en fait un cas particulier de type somme), et pourtant on ne retire pas if/then/else du langage ! C'est pareil aussi pour les fonctions anonymes (les lambda-expressions), qui ont été apportées aux langages "mainstream" par des théoriciens, et qui sont maintenant très courantes parce qu'on se rend compte, à l'usage, que c'est bien pratique. (D'ailleurs elles existent aussi en Go, donc quelqu'un a fait le choix d'implémenter le truc, d'écrire la documentation, etc. etc.)
Je reste de l'avis que c'est une faute de ne pas l'implémenter. Le coût n'est pas si élevé, surtout si on les prend en compte dès la création du langage, et ça permet vraiment de mieux représenter les données que l'on manipule.
Si un constructeur de voiture ne se tient pas au courant des dernières pratiques de sûreté, et n'applique pas une idée (développée au départ par un concurrent) qui permet d'éviter certains accidents sans surcoût à la production (mais avec le coût de se former dessus, de modifier la chaîne de production, etc.), et qu'il y a des gens qui ont un accident, on peut légitimement dire que le constructeur n'a pas fait son boulot correctement.
Quand il y aura un bug qui fera exploser en vol le système d'administration, codé en Go, du cloud d'un gros fournisseur, l'impact (financier, humain, etc.) peut être énorme. Ce sera peut-être une erreur qui aurait été évitée facilement si le langage avait eu des types sommes. (L'erreur de validation SSL citée dans le document est tout à fait de cet ordre.) Et sans aller vers ce catastrophisme, les types sommes peuvent améliorer la vie des programmeurs tous les jours. (Tout comme le GC, les fonctions anonymes, l'inférence de types, etc.)
[^] # Re: go 2.0
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Ce que tu dis est vrai mais s'applique à toutes les fonctionnalités d'un langage de programmation. C'est pareil pour les booléens (qui sont en fait un cas particulier de type somme), et pourtant on ne retire pas
if/then/elsedu langage ! C'est pareil aussi pour les fonctions anonymes (les lambda-expressions), qui ont été apportées aux langages "mainstream" par des théoriciens, et qui sont maintenant très courantes parce qu'on se rend compte, à l'usage, que c'est bien pratique. (D'ailleurs elles existent aussi en Go, donc quelqu'un a fait le choix d'implémenter le truc, d'écrire la documentation, etc. etc.)Je reste de l'avis que c'est une faute de ne pas l'implémenter. Le coût n'est pas si élevé, surtout si on les prend en compte dès la création du langage, et ça permet vraiment de mieux représenter les données que l'on manipule.
Si un constructeur de voiture ne se tient pas au courant des dernières pratiques de sûreté, et n'applique pas une idée (développée au départ par un concurrent) qui permet d'éviter certains accidents sans surcoût à la production (mais avec le coût de se former dessus, de modifier la chaîne de production, etc.), et qu'il y a des gens qui ont un accident, on peut légitimement dire que le constructeur n'a pas fait son boulot correctement.
Quand il y aura un bug qui fera exploser en vol le système d'administration, codé en Go, du cloud d'un gros fournisseur, l'impact (financier, humain, etc.) peut être énorme. Ce sera peut-être une erreur qui aurait été évitée facilement si le langage avait eu des types sommes. (L'erreur de validation SSL citée dans le document est tout à fait de cet ordre.) Et sans aller vers ce catastrophisme, les types sommes peuvent améliorer la vie des programmeurs tous les jours. (Tout comme le GC, les fonctions anonymes, l'inférence de types, etc.)