Discussion :

[flotteman]

Bonjour,
J'aimerai savoir quels sont d'après vous les arguments qui seraient favorables à l'un ou l'autre des systèmes de typage.
J'ai lu beaucoup d'articles critiquant Java, et qui mettent en avant Ruby ou Python, pour leur puissance notamment dû au système de typage. Mais j'ai quelques doutes, peut être en partie dû que je viens du monde Java.

Par exemple j'ai l'impression qu'avec un typage dynamique, on peut tomber dans des travers comme nommer ces variables avec une information de typage en plus. Par exemple iNumber pour un entier, ou mapTruc pour une map, ce que je trouve assez crade. Du coups économiser le typage à la déclaration ne fait que déplacer le désagrément dans le nom de la variable. Ocaml est très clean à ce niveau vu qu'il laisse le choix de déclarer tout en gardant un contrôle à la compilation.

Y a t il une grosse perte au niveau sûreté avec un typage dynamique ou est ce une illusion? Le fait qu'un programme ne compile pas, pour moi c'est le minimum pour détecter une non régression.
De plus on pourrait n'utiliser que des Object en Java, si on en avait marre de se soucier du type. Mais c'est rarement le cas en réalité. On préfère typer avec des interfaces. D'ailleurs quand je manipule des Objects, çà me met mal à l'aise. Je sens qu'il faut contrôler s'il n'existe pas des cas où on se retrouve avec un type non voulu.

Quelle est votre sentiment à ce niveau?

[Garulfo]

Un typage dynamique offre une souplesse d'emploi. Certes cela ressemble à ce que tu obtiendrais pas l'utilisation abusive de Object en Java. Mais attention, en Java cela reviendrait à passer ton temps à faire des casts et cela surchargerait la mémoire. Cependant c'est techniquement faisable. La raison est que si le Java s'est inspiré du C/C++ pour sa syntaxe, il a cherché à s'orienter vers le smalltalk et à la philosophie du Lisp-objet: tout est un objet y compris les classes. On a donc un langage à typage statique, mais qui permet avec des tours de passe-passe de faire comme si tu avais du dynamique.

Ceci diffèrent d'un langage comme ocaml où le typage n'est pas un objet du langage. Le typage est donc réellement fort. Ainsi seul Ada et Ocaml, à ma connaissance — mais peut être pourrait-on en classer d'autres ici — sont réellement type safe: il est impossible d'avoir un problème de typage une fois que le compilateur a validé le typage. Ce n'est pas le cas du C++ par exemple ni du Java (d'où la raison de l'existence de l'exception idoine).

On passe donc à l'idée d'un typage statique qui effectivement améliore la fiabilité d'un programme. Mais attention, ce n'est pas pour rien que les programmes à fort risque sont en général fait en Ada ! C'est parce qu'il est un des rares langages à offrir un vrai typage sûr (avec ocaml donc si tu as suivi ) Ceci a par contre un coût pour Ada: c'est lourd en maudit à écrire. Pour ocaml, il y a une certaine souplesse dans son utilisation tout en conservant son typage sûr.

Donc typage dynamique ou statique, tout dépend du projet, de son utilisation et de tes besoins.

[Jedai]

Ainsi seul Ada et Ocaml, à ma connaissance — mais peut être pourrait-on en classer d'autres ici — sont réellement type safe: il est impossible d'avoir un problème de typage une fois que le compilateur a validé le typage.

Y a tout de même pas mal de langages maintenant à avoir un vrai système de type statique, tu peux rajouter Haskell, Clean, les autres ML... à ta liste par exemple.

--
Jedaï

[flotteman]

C'est d'ailleurs assez étonnant qu'en Haskell on demande de déclarer les types en soulignant que çà fait partie de la documentation utile pour le code. Est ce que certains d'entre vous trouve que çà alourdit?
Pour les petits scripts shell fait à la va vite, je trouve python et ruby bien pratique. Mais je me demande si les succès de Ror ou autres Django ne viennent pas en partie du fait que tout est packagé, ce qui amoindrit le risque, et que s'il fallait réellement coder une grosse application, çà serait bien plus compliqué. Y en a t il parmi vous qui utilisent Python et Ruby pour des applis d'entreprise. Est ce que vous êtes obligés de mettre des assert() partout pour se protéger des risques du typage dynamique? (Perso j'ai pas mal de assert en Java, je me demande s'il n'y en pas des tonnes en Ruby et en Python, ce qui amoindrit l'intérêt du typage dynamique)

[Jedai]

C'est d'ailleurs assez étonnant qu'en Haskell on demande de déclarer les types en soulignant que çà fait partie de la documentation utile pour le code. Est ce que certains d'entre vous trouve que çà alourdit?

On ne te demande pas de déclarer les types partout (seules les fonctions de top-level sont à typer explicitement par convention), par contre il est vrai que dans bien des cas, le type documente bien la fonction (surtout si tu as des types personnalisés, des synonymes de types, etc...). De plus parfois, écrire le type aide à écrire la fonction.
Note que tu peux demander à emacs par exemple d'inférer le type d'une fonction et de l'annoter automatiquement, tu n'es pas obligé de toujours le taper à la main.

Un autre point important à comprendre c'est que le système de type de Haskell est plus puissant que celui d'OCaml, mais en conséquence il n'est pas complètement inférable. En pratique, les cas où les annotations de type sont nécessaires sont extrêmement rares. Mais le système de type d'Haskell est tout de même tel qu'aucune erreur de type ne peut avoir lieu au runtime.

--
Jedaï

[flotteman]

Est ce que Python/Ruby est adapté aux pratiques agiles, prototypages, correction à chaud sans redémarrage?(plus à voir avec le fait que ce sont des langages de script que la question du typage) La flexibilité, et la relative simplicité du code compense-t-elle la sûreté à la compilation? Est ce que le typage statique tient plus de la flemme du développeur de cerner complètement ce qu'il écrit(çà compile, çà doit marcher...)?

Bon moi, faudrais peut être que je code plus pour éclaircir mes idées.
(pssst...c'est le mode Haskell pour emacs qui annote les fonctions?....ok bon je vais aller tester çà et jeter un coups d'oeil sur Ada )

[Jedai]

Est ce que le typage statique tient plus de la flemme du développeur de cerner complètement ce qu'il écrit(çà compile, çà doit marcher...)?

Mon opinion (et celle d'une majorité de programmeurs expérimentés) est que tout outil réduisant le nombre d'erreurs potentielles est bon à prendre. Là où la plupart des programmeurs de langage dynamique résiste à l'idée de typage statique c'est qu'ils ont l'impression que ça ne leur apporte pas tant de sécurité que ça et que ça encombre leur code et restreint leur pouvoir d'expression... Mais la plupart de ceux qui sont de cette opinion n'ont pratiquement aucune expérience des langages fonctionnels avec inférence de type (l'exception probable étant les Schemers et les Lispiens, mais il s'agit là d'une toute autre école que Python...).

(pssst...c'est le mode Haskell pour emacs qui annote les fonctions?....)

Ouaip, il faut lancer l'interpréteur avec C^c C^l puis lorsque le module compile, tu peux utiliser C^c C^t pour afficher le type de n'importe quelle expression (par défaut celui de l'identifiant sur lequel se trouve le curseur) et C^u C^c C^t pour automatiquement rajouter une ligne d'annotation.

--
Jedaï

[GnuVince]

À mon avis, ça revient à un débat entre fiabilité et flexibilité. J'ai écris là dessus sur mon blog il y a quelques temps: http://gnuvince.wordpress.com/2008/0...ynamic-typing/

Steve Yegge a aussi écrit sur ce sujet: http://steve.yegge.googlepages.com/i...-strong-enough

En gros, je trouve que ce qu'on gagne en fiabilité avec un système de typage comme celui d'Haskell, on le perd en flexibilité. Le défi est de trouver si l'application sur laquelle on travaille bénéficie plus de fiabilité ou de flexibilité, et des fois, c'est pas évident à décider.

C'est sans doute le sujet en informatique sur lequel je suis le plus partagé et déchiré.

[Garulfo]

Y a tout de même pas mal de langages maintenant à avoir un vrai système de type statique, tu peux rajouter Haskell, Clean, les autres ML... à ta liste par exemple.

--
Jedaï

Et bien a priori, c'est loin d'être aussi évident.
Disons que puisque je n'ai pas vérifier et que je n'ai rien sous la main qui permet de l'affirmer, je ne l'affirme pas. Il me semble qu'Haskell a cette propriété, mais je n'en suis pas certain, ni les autres ML d'ailleurs. As tu quelque chose qui atteste que ce soit type safe ?

[edit]D'ailleurs je crois me rappeler qu'un spécialiste du typage qui était venu donner une conférence à mon université a bien préciser qu'il est fort probable qu'Haskell soit type safe mais que ça n'avait pas été démontré. Quant à SML, je pense me rappeler qu'il y a justement quelques détails qui font qu'au final, ça ne l'est pas.[/edit]

[GnuVince]

Garulfo: tu veux dire quoi par type-safe? Qu'il ne peut pas y avoir d'erreurs de typage à l'exécution? Si c'est le cas, je pense qu'Haskell entre dans cette définition.

[Garulfo]

Garulfo: tu veux dire quoi par type-safe? Qu'il ne peut pas y avoir d'erreurs de typage à l'exécution? Si c'est le cas, je pense qu'Haskell entre dans cette définition.

Qu'aucune erreurs ne peut survenir à cause d'un problème lié aux types, ce qui est un peu plus général que « erreurs de typage » mais bon on s'est compris.

Je le pense aussi, mais je crois que ça n'est pas démontré. Alors qu'Ada (sous la condition d'utiliser du « pur » Ada) et ocaml ( sans l'utilisation de fonction externe en C ) ont déjà fait l'objet de telles preuves.

Toujours est-il que je n'ai rien sous la main pour invalider ou valider ce fait.

[Garulfo]

Ah il semblerait qu'il y ait qqchose là

Type safety of imperative programs is an area fraught with difficulty and requiring great care. The SML solution to the problem, originally involving imperative type variables, has been recently simplified to the syntactic-value restriction. In Haskell, the problem is addressed in a rather different way using explicit monadic state. We present an operational semantics for state in Haskell and the first full proof of type safety. We demonstrate that the semantic notion of value provided by the explicit monadic types is able to avoid any problems with generalization.

http://portal.acm.org/citation.cfm?id=258949.258970

Cet article date de 1997. En 1992, Hudak et Fasel disait que Haskell était type-safe. Donc c'est ce que je sous-entendais: beaucoup le pensait depuis longtemps, mais la preuve n'était pas là. Est-ce que maintenant on ne se pose plus la question ? c'est possible

[Jedai]

Voici un autre article sur les différences entre typage statique et dynamique ainsi que d'autre distinctions qu'il est possible de faire sur les systèmes de types. L'aspect intéressant est que l'article est pédagogique et ne plonge pas directement dans le débat (même si on sent que l'auteur a ses préférences).

--
Jedaï

[GnuVince]

Voici un autre article sur les différences entre typage statique et dynamique ainsi que d'autre distinctions qu'il est possible de faire sur les systèmes de types. L'aspect intéressant est que l'article est pédagogique et ne plonge pas directement dans le débat (même si on sent que l'auteur a ses préférences).

--
Jedaï

Voyons, c'est pas parce qu'un auteur a du code Haskell dans la bannière de son site qu'il est nécessairement biaisé en faveur du typage statique :-D

[Jedai]

Voyons, c'est pas parce qu'un auteur a du code Haskell dans la bannière de son site qu'il est nécessairement biaisé en faveur du typage statique :-D

Je trouve qu'il est relativement équilibré dans cet article, et il pose des questions intéressantes. Il ne faut pas penser non plus que je suis un fana du typage statique au sens classique... Je prendrais Perl ou Ruby plutôt que Java ou C++ 100 fois sur 100 (si j'avais le choix... ). Par contre en tant qu'utilisateur d'Haskell je suis exposé à un système de type vraiment intéressant à mes yeux et qui comme cet auteur le fait remarquer n'est pas simplement une limitation mais également un outil (cf. son exemple de la fonction lookup dans Data.Map).

--
Jedaï

[flotteman]

Merci pour ces articles. Ça aide à comprendre ce que peux impliquer le choix du typage dans un langage.

[flotteman]

Pour ceux que çà intéresse, je rajoute ce post paru dans un blog

http://kawagner.blogspot.com/2008/03...ng-part-2.html

Les réactions sont intéressantes notamment de la part de ceux qui préfèrent le typage dynamique. Le typage dynamique est notamment montré comme spécialement adapté au Test driven development (Si on se trompe dans les types on devrait rapidement le voir dans les tests unitaires. Il est plus simple d'écrire des mocks,...).

[GnuVince]

Pour ceux que çà intéresse, je rajoute ce post paru dans un blog

http://kawagner.blogspot.com/2008/03...ng-part-2.html

Les réactions sont intéressantes notamment de la part de ceux qui préfèrent le typage dynamique. Le typage dynamique est notamment montré comme spécialement adapté au Test driven development (Si on se trompe dans les types on devrait rapidement le voir dans les tests unitaires. Il est plus simple d'écrire des mocks,...).

Mon problème avec cet article, c'est qu'il assume que les langages au typage dynamique ne peuvent pas avoir le genre d'outils que les langages au typage statique peuvent avoir. Par exemple, un refactoring browser.

Pourtant, le premier refactoring browser a été créé en Smalltalk, l'un des langages les plus dynamiques qui soient. Toutes les actions de renommer, déplacer, extraire, etc. s'y trouvent. Donc cet argument est complètement vide.

Selon moi, le seul débat intéressant entre le typage dynamique et statique, est celui de la "correctness".

[Jedai]

Les réactions sont intéressantes notamment de la part de ceux qui préfèrent le typage dynamique. Le typage dynamique est notamment montré comme spécialement adapté au Test driven development (Si on se trompe dans les types on devrait rapidement le voir dans les tests unitaires. Il est plus simple d'écrire des mocks,...).

Je suis franchement sceptique, écrire des mocks en Java ou autre langage statique n'est pas plus complexe qu'avec un langage dynamique (surtout avec un IDE qui crée les méthodes d'une interface pour toi), les tests pour vérifier qu'il n'y a pas d'erreur de types ne sont tout simplement pas nécessaire dans le langage typé statiquement, je ne vois donc vraiment pas en quoi ils peuvent être considérés un avantage.

Pas mal d'adeptes du typage dynamique expliquent que le TDD évite toutes les erreurs qu'évite un système de type et plus, mais ce qu'ils perdent de vue, c'est que le TDD peut être utilisé avec un typage statique également (comme certains l'ont pointé dans cet article, c'est Java qui a popularisé les tests unitaires) et qu'on peut se contenter de moins de tests dans ce cas puisque toute une partie des tests n'est plus nécessaire grâce au système de type. (Il faut éviter de croire que le typage statique évite d'avoir à tester par contre, c'est une erreur classique)

Mon problème avec cet article, c'est qu'il assume que les langages au typage dynamique ne peuvent pas avoir le genre d'outils que les langages au typage statique peuvent avoir. Par exemple, un refactoring browser.

Pourtant, le premier refactoring browser a été créé en Smalltalk, l'un des langages les plus dynamiques qui soient. Toutes les actions de renommer, déplacer, extraire, etc. s'y trouvent. Donc cet argument est complètement vide.

C'est exact, néanmoins comme pointé par un certain nombre de participants, le refactoring dans les langages dynamiques est moins sûr que dans les langages statiques pour des raisons évidentes de manque de méta-information sur le code.
(La réflexion dans des langages comme Java peut également casser toute la belle mécanique des IDE, et même dans des langages statiques il reste parfois des ambiguités. Le refactoring n'est pas non plus un silver bullet)

--
Jedaï