Mais pourtant on te l'a expliqué que les développeurs de Go, sur cet aspect, connaissait ce que tu énonçais mais l'ont ignoré pour certaines raisons. Tu peux dire ce que tu veux, mais ils ont fait un choix, un compromis et c'est nécessaire d'en faire sur certains sujets.
Il y a des choix qui sont suffisamment motivés pour être justifiables, il y a des choix qui sont des fautes.
Je ne devrais pas avoir besoin de me justifier sur l'idée suivante : si on est payé pour construire un langage de programmation qui a vocation à être adopté largement, il est naturel et important de se renseigner un peu auprès de gens qui étudient scientifiquement ce domaine. C'est assez facile, c'est gratuit, il suffit de contacter des personnes connues dans la communauté de recherche (ou les bonnes mailing-list) et d'espérer être redirigé vers des personnes intéressées par une discussion ou une collaboration. C'est une faute de ne pas le faire !
Si quelqu'un décidait d'écrire un projet de loi important sans consulter un juriste, de construire bâtiment public important sans contacter un architecte ou un spécialiste de l'accessibilité au handicap, on trouverait ça choquant.
Si on pense que la recherche en langages de programmation ne sert à rien, il faut le dire clairement et on en discute. (Par exemple, j'ai expliqué dans mon document qu'il y a beaucoup d'autres domaines qui pourraient avoir des apports intéressants, un angle de critique serait de dire que ces domaines seraient plus importants et ne sont pas assez explorés.) Mais vous ne pouvez pas dire à la fois "oui, on est convaincu que c'est utile" et "ah mais les créateurs de Go n'en avaient rien à battre, mais il ne faut pas leur en vouloir, tout le monde fait des choix". Quand on se lance dans un projet lourd sur de nombreuses années, et qu'on ne consulte pas une communauté de gens dont les idées sont importantes et utiles pour le projet, on a merdé, pourquoi est-ce si difficile de reconnaître cette évidence ?
Honnêtement, je ne suis toujours pas convaincu que c'est un manque aussi important que tu l'énonces.
C'est peut-être aussi parce que tu n'as pas l'habitude d'utiliser cette fonctionnalité, parce que les langages que tu utilises le plus souvent ne l'ont toujours pas. Les connaissances de la communauté de programmation évoluent très lentement, l'inertie est forte, donc ça bouge lentement. Mais une fois qu'on a découvert, on peut difficilement s'en passer ! Avec Rust et Swift qui ont des types sommes, il y a de plus en plus de gens qui vont découvrir et bientôt ça paraîtra une évidence qu'il faut en avoir dans un langage (comme les fonctions anonymes, les génériques (si le langage est typé), ou la sûreté mémoire par défaut). Go aurait pu être une occasion pour un nouveau public de découvrir, c'est une occasion manquée, c'est très dommage.
(Au passage: Swift est beaucoup plus intéressant que Go comme langage, alors qu'il a les même buts d'offrir une transition en douceur pour des développeurs dans un langage impératif existant (Objective-C). C'est pour beaucoup une question de culture — Chris Lattner est au courant du fait que la programmation fonctionnelle existe — et c'est sur ça qu'on peut influer avec un peu de bonne volonté de tous les côtés.)
[^] # Re: go 2.0
Posté par gasche . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 6. Dernière modification le 19 octobre 2017 à 11:37.
Il y a des choix qui sont suffisamment motivés pour être justifiables, il y a des choix qui sont des fautes.
Je ne devrais pas avoir besoin de me justifier sur l'idée suivante : si on est payé pour construire un langage de programmation qui a vocation à être adopté largement, il est naturel et important de se renseigner un peu auprès de gens qui étudient scientifiquement ce domaine. C'est assez facile, c'est gratuit, il suffit de contacter des personnes connues dans la communauté de recherche (ou les bonnes mailing-list) et d'espérer être redirigé vers des personnes intéressées par une discussion ou une collaboration. C'est une faute de ne pas le faire !
Si quelqu'un décidait d'écrire un projet de loi important sans consulter un juriste, de construire bâtiment public important sans contacter un architecte ou un spécialiste de l'accessibilité au handicap, on trouverait ça choquant.
Si on pense que la recherche en langages de programmation ne sert à rien, il faut le dire clairement et on en discute. (Par exemple, j'ai expliqué dans mon document qu'il y a beaucoup d'autres domaines qui pourraient avoir des apports intéressants, un angle de critique serait de dire que ces domaines seraient plus importants et ne sont pas assez explorés.) Mais vous ne pouvez pas dire à la fois "oui, on est convaincu que c'est utile" et "ah mais les créateurs de Go n'en avaient rien à battre, mais il ne faut pas leur en vouloir, tout le monde fait des choix". Quand on se lance dans un projet lourd sur de nombreuses années, et qu'on ne consulte pas une communauté de gens dont les idées sont importantes et utiles pour le projet, on a merdé, pourquoi est-ce si difficile de reconnaître cette évidence ?
C'est peut-être aussi parce que tu n'as pas l'habitude d'utiliser cette fonctionnalité, parce que les langages que tu utilises le plus souvent ne l'ont toujours pas. Les connaissances de la communauté de programmation évoluent très lentement, l'inertie est forte, donc ça bouge lentement. Mais une fois qu'on a découvert, on peut difficilement s'en passer ! Avec Rust et Swift qui ont des types sommes, il y a de plus en plus de gens qui vont découvrir et bientôt ça paraîtra une évidence qu'il faut en avoir dans un langage (comme les fonctions anonymes, les génériques (si le langage est typé), ou la sûreté mémoire par défaut). Go aurait pu être une occasion pour un nouveau public de découvrir, c'est une occasion manquée, c'est très dommage.
(Au passage: Swift est beaucoup plus intéressant que Go comme langage, alors qu'il a les même buts d'offrir une transition en douceur pour des développeurs dans un langage impératif existant (Objective-C). C'est pour beaucoup une question de culture — Chris Lattner est au courant du fait que la programmation fonctionnelle existe — et c'est sur ça qu'on peut influer avec un peu de bonne volonté de tous les côtés.)