(C'est quand même vraiment très con d'écrire (a, err) := foo(bar), en sachant que a n'est pas défini si err est nil !)
C'est moins satisfaisant qu'un type somme, en effet. Mais j'ai du mal à en faire tout un pâté inadmissible comme toi : en tous cas, j'ai codé en Go et OCaml, et (a, err) := m'a pas causé plus de soucis que les exceptions (invisibles dans la signature) en OCaml ; en fait moins : d'accord, c'est peut-être juste parce qu'on abuse des exceptions en OCaml, donc pas propre au langage, mais on trouve cela jusque dans la librairie standard.
Je remarque que parfois les programmeurs et programmeuses rechignent à admettre des défauts de leurs langages parce qu'il y a une dimension communautaire voire marketing au choix du langage : on a besoin que les langages qu'on utilise séduisent les gens pour avoir plus d'outils et de bibliothèques, donc il faut avoir un discours positif et ne pas insister sur ses points faibles. Je pense que cette forme de subjectivité est inévitable dans certains contextes, mais elle n'a pas sa place dans le contexte de discussions sur la recherche en langage de programmation, où il faut essayer de s'exprimer au maximum de façon réaliste et précise.
En effet, mais il me semble que tu prends la chose aussi un peu trop à cœur (ou du moins ta prose en donne l'impression) pour apparaître totalement objectif aussi, car en ayant une vision trop ancrée système de types, on finit par ne voir plus que cela dans le langage ; je vois ça dans ma communauté aussi (qui est similaire à la tienne), et même si je comprends et moi aussi j'apprécie les avancées dans le domaine, j'aimerais voir plus d'auto-critique sur certains langages : par exemple Haskell suit la voit de la complexité et des pragmas à tout va, OCaml de plus en plus aussi, avec tout plein d'annotations spéciales maintenant, qu'ils finissent par ressembler au C++ et ça fait peur ; surtout qu'OCaml est un langage que j'aime bien en dehors de quelques manques et fonctions dans la librairie standard et la syntaxe, plus la couche objet qui n'est pas rentable à mon avis, et la syntaxe limitée pour la programmation impérative avec des tableaux (qui a le mérite d'exister, contrairement au cas d'Haskell).
[^] # Re: go 2.0
Posté par anaseto . En réponse au journal Pourquoi la recherche en langages de programmation ?. Évalué à 4.
C'est moins satisfaisant qu'un type somme, en effet. Mais j'ai du mal à en faire tout un pâté inadmissible comme toi : en tous cas, j'ai codé en Go et OCaml, et
(a, err) :=m'a pas causé plus de soucis que les exceptions (invisibles dans la signature) en OCaml ; en fait moins : d'accord, c'est peut-être juste parce qu'on abuse des exceptions en OCaml, donc pas propre au langage, mais on trouve cela jusque dans la librairie standard.En effet, mais il me semble que tu prends la chose aussi un peu trop à cœur (ou du moins ta prose en donne l'impression) pour apparaître totalement objectif aussi, car en ayant une vision trop ancrée système de types, on finit par ne voir plus que cela dans le langage ; je vois ça dans ma communauté aussi (qui est similaire à la tienne), et même si je comprends et moi aussi j'apprécie les avancées dans le domaine, j'aimerais voir plus d'auto-critique sur certains langages : par exemple Haskell suit la voit de la complexité et des pragmas à tout va, OCaml de plus en plus aussi, avec tout plein d'annotations spéciales maintenant, qu'ils finissent par ressembler au C++ et ça fait peur ; surtout qu'OCaml est un langage que j'aime bien en dehors de quelques manques et fonctions dans la librairie standard et la syntaxe, plus la couche objet qui n'est pas rentable à mon avis, et la syntaxe limitée pour la programmation impérative avec des tableaux (qui a le mérite d'exister, contrairement au cas d'Haskell).