Dans la plupart des langages, les concepts "dans le langages" peuvent exploiter des informations et des outils auxquelles les bibliothèques externes n'ont pas accès. Les langages où ça ne se voit pas trop sont les langages dont le cœur est extrêmement minimaliste (je pense à Forth par exemple, où on a l'impression que rien n'est "dans le langage") et les langages qui insistent énormément sur l'extensibilité (comme Scheme; l'approche Racket est exemplaire dans le style "tout implémenter sous forme de bibliothèque", mais ça demande un travail considérable).
Concrètement, l'intérêt des slices "dans le langage" c'est d'avoir une syntaxe agréable pour gérer ça. Les opérations peuvent très bien être écrites de façon externe dans une bibliothèque, mais si on voulait une bibliothèque qui apporte ce sucre syntaxique il faudrait ajouter une facilité générale de sucre syntaxique dans le langage (par exemple une forme de surcharge des opérateurs), c'est tout de suite plus compliqué, il faut réfléchir, on risque de se planter et de faire des choix de conceptions qui plombent le langage pendant des années, etc.
Même topo pour les maps : c'est une structure de donnée indispensable dans un langage, car extrêmement utilisée, comme les listes et les tableaux; d'ailleurs une fois abstraites les considérations bas-niveau un tableau est essentiellement une map avec des clés entières au domaine restreint à être de la forme [0..N-1]. Pour l'ajouter sous forme de bibliothèque il faudrait ajouter une paramétrisation des types par les types, comme les types paramétriques des langages fonctionnels ou les "generics" des langages objet (essentiellement la même chose sous deux noms différents, si l'on exclu la template madness). Tu notes que ces types paramétrés sont les grands absents du langage de type de Go, puisqu'aujourd'hui tous les langages statiquement typés sont d'accord pour dire que c'est utile (on arrête avec les conneries Object ou void*). Pourquoi ? Parce que les concepteurs de Go n'ont pas d'expérience dans ce domaine, pensent que c'est délicat et ont préféré ne rien mettre que mettre un truc cassé qui les engage dans le futur. Donc on ajoute les map en dur dans le langage parce qu'il y a un fort besoin et ont dit que pour le reste, on verra plus tard.
C'est en cela que Go est un langage "minimaliste dans le style C" : pas de fonctionnalités compliquées qui pourraient poser des problèmes, on n'ajoute que des trucs utilisés depuis des années et bien maîtrisés, et si ça demande de faire des choix pragmatiques (inclusion des map en dur), on le fait.
[^] # Re: c'est moi ou bien...
Posté par gasche . En réponse à la dépêche Quelques nouvelles rapides du langage Go. Évalué à 5.
Dans la plupart des langages, les concepts "dans le langages" peuvent exploiter des informations et des outils auxquelles les bibliothèques externes n'ont pas accès. Les langages où ça ne se voit pas trop sont les langages dont le cœur est extrêmement minimaliste (je pense à Forth par exemple, où on a l'impression que rien n'est "dans le langage") et les langages qui insistent énormément sur l'extensibilité (comme Scheme; l'approche Racket est exemplaire dans le style "tout implémenter sous forme de bibliothèque", mais ça demande un travail considérable).
Concrètement, l'intérêt des slices "dans le langage" c'est d'avoir une syntaxe agréable pour gérer ça. Les opérations peuvent très bien être écrites de façon externe dans une bibliothèque, mais si on voulait une bibliothèque qui apporte ce sucre syntaxique il faudrait ajouter une facilité générale de sucre syntaxique dans le langage (par exemple une forme de surcharge des opérateurs), c'est tout de suite plus compliqué, il faut réfléchir, on risque de se planter et de faire des choix de conceptions qui plombent le langage pendant des années, etc.
Même topo pour les maps : c'est une structure de donnée indispensable dans un langage, car extrêmement utilisée, comme les listes et les tableaux; d'ailleurs une fois abstraites les considérations bas-niveau un tableau est essentiellement une map avec des clés entières au domaine restreint à être de la forme [0..N-1]. Pour l'ajouter sous forme de bibliothèque il faudrait ajouter une paramétrisation des types par les types, comme les types paramétriques des langages fonctionnels ou les "generics" des langages objet (essentiellement la même chose sous deux noms différents, si l'on exclu la template madness). Tu notes que ces types paramétrés sont les grands absents du langage de type de Go, puisqu'aujourd'hui tous les langages statiquement typés sont d'accord pour dire que c'est utile (on arrête avec les conneries
Objectouvoid*). Pourquoi ? Parce que les concepteurs de Go n'ont pas d'expérience dans ce domaine, pensent que c'est délicat et ont préféré ne rien mettre que mettre un truc cassé qui les engage dans le futur. Donc on ajoute les map en dur dans le langage parce qu'il y a un fort besoin et ont dit que pour le reste, on verra plus tard.C'est en cela que Go est un langage "minimaliste dans le style C" : pas de fonctionnalités compliquées qui pourraient poser des problèmes, on n'ajoute que des trucs utilisés depuis des années et bien maîtrisés, et si ça demande de faire des choix pragmatiques (inclusion des
mapen dur), on le fait.