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]

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

[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).