Je ne suis pas convaincu par ton argumentation, dans les sens où tes trois points me semblent faux.
La facilité de la sérialisation dépend avant tout d'un choix d'implémentation du langage, celui de trimballer ou pas de l'information de typage au runtime. Les langages objets ont tendance à le faire (entre autres parce parce que leurs systèmes de typage souvent incorrects ne suffisent pas et il faut parfois un garde-fou dynamique), les langages fonctionnels ne le font souvent pas par défaut (on peut l'encoder par dessus, cf. Data.Typeable en Haskell). Les langages qui ont cette information sont favorisés, qu'ils soient statiquement typés ou non.
Un type algébrique à la ML (ou une hiérarchie de classe si tu veux du lourd) permet(tent) de représenter un valeur qui peut avoir plusieurs formes différentes. Si tu veux cacher cette conversion (mot-clé -> truc-paramètre-de-filtrage), tu peux utiliser des conversions implicites; ce n'est en rien incompatible avec le typage statique (cf. les implicites de Scala).
Je ne vois pas en quoi la présence ou non de typage statique change le statut des arguments optionnels. Une fonction précise combien d'arguments elle attend, éventuellement des valeurs par défaut pour ses arguments, et c'est la sémantique opérationnelle (à l'exécution) qui précise ce qui se passe si un argument n'est pas fourni. Le typage statique ne pose aucun problème. Il peut par contre parfois être un peu utile, quand on utilise des formes de surcharge basées sur le typage : par exemple si la fonction attend un entier, une chaîne de caractères et un objet, on peut l'appeler en passant seulement l'entier et l'objet, et le typeur comprend que c'est la chaîne de caractères qui n'a pas été renseignée. Je ne dis pas que c'est une bonne idée, mais qu'à priori le typage "aide" les arguments optionnels plus qu'il ne les gêne.
Pour les fonctions à nombre d'argument multiple, on peut en fait typer ça correctement (après la façon de typer dépend de la façon dont la fonction utilise ses arguments), mais le fait est que ça ne fait pas partie de la plupart des langages de programmation typé. C'est bien le seul point de ton argumentaire qui me semble recevable, sachant que par ailleurs je n'aime pas trop les fonctions à nombre d'argument multiple et je pense qu'il y a souvent moyen de faire mieux et plus propre en s'en passant (si le langage est suffisamment expressif).
Ceci dit je ne suis pas fondamentalement contre l'utilisation de Scheme/Racket/Guile comme langage de configuration (si on pouvait éviter Elisp par contre, qui n'est de loin pas le Lisp le plus réussi). C'est juste que je ne vois pas d'argument conseillant, dans l'absolu, d'éviter les langages ayant du typage statique.
[^] # Re: déçu aussi, mais confiant
Posté par gasche . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 3.
Je ne suis pas convaincu par ton argumentation, dans les sens où tes trois points me semblent faux.
La facilité de la sérialisation dépend avant tout d'un choix d'implémentation du langage, celui de trimballer ou pas de l'information de typage au runtime. Les langages objets ont tendance à le faire (entre autres parce parce que leurs systèmes de typage souvent incorrects ne suffisent pas et il faut parfois un garde-fou dynamique), les langages fonctionnels ne le font souvent pas par défaut (on peut l'encoder par dessus, cf. Data.Typeable en Haskell). Les langages qui ont cette information sont favorisés, qu'ils soient statiquement typés ou non.
Un type algébrique à la ML (ou une hiérarchie de classe si tu veux du lourd) permet(tent) de représenter un valeur qui peut avoir plusieurs formes différentes. Si tu veux cacher cette conversion (mot-clé -> truc-paramètre-de-filtrage), tu peux utiliser des conversions implicites; ce n'est en rien incompatible avec le typage statique (cf. les implicites de Scala).
Je ne vois pas en quoi la présence ou non de typage statique change le statut des arguments optionnels. Une fonction précise combien d'arguments elle attend, éventuellement des valeurs par défaut pour ses arguments, et c'est la sémantique opérationnelle (à l'exécution) qui précise ce qui se passe si un argument n'est pas fourni. Le typage statique ne pose aucun problème. Il peut par contre parfois être un peu utile, quand on utilise des formes de surcharge basées sur le typage : par exemple si la fonction attend un entier, une chaîne de caractères et un objet, on peut l'appeler en passant seulement l'entier et l'objet, et le typeur comprend que c'est la chaîne de caractères qui n'a pas été renseignée. Je ne dis pas que c'est une bonne idée, mais qu'à priori le typage "aide" les arguments optionnels plus qu'il ne les gêne.
Pour les fonctions à nombre d'argument multiple, on peut en fait typer ça correctement (après la façon de typer dépend de la façon dont la fonction utilise ses arguments), mais le fait est que ça ne fait pas partie de la plupart des langages de programmation typé. C'est bien le seul point de ton argumentaire qui me semble recevable, sachant que par ailleurs je n'aime pas trop les fonctions à nombre d'argument multiple et je pense qu'il y a souvent moyen de faire mieux et plus propre en s'en passant (si le langage est suffisamment expressif).
Ceci dit je ne suis pas fondamentalement contre l'utilisation de Scheme/Racket/Guile comme langage de configuration (si on pouvait éviter Elisp par contre, qui n'est de loin pas le Lisp le plus réussi). C'est juste que je ne vois pas d'argument conseillant, dans l'absolu, d'éviter les langages ayant du typage statique.