Non, c'est vrai. On peut faire des types sommes et du filtrage de motif en restant tout à fait dans le "budget complexité" de Go, regarde la façon (pas très compliquée) dont ils sont présentés dans OCaml ou Swift par exemple.
Sur ce point, tu as très probablement raison, encore que je ne suis pas sûr que ça s'harmonise parfaitement avec le reste du langage, au sens, ça demande d'introduire une nouvelle notion, pas de changer une notion existante (les constantes en go étant déjà utilisées comme enum, le cas particulier d'utilisation le plus courant). Mais que juste ceci donne droit aux « 40 années de recherche ignorées » me semble légèrement injuste et traduire une réaction à une difficulté à appréhender qu'est-ce qui attire d'autres personnes vers un langage auquel on ne trouve soi-même rien d'intéressant, et de se rassurer intuitivement en pensant que c'est dû uniquement aux outils.
travailler sur Go serait clairement le cas (a), personnellement j'ai plutôt tendance à m'inscrire dans l'approche (b)
Ça c'est quelque chose que je comprends parfaitement, j'ai tendance à penser pareil : autant poursuivre ses idéaux, peut-être que d'autres s'en inspireront après, plutôt que de faire face à des obstacles qu'on pense vraiment évitables.
Par ailleurs, indépendamment de Go, le langage, qui n'a aucun intérêt ou presque, il y a des choses intéressantes dans Go, en particulier l'idée que finalement on peut rendre un langage bof très agréable à utiliser si on met le paquet sur les outils. C'est hors du cadre discuté dans mon journal ci-dessus, et personellement je ne comprends pas encore très bien, scientifiquement, l'articulation entre un langage de programmation et les outils qui l'entourent.
Eh bien en pratique il me semble que c'est quand même un lien à ne pas négliger, même si scientifiquement on n'arrive pas à le définir facilement. Et, autant d'un point de vue théorique il n'y a rien ou presque d'innovant dans Go, d'un point de vue humain, les choix faits sont intéressants à mon avis : ce n'est pas qu'une question d'outils, le succès de ce langage, c'est aussi (et peut-être surtout) une question d'approche par la simplicité (au risque d'être simpliste parfois), optique qui n'est pas du tout à la mode et qui manquait visiblement à pas mal de monde ; je pense que des langages avec des systèmes de types plus évolués pourraient essayer de s'en inspirer un peu.
[^] # Re: go 2.0
Posté par anaseto . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
Sur ce point, tu as très probablement raison, encore que je ne suis pas sûr que ça s'harmonise parfaitement avec le reste du langage, au sens, ça demande d'introduire une nouvelle notion, pas de changer une notion existante (les constantes en go étant déjà utilisées comme enum, le cas particulier d'utilisation le plus courant). Mais que juste ceci donne droit aux « 40 années de recherche ignorées » me semble légèrement injuste et traduire une réaction à une difficulté à appréhender qu'est-ce qui attire d'autres personnes vers un langage auquel on ne trouve soi-même rien d'intéressant, et de se rassurer intuitivement en pensant que c'est dû uniquement aux outils.
Ça c'est quelque chose que je comprends parfaitement, j'ai tendance à penser pareil : autant poursuivre ses idéaux, peut-être que d'autres s'en inspireront après, plutôt que de faire face à des obstacles qu'on pense vraiment évitables.
Eh bien en pratique il me semble que c'est quand même un lien à ne pas négliger, même si scientifiquement on n'arrive pas à le définir facilement. Et, autant d'un point de vue théorique il n'y a rien ou presque d'innovant dans Go, d'un point de vue humain, les choix faits sont intéressants à mon avis : ce n'est pas qu'une question d'outils, le succès de ce langage, c'est aussi (et peut-être surtout) une question d'approche par la simplicité (au risque d'être simpliste parfois), optique qui n'est pas du tout à la mode et qui manquait visiblement à pas mal de monde ; je pense que des langages avec des systèmes de types plus évolués pourraient essayer de s'en inspirer un peu.