Discussion :

[Garulfo]

Proposition pour la FAQ

--------------------

Quel langage choisir ?

Deux visions principales s'affrontent : le typage statique (OCaml, Haskell, F#) et le typage dynamique (Scheme, Lisp). Le choix est souvent difficile, mais nous allons tenter de vous donner quelques pistes qui devraient vous éclairer :

typage inféré statiquement

1. points forts:
   
   • permet de détecter de nombreuses incohérences dès la compilation et, donc, des erreurs potentielles du développeur;
   • ajoute une documentation implicite à l'aide des types de la fonction;
   • assure, dans le cas de nombreux langages aux typages inférés statiquement, qu'une erreur de typage est impossible à l'exécution.
2. points faibles:
   
   • peut être particulièrement contraignant et peut nécessiter de développer des mécanismes peu élégant ou lourd pour que le programme soit accepté par le système de typage;
   • certaines fonctions sont mathématiquement et sémantiquement correctes mais ne sont pas typables, bien qu'en général, elles ne soient pas vraiment utilisées en pratique et soient plutôt des cas d'école;
   • de manière plus terre à terre, limite la possibilité d'utiliser la surcharge de fonction ou d'opérateur (le polymorphisme pouvant cependant largement compenser ce problème).

typage dynamique

1. points forts :
   
   • assure une grande souplesse dans le développement des fonctions, le domaine et l'image de la fonction n'ayant pas de contraintes.
   • permet de développer et de tester des morceaux de code incomplets (très efficace pour le prototypage).
   • ces langages excellent souvent dans la réflexivité et l'introspection, c'est-à-dire la capacité de se regarder et de s'auto-modifier.
2. points faibles
   
   • impose une conception sans faille au risque de ne jamais retrouver une erreur faite durant le développement;
   • même si une erreur est détectée, le déverminage peut s'avérer très fastidieux.

En résumé, un système de typage inféré offre une fiabilité et une sécurité supplémentaire, en plus d'une documentation implicite. Cependant, ceci se fait au prix d'une certaine rigidité. Le jeu en vaut probablement la chandelle, surtout pour un débutant qui aura un guide pour développer. Un développeur expérimenté peut cependant trouver des avantages dans un système de type plus souple qui lui impose moins de contraintes et moins de pirouettes pour obtenir le résultat. C'est particulièrement vrai lors d'une approche basée sur des prototypes où on ne sait pas encore tous les éléments constituants d'une fonction.

--------------------

Pour information
Je n'ai pas gardé « plus proches de nombreux langages classiques par leur portée lexicale » en point fort des typages statiques ni « la portée dynamique peut en surprendre plus d'un » car ce sont des concepts distincts du typage. En Scheme, par exemple, la portée est lexicale. Elle est dynamique au top-level mais statique autrement — ce qui est dû uniquement au comportement de define qui est différent. L'utilisation de let la rend uniquement statique.

Mon dernier paragraphe s'applique aussi aux langages qui ne sont pas fonctionnels. Python est un must pour les prototypes et je ne le conseille pas à des débutants pour ce qui fait sa force dans ce premier cas justement.

Qu'en pensez-vous ?

[SpiceGuid]

La question est incontournable pour une FAQ.
La réponse me convient, ce qui fait la richesse du paradigme fonctionnel ce sont les différents systèmes de types.
Après, dans le détail, restons diplomates car c'est avant tout une réponse collective

[gorgonite]

La question est incontournable pour une FAQ.
La réponse me convient, ce qui fait la richesse du paradigme fonctionnel ce sont les différents systèmes de types.
Après, dans le détail, restons diplomates car c'est avant tout une réponse collective

+1, on voit l'expérience de Garulfo en terme de pédagogie... tout y est, et pourtant ça passe tout seul

[Sygénème]

Personnellement, je suis en train d'étudier toutes ces différences afin de me choisir un langage de prédilection... Ce texte relativise le typage fort qui à souvent été mis en valeur dans les textes pour mettre en valeur Caml, Haskell ou Anubis par exemple par rapport aux plus anciens Lisp, Common Lisp et Scheme...

Je rajouterais qu'on reproche au typage dynamique de grever les performances, la gestion des types étant effectuer pendant l'exécution du programme...

[gasche]

permet de développer et de tester des morceaux de code incomplets (très efficace pour le prototypage).

Certes, mais ce n'est pas lié au système de typage. La plupart des langages typés permettent ce genre de choses en plaçant dans les parties à compléter des valeurs divergentes.

Exemple en OCaml :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
let ma_fonction truc =
  if condition truc then
     partie_deja_codee
  else
     assert false

ces langages excellent souvent dans la réflexivité et l'introspection, c'est-à-dire la capacité de se regarder et de s'auto-modifier.

Il faut faire attention à ne pas mélanger les facilités de macro, qui ne sont pas liées au typage mais à la pauvreté syntaxique de ces langages, et les méthodes utilisant la fonction "eval" qui sont effectivement relativement spécifiques aux langages dynamiques (même si la limite tend à se brouiller à ce niveau).

[Garulfo]

Je rajouterais qu'on reproche au typage dynamique de grever les performances, la gestion des types étant effectuer pendant l'exécution du programme...

On reproche... mais ce n'est pas vrai.
Donc mieux vaut éviter les erreurs
Des compilateurs de Scheme ou Common Lisp sont très efficaces et n'ont rien à envier à Ocamlopt ou GHC (globalement).

[Garulfo]

Certes, mais ce n'est pas lié au système de typage. La plupart des langages typés permettent ce genre de choses en plaçant dans les parties à compléter des valeurs divergentes.

Exemple en OCaml :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
let ma_fonction truc =
  if condition truc then
     partie_deja_codee
  else
     assert false

Tu ne parles pas de la même chose exactement de la même chose. Car on aurait pû aussi lancer une exception.
Sur des gros morceaux, la possibilité de ne même pas savoir exactement ce que tu vas renvoyer (et donc renvoyer des résultats très différents ou en morceaux) sont simplifiés par le typage dynamique. On peut donc continuer le programme (qui marchera mal sur certains morceaux) sans même se préoccuper d'une manière de le bloquer par un assert ou une exception. C'est plus ça le sens du prototypage: pas l'envoie d'une erreur.

J'aurais dû dire « simplifie » plutôt cependant. Car là ça paraît un peu absolu. C'est à changer.

Il faut faire attention à ne pas mélanger les facilités de macro, qui ne sont pas liées au typage mais à la pauvreté syntaxique de ces langages, et les méthodes utilisant la fonction "eval" qui sont effectivement relativement spécifiques aux langages dynamiques (même si la limite tend à se brouiller à ce niveau).

Je ne mélange pas. Les facilités de macro viennent du typage dynamique. Et ce que tu appelles la pauvreté syntaxique aussi : s'il y a peu d'opérateur c'est parce que tout se fait avec cons car cdr et lambda (théoriquement). Il ne reste qu'à avoir de quoi contrôler l'évaluation (puisqu'il n'y a que très peu de langage à évaluation en ordre normal).

Cette fois-ci je n'ai pas fait d'absolu en sous-entendant que les autres ne pouvait pas. C'est vrai que tous les langages fonctionnels à typage dynamique excelle dans les méta-fonctionnalités. C'est qu'il y a un lien ne penses-tu pas

[gasche]

Cette fois-ci je n'ai pas fait d'absolu en sous-entendant que les autres ne pouvait pas. C'est vrai que tous les langages fonctionnels à typage dynamique excelle dans les méta-fonctionnalités. C'est qu'il y a un lien ne penses-tu pas.

Tu opposes Scheme/Lisp et OCaml/Haskell au niveau des capacités d'auto-transformation syntaxique, et tu dis "il y a un lien avec le typage". Je prétends que le lien est en fait syntaxique : la syntaxe des Scheme/Lisp est complètement homogène, les Abstract Syntax Tree sont tout simplement des arbres n-aires donc chaque noeud a la même tête (c'est une liste). C'est ce que j'appelle "pauvreté syntaxique".
À l'inverse, OCaml/Haskell et en général la plupart des langages ont un AST très hétérogène, avec de nombreuses constructions différentes, et donc plus rigide. Cette deuxième approche a ses avantages (on peut choisir une structure syntaxique visuellement plus adaptée à certaines situations, comme le | -> ... pour le pattern matching) mais apporte un fort coût d'entrée aux manipulations syntaxiques : il faut avoir les moyens de manipuler un AST plutôt complexe.

Les facilités de sous-évaluation à l'intérieur d'un programme sont une autre force de Scheme/Lisp (et dans l'ensemble c'est plutôt caractéristique des langages à typage simple), mais je ne pense pas qu'elles jouent beaucoup dans la création des macros. Par ailleurs il paraît (j'ai demandé à un lispeux qui passait) que les recommandations en la matière sont "pas d'eval inutile dans les macros" (ou plutôt "si tu veux eval, fait une fonction, on n'est pas des porcinets ici").

Enfin, l'argument que je pense déterminant est l'existence de versions syntaxiquement appauvries de langage statiquement typées, et qu'elles se retrouvent naturellement à permettre des macros à la lisp.
Par exemple Liskell, un frontend Haskell avec une syntaxe Lisp (bon, c'est plutôt expérimental et personne ne l'utilise je crois) : après avoir créé une syntaxe homogène, il s'est retrouvé tout naturellement à implémenter des facilités de macrottage, parce que c'était devenu facile. Il existe aussi des syntaxes lispeuses pour OCaml, grâce à camlp4 (un projet qui s'attaque frontalement à la difficulté, en essayant de faciliter les transformations sur un AST fortement structuré tel que celui de OCaml), mais je n'ai pas entendu parler de projets de ce genre (visiblement ça n'intéresse pas tant de gens que ça).


Pour résumer, je pense que les facilités de macrotage syntaxique sont lié quasi-uniquement à la syntaxe, et pas au typage.

[Garulfo]

Tu opposes Scheme/Lisp et OCaml/Haskell au niveau des capacités d'auto-transformation syntaxique, et tu dis "il y a un lien avec le typage". Je prétends que le lien est en fait syntaxique : la syntaxe des Scheme/Lisp est complètement homogène, les Abstract Syntax Tree sont tout simplement des arbres n-aires donc chaque noeud a la même tête (c'est une liste). C'est ce que j'appelle "pauvreté syntaxique".
À l'inverse, OCaml/Haskell et en général la plupart des langages ont un AST très hétérogène, avec de nombreuses constructions différentes, et donc plus rigide. Cette deuxième approche a ses avantages (on peut choisir une structure syntaxique visuellement plus adaptée à certaines situations, comme le | -> ... pour le pattern matching) mais apporte un fort coût d'entrée aux manipulations syntaxiques : il faut avoir les moyens de manipuler un AST plutôt complexe.

Les facilités de sous-évaluation à l'intérieur d'un programme sont une autre force de Scheme/Lisp (et dans l'ensemble c'est plutôt caractéristique des langages à typage simple), mais je ne pense pas qu'elles jouent beaucoup dans la création des macros. Par ailleurs il paraît (j'ai demandé à un lispeux qui passait) que les recommandations en la matière sont "pas d'eval inutile dans les macros" (ou plutôt "si tu veux eval, fait une fonction, on n'est pas des porcinets ici").

Enfin, l'argument que je pense déterminant est l'existence de versions syntaxiquement appauvries de langage statiquement typées, et qu'elles se retrouvent naturellement à permettre des macros à la lisp.
Par exemple Liskell, un frontend Haskell avec une syntaxe Lisp (bon, c'est plutôt expérimental et personne ne l'utilise je crois) : après avoir créé une syntaxe homogène, il s'est retrouvé tout naturellement à implémenter des facilités de macrottage, parce que c'était devenu facile. Il existe aussi des syntaxes lispeuses pour OCaml, grâce à camlp4 (un projet qui s'attaque frontalement à la difficulté, en essayant de faciliter les transformations sur un AST fortement structuré tel que celui de OCaml), mais je n'ai pas entendu parler de projets de ce genre (visiblement ça n'intéresse pas tant de gens que ça).


Pour résumer, je pense que les facilités de macrotage syntaxique sont lié quasi-uniquement à la syntaxe, et pas au typage.

J'ai bien compris tout ça. Mais tout oublie aussi que la syntaxe de Lisp/Scheme est suite au typage dynamique: elle impose le préfixage et autorise une grand simplicité (ou pauvreté si tu veux) syntaxique.
C'est pourquoi le typage dynamique jouant sur la syntaxe et la syntaxe jouant sur la facilité d'introspection, on peut dire que le typage dynamique facile l'introspection. A => B et B => C ne font-ils pas que A => C ?

Pour le eval il a pas tort ton lispeux... Il faut faire attention. Comme pour les macros d'ailleurs. Mais tu remarqueras que je n'ai pas parlé d'eval. J'ai parlé de « contrôler l'évaluation » dans mon dernier message.

Si ce lien n'existait pas (entre typage dynamique et typage statique), comment expliquer que quasiment tous les langages à TD ont des capacités importante de réflexivité alors que les quasiments tous les langages à TS ne l'ont pas ? Les langages objets l'ont aussi souvent lorsqu'ils considèrent que tout est un objet et autorisent les cast à tout va (ce qui est une forme de TD). Les langages qui imposent de forte contrainte sur le typage ont des problèmes avec les macros puisque tu rentres dans un méta-langage, donc dans un méta-typage, ce qui te complique la donne.

En tout cas... cette fois, je suis sûr de moi. Le typage dynamique a un rapport avec la facilité d'introspection (car un rapport avec la syntaxe). Et ma phrase est bien formée : « ces langages excellent souvent dans la réflexivité et l'introspection, c'est-à-dire la capacité de se regarder et de s'auto-modifier. » Ce qui ne veut pas dire que d'autres n'ont pas ces capacités mais souvent avec plus de difficultés ^_^

[1337cclean]

Pendant longtemps je n'hésitais pas un instant entre Miranda (ou Haskell, ultra similaires), pour choisir Concurrent-CLEAN; Mais aujourd'hui faut dire ce qui est, Haskell ghci (glasgow Haskell) à pris une "certaine" avance.

Donc je serait un peu plus hésitant.

http://wiki.clean.cs.ru.nl/Clean

Mais je conserve les pionniers de l'UNIQUENESS-OF-TYPING, dans l'histoires des langages fonctionnels modernes

<--- Zut quelqu'un viens de PENSER à "développer" l'idée... [non]

http://en.wikipedia.org/wiki/Uniqueness_type

Disont que le "coup" de reformuler un layout linguistique qui permet de revenir à des conceptions impératives, me déplaisent un peu. (Monades à la sauce G-Haskell...).

Par contre la notion de ARROWS (flêches), se réapproprient des notions issues (semble-t'il pas?) directement de l'études des Topos et Catégories. Ce qui s'adapte à des fondemments modernes des mathématiques logiciennes.

Un excellent professeur en la matière: Alain Prouté qui enseigne ces concepts niveaux M2...

http://www.math.jussieu.fr/~alp/

Merci pour lui