Les cas simples avec les type-class sont ok, c'est sans doute plus une question de savoir les présenter (donc pas propre au langage) : parmi les première que décrivent pas mal de tutos, c'est celle des monades ; et, il me semble (mais ça fait plusieurs années que je fais pas de Haskell), que pour des choses concrètes équivalentes au Writer et Reader de Go, il faut aller chercher dans les packages. Après, le fait qu'il soit possible de faire des classes sur des types plus complexes et des concepts plus avancés n'est pas intéressant pour un langage comme Go : un principe du langage c'est qu'au bout d'une semaine tu peux lire le code de n'importe qui sans barrière de compétence sur le langage. Du coup, au mieux, ils auraient pu viser un sous-ensemble de la solution à base de type-class ; est-ce qu'en pratique le résultat aurait changé beaucoup par rapport aux interfaces ?
[^] # Re: go 2.0
Posté par anaseto . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 2.
Les cas simples avec les type-class sont ok, c'est sans doute plus une question de savoir les présenter (donc pas propre au langage) : parmi les première que décrivent pas mal de tutos, c'est celle des monades ; et, il me semble (mais ça fait plusieurs années que je fais pas de Haskell), que pour des choses concrètes équivalentes au Writer et Reader de Go, il faut aller chercher dans les packages. Après, le fait qu'il soit possible de faire des classes sur des types plus complexes et des concepts plus avancés n'est pas intéressant pour un langage comme Go : un principe du langage c'est qu'au bout d'une semaine tu peux lire le code de n'importe qui sans barrière de compétence sur le langage. Du coup, au mieux, ils auraient pu viser un sous-ensemble de la solution à base de type-class ; est-ce qu'en pratique le résultat aurait changé beaucoup par rapport aux interfaces ?