Discussion :

[gorgonite]

Le fait que l'on ne puisse pas écrire par exemple une fonction qui prenne un nombre en argument (soit entier, soit flottant...) me semble être une limitation du système de typage.

ben non, c'est du typage fort... on n'a qu'à définir un type pour "fusionner" ses deux types, et le tour est joué
c'est donc faisable, mais plus long

Le fait que chaque structure doive avoir des noms de champs différents (et quand on en a beaucoup, c'est pénible), me semble en être une autre.

c'est une conséquence de leur inférence de type... si l'on typait à la main, on pourrait le faire

Il y a aussi le fait que l'on ne puisse pas écrire une liste de fonctions.

si toutes les fonctions ont la meme signature, je ne vois pas pourquoi ça ne marcherait pas...

Le fait que l'on ne puisse pas écrire de fonction avec un nombre variable d'arguments est aussi une limitation.

ça sert à éviter l'indétermination... si tu veux un nombre variable de paramètres, tu passes un vecteur en argument
encore une fois, c'est possible... fait juste le prendre en compte à la conception

Comment écrire aussi une fonction qui renvoie le complément d'une autre fonction ?

pas clair...

Comment écrire une fonction prenant un tuple en argument et renvoyant son premier élément ?

ben tu passes le tuple sous forme de vecteur... et ça marche, juste un détail à la conception

Comment écrire une fonction prenant en argument un entier positif ? Ou un entier compris entre 10 et 20 ? Même Pascal permet de faire ça !

définir un type adéquate et le spécifier... sinon il généralisera à int

Le fait que le système de typage interdise la surcharge est aussi une limitation : OCaml doit être l'un des rares langages qui "oblige" à mettre l'information de type dans le nom même de la fonction : print_int, print_float, print_string... abs, abs_float...

point déjà traité...

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

Bon je pense qu'on a fait le tour de la question OCaml vs F#, qui ne sont pas très éloignés...


Il serait peut-etre temps de changer de sujet... ou de faire le meme genre de comparatif avec d'autres langages

[InOCamlWeTrust]

Je crois sincèrement que tu n'as rien compris au langage : on peut bien-sûr écrire des listes de fonctions, du moment qu'elles ont le même type... car tout est valeur, y compris les fonctions, et les listes prennent en charge des éléments de même type, donc des fonctions de même type. Même en C-ANSI tu ne peux pas faire ce que tu veux : tu ne peux pas mettre dans un même vecteur de fonctions des fonctions de type différent... à moins de faire des choses non standard !

Ensuite, le fait de ne pas avoir de fonction prenant en argument un nombre quelconque n'est pas une limitation en soi : tu ne peux pas non plus faire ça en C ! Imagine que ta fonction d'exponentiation puisse prendre en paramètre un entier ou un flottant : quel sera le type de retour ? un entier ? un flottant ? Ta fonction ne serait plus utilisable ! Ou encore du genre : "si j'ai un entier, alors je retourne un entier, et sinon un flottant"... tu trouves ça propre ? Moi je trouve ça archi-dégueulasse. De plus, ce genre de construction empêcherait très clairement de faire des optimisations de code pour le compilateur, comme le manuel de GHC, qui autorise la surcharge, le fait comprendre très clairement.

Pour ce qui est des fonctions à plusieurs arguments, là encore, tu veux utiliser quelque chose qui n'a pas de sens dans le système de typage de Objective Caml. Quel serait le type d'une fonction prenant un nombre quelconque d'arguments en paramètre ? Idem pour les n-uplets quelconques : quel est leur type ? Là réponse est toute simple : il n'y en a pas. Objective Caml reste cohérent de bout en bout avec lui-même.

Si tu veux contourner tout celà, tu peux toujours utiliser des fonctions avec labels et arguments optionnels, qui permettent en plus de faire commuter les arguments, voire d'en omettre.

Pour ce qui est de ça :

cette analyse statique pose aussi de sérieuses limitations au modèle objet de Caml... normalement, l'héritage assure d'une certaine "force" du type, alors qu'en OCaml une classe n'est définie "que par ses méthodes"

Ce n'est pas tout à fait vrai : le type d'un objet est le type de ses méthodes, mais une classe définit également un synonyme pour le type des méthodes déclarées... donc déclarer une classe, c'est aussi déclarer un type. Celà autorise du sous-typage sans héritage, chose qui peut être appréciable.

Depuis peu, on peut également faire d'une classe un type unique incompatible avec toute autre classe, même si définissant les mêmes méthodes avec les mêmes types. L'explication se trouve ici...

http://caml.inria.fr/pub/docs/manual...manual021.html

... section 7.10 "Private row types". La classe définie est tout bonnement incompatible avec toute autre classe de même type.

Franchement je trouve que les soi-disant "limitations" évoquées n'en sont pas parce qu'elles n'ont pas de sens.

Pour ce qui est des classes en Objective Caml, je suis désolé, mais on ne peut pas dire qu'elles n'apportent rien de plus au langage. Le système fournit énormément de possibilités que ne fournit aucun autre langage (objet fonctionnels, sous-typage sans héritage et constructeurs fonctionnels dont on peut en faire des applications partielles) et accorde une souplesse extrême.

Le grand problème, c'est que le système de classe est très mal documenté et que les gens ne sont tout simplement pas au courant des possibilités qu'offre cette extension. De plus, la majorité des programmeurs Objective Caml sont des personnes voulant monter aux arbres en faisant du tout récursif-fonctionnel "parce que c'est très beau" (comme des professeurs que j'ai eus) et ne veulent entendre rien d'autre.

Si j'avais un peu plus de temps, j'aimerais bien fournir de la documentation lisible et accessible sur ces sujets et points très subtils du langage, car il y en a un certain nombre.

Comme je le dis : si tu veux de la surcharge à gogo, regarde su côté de Haskell, mais là, tu t'en mordras les doigts si tu penses que Objective Caml est trop rigide (ce n'est pas une critique envers Haskell, langage que j'aime beaucoup) !

[LLB]

c'est une conséquence de leur inférence de type... si l'on typait à la main, on pourrait le faire

Il y a de nombreux cas où ça pourrait être inféré. Les très rares cas ambigus pourraient être gérés à la main (et ceux qui n'aiment pas pourraient toujours utiliser des noms différents).

pas clair...

Code :

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

1
2
3
let comp f arg = not (f arg);;
let comp2 f arg arg2 = not (f arg arg2);;
let comp3 f arg arg2 arg3 = not (f arg arg2 arg3);;

Dans le cas général... ?
Parfois, on peut s'en sortir en jouant avec l'évaluation partielle et en renvoyant une fonction. Mais pas dans cet exemple.
Et pour le typage : ('a -> bool) -> ('a -> bool).
('a pouvant être une fonction)

car tout est valeur, y compris les fonctions, et les listes prennent en charge des éléments de même type, donc des fonctions de même type.

Cf l'exemple donné. Ca ne marche pas puisque les fonctions n'ont pas exactement le même type. Pourtant, ça ne gène en rien par la suite. Mais bon, je comprends que ce cas soit trop compliqué à gérer dans le compilateur.

tu ne peux pas non plus faire ça en C !

Les comparaisons avec le C, c'est un peu facile et ça ne montre rien (on va pas commencer à liste les défauts de ce langage...).

Imagine que ta fonction d'exponentiation puisse prendre en paramètre un entier ou un flottant : quel sera le type de retour ? un entier ? un flottant ? Ta fonction ne serait plus utilisable ! Ou encore du genre : "si j'ai un entier, alors je retourne un entier, et sinon un flottant"... tu trouves ça propre ? Moi je trouve ça archi-dégueulasse.

De la même façon qu'il existe des fonctions de type 'a -> 'a -> 'a (par exemple "min"). Par exemple, il serait agréable d'avoir la même chose, en fixant des contraintes sur le type : "'a -> 'a -> 'a when 'a is a number". Ce n'est pas sale : tout est défini, comme dans tes fonctions polymorphiques. C'est juste à mi-chemin entre un type exact (int) et un type complètement générique ('a).

Pour ce qui est des fonctions à plusieurs arguments, là encore, tu veux utiliser quelque chose qui n'a pas de sens dans le système de typage de Objective Caml. Quel serait le type d'une fonction prenant un nombre quelconque d'arguments en paramètre ? Idem pour les n-uplets quelconques : quel est leur type ?

Je sais très bien. Je faisais justement remarquer que le système de typage empêche d'écrire un certain nombre de choses qui pourraient être valides dans un autre système.

Le système fournit énormément de possibilités que ne fournit aucun autre langage (objet fonctionnels, sous-typage sans héritage et constructeurs fonctionnels dont on peut en faire des applications partielles) et accorde une souplesse extrême.

Oui oui, j'en connais les possibilités.
Je disais juste que j'en ai jamais ressenti le besoin de les utiliser (et que j'en ai rarement rencontrés), mais ça dépend peut-être du type de programme que l'on écrit.
J'apprécie beaucoup le typage structurel, c'est aussi agréable que le duck typing, mais c'est entièrement statique et sûr. J'aimerais bien avoir cette même souplesse dans le reste du système.

Il y a un certain nombre de cas où l'on doit réécrire plusieurs fois la même fonction en changeant juste le type, et je trouve ça dommage.

Il y a énormément de choses que j'apprécie dans Caml, mais parfois je souhaiterais plus de souplesse et de généricité.

[gorgonite]

Ce n'est pas tout à fait vrai : le type d'un objet est le type de ses méthodes, mais une classe définit également un synonyme pour le type des méthodes déclarées... donc déclarer une classe, c'est aussi déclarer un type. Celà autorise du sous-typage sans héritage, chose qui peut être appréciable.

Depuis peu, on peut également faire d'une classe un type unique incompatible avec toute autre classe, même si définissant les mêmes méthodes avec les mêmes types. L'explication se trouve ici...

http://caml.inria.fr/pub/docs/manual...manual021.html

... section 7.10 "Private row types". La classe définie est tout bonnement incompatible avec toute autre classe de même type.

pas le temps de tout lire en détails... mais en gros, si l'on utilise cela, peut-on encore prendre une instance d'une classe dérivée et la considérer comme étant de cette classe ?

Franchement je trouve que les soi-disant "limitations" évoquées n'en sont pas parce qu'elles n'ont pas de sens.

comme toujours avec toi... mais cela peut avoir un sens pour d'autres

[gorgonite]

Les comparaisons avec le C, c'est un peu facile et ça ne montre rien (on va pas commencer à liste les défauts de ce langage...).

et pourquoi ?
C est un langage qui demande juste de faire attention à ce qu'on écrit car on doit presque tout gérer à la main... chose parfaitement inconcevable pour nombre de "purs programmeurs fonctionnels"

[InOCamlWeTrust]

Si on s'en tient à la norme C-ANSI, le C est très rigide et peu permissif. Le problème, c'est que les compilateurs sont eux très laxistes.

[Garulfo]

et pourquoi ?
C est un langage qui demande juste de faire attention à ce qu'on écrit car on doit presque tout gérer à la main... chose parfaitement inconcevable pour nombre de "purs programmeurs fonctionnels"

C est un langage qui a été créé pour remplacer un assembleur complètement inhumain. Il garde cependant les mêmes réflexes.

C'est incomparable avec des langages qui ne visent pas à rester proche de la machine mais au contraire à s'en séparer. C'est comme dire: je peux comparer ma ferrari F350 et mon tracteur parce que toutes les deux roulent sur des routes: on ne s'adresse pas du tout au même personne. Le paysan sur sa ferrari aura l'air richemment idiot. Et le playboy sur un tracteur aura juste l'air idiot ^_^

C'est pareil pour le C et les langages fonctionnels en général et ocaml en particulier. Le C ne devrait pas être vu comme un langage de haut niveau de nos jours et devraient être utilisé pour ce qu'il fait de mieux : construire d'autres langages.

Malheureusement inertie de l'industrie l'obligeant, on continue à faire apprendre du C en math parfois -_-

[Garulfo]

[...]
Le TOUT objet, ce n'est pas dans la mentalité Objective Caml, étant donné que celà se révèle lourd dès que lon veut parcourir les structures... tout comme la surcharge.[...]

Ça va plus loin qu'un problème de surcharge.
C'est effectivement un problème de mentalité et de philosophie.
En fait c'est le débat entre les aristotéliciens et les platoniciens du moyen-âge (ce n'est pas de moi cette réflexion).

Un tout objet c'est une vision qui dit qu'un type est un élément constitutif du monde et peut se manipuler. C'est la vision d'Aristote sur les idées.
Un typage fort à-la caml c'est une vision disant que le type est au-dessus et ne peut se manipuler. C'est la vision de Platon sur les idées.

[InOCamlWeTrust]

C est un langage qui a été créé pour remplacer un assembleur complètement inhumain. Il garde cependant les mêmes réflexes.

C'est incomparable avec des langages qui ne visent pas à rester proche de la machine mais au contraire à s'en séparer. C'est comme dire: je peux comparer ma ferrari F350 et mon tracteur parce que toutes les deux roulent sur des routes: on ne s'adresse pas du tout au même personne. Le paysan sur sa ferrari aura l'air richemment idiot. Et le playboy sur un tracteur aura juste l'air idiot ^_^

C'est pareil pour le C et les langages fonctionnels en général et ocaml en particulier. Le C ne devrait pas être vu comme un langage de haut niveau de nos jours et devraient être utilisé pour ce qu'il fait de mieux : construire d'autres langages.

Malheureusement inertie de l'industrie l'obligeant, on continue à faire apprendre du C en math parfois -_-

Non : le C est un meveilleux langage. Cependant, c'est une arme qui, si on ne la maîtrise pas entièrement, peut être dangereuse et peu agréable.

[Garulfo]

Non : le C est un meveilleux langage. Cependant, c'est une arme qui, si on ne la maîtrise pas entièrement, peut être dangereuse et peu agréable.

Tu n'as pas bien lu ce que j'ai dit, ou je me suis mal exprimé:
le C en tant que langage de haut niveau est particulièrement merdique;
le C en tant que langage de bas niveau est merveilleux.

De plus en plus de non-informaticiens sont amenés à programmer. « Non-informaticien » signifiant que ce n'est pas leur métier. Et dans ce cadre, le C est une plaie et non une aide. Ce qu'ils veulent c'est des langages exprimant les concepts aisément et non des langages s'embourbant dans des subtilités syntaxiques inadéquates et proche de l'assembleur. Ainsi, physiciens, mathématiciens et autres géomaticiens, pour ne citer que les plus nombreux ici, n'ont aucun intérêt dans un langage comme le C.
Un informaticien y trouvera sa part par contre.

D'où mon analogie avec le playboy et le fermier... chacun doit avoir un outil adapté à ses besoins. Comme le soulignait Alan Kay il y a quelques années, l'informatique est actuellement un échec: elle voulait donner les moyens à des corps de métier non spécialisé d'automatiser des tâches. Des langages comme le C sont à contre-pied de ceci. Mais reste nécessaire pour ceux qui ont les mains dans le cambouis.

---

Pour revenir au sujet, donc, tous les langages fonctionnels ont cette idée qu'il faut voir abstrait et de haut niveau. Ça a toujours été le cas. Après on rentre dans des saveurs personnelles. J'adore le scheme, car j'aime le typage faible. Mais je comprends les remarques de LLB (si je ne me trompe pas) sur la syntaxe. Personnellement, je n'y ai jamais vu aucun problème (très faible temps d'adaptation), mais il est clair que si la syntaxe est ainsi très claire et simple, la notation préfixée fait une marche supplémentaire que caml aide à traverser.

À l'enseignement, je vois chaque année combien des personnes n'ayant jamais programmé sont bien plus à l'aise avec un langage fonctionnel qu'un langage à-la C. Et il faut exactement 6 heures de cours pratique pour que la notation ne soit plus un obstacle. Le système de typage d'ocaml par contre, s'il est appréciable pour qqun connaissant le principe, n'aide pas à l'apprentissage et oblige une certaine rigidité mal venu. Mais cependant, elle est elle aussi plutôt vite absorbé, surtout quand l'auditoire est scientifique. Il suffit de mettre le parallèle sur les ensembles mathématiques et cela passe beaucoup mieux qu'avec la même matière (les types) en C par exemple.

Je ne connais pas assez bien Miranda ou Haskell pour me prononcer de la même manière. Et sinon Common Lisp ou Scheme, ça ne change pas grand chose.

Je n'ai jamais utilisé les autres langages mentionnés.

[InOCamlWeTrust]

Si tu veux mon avis, je pense aussi, comme tu l'as dit, que l'informatique est un échec.

Cependant, ce ne sont pas les langages fonctionnels qui aideront les physiciens ou (pire encore !) les chimistes à programmer deux algorithmes à la noix. Beaucoup d'entre eux ont déjà du mal avec des environnements bien foutus et faciles d'accès comme MATLAB ou MAPLE... alors leur parler de Scheme ou d'Objective Caml... ! Je vois mal des physiciens ou des chimistes coder :

Code :

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

1
2
3
qsort []   = []
qsort x:xs = (qsort [ y | y <- xs, y <= x ]) ++ x:(qsort [ y | y <- xs, y > x ])

Pourtant, ça prend deux secondes à écrire, non ? Mais ça reste tout de même très obscur.

Il faut se rendre à l'évidence : le C, l'ADA, le Haskell, le Scheme, l'OCaml, etc... tout ça, c'est de l'informatique informaticienne. Ce sont des langages d'informaticiens, faits par des informaticiens pour des informaticiens. Ni plus ni moins.

Seul FORTRAN 77 (et non 90 !), il faut l'avouer, a réussi son pari : rendre la programmation accessible à un public qui est non informaticien.

[Garulfo]

Si tu veux mon avis, je pense aussi, comme tu l'as dit, que l'informatique est un échec.

Cependant, ce ne sont pas les langages fonctionnels qui aideront les physiciens ou (pire encore !) les chimistes à programmer deux algorithmes à la noix. [...]

Détrompes toi... nous avons un cours de préparation. J'ai choisi (car pour ce cours, je n'ai pas de contraintes de cursus) le Scheme pour commencer à enseigner les notions. Les progrès sont vraiment flagrants. En programmation fonctionnel, tu es proche des maths. Ça les physiciens comme les autres scientifiques y sont sensibles. En une semaine, à 6 heures par jour, en leurs fournissant les primitives d'affichages (comme tracer une ligne), ils font des fractales en scheme. Ça il me faut un bout de temps pour le faire avec des informaticiens (manque de bagages mathématiques). Les physiciens ont cette capacité, mais ils sont écœurés par la syntaxe souvent et les petites gogosses qu'ils trouvent inutiles (gestion de mémoire, notion de pointeur etc.)

L'exemple que tu donnes n'est pas syntaxiquement agréable et est, pour moi, le genre de raison qui me font finalement préféré Scheme. FORTRAN a réussi parce qu'il placait des concepts avant la syntaxe à son époque... de nos jours ce n'est que l'inertie qui explique la réussite continue de FORTRAN. C'est parce que c'est encore utilisé que ça existe encore. Le LISP a été fait dans la même idée et n'est pas un langage fait par et pour les informaticiens. Ce qui explique sont échecs malgré ses grandes idées (manque de performance due à l'avancé des connaissances techniques par exemple). Si on avait eu un compilateur lors de sa création, les choses seraient probablement très différent.

Ici, au Canada, beaucoup de physiciens, ceux qui ne vont pas jusqu'en maîtrise, terminent dans l'informatique de toute façon.

[Jedai]

L'exemple que tu donnes n'est pas syntaxiquement agréable et est, pour moi, le genre de raison qui me font finalement préféré Scheme.

Que reproches-tu à l'exemple de InOCamlWeTrust ???? Syntaxiquement désagréable selon quel critère ?
Ca se lit comme ça s'écrit, et c'est extrêmement proche de la notation mathématiques (tu remplaces le <- par un appartient)... C'est l'écriture la plus élégante et la plus explicite du quicksort que je connaisse !
qsort de la liste vide donne la liste vide,
qsort de x cons xs donne (qsort des éléments inférieurs à x dans xs) concat x cons (qsort des éléments supérieurs ou égal à x dans xs)

Je sais bien qu'on peut faire pareil en Scheme, mais plus proche de la notation mathématique ou plus agréable à l'oeil (ça c'est une question de goût, personnellement les parenthèses à répétition je trouve ça confus, même si un bon éditeur de texte aide) ?

--
Jedaï

[InOCamlWeTrust]

Honnêtement, j'ai rarement vu des physiciens ou autres non informaticiens faire autre chose que du FORTRAN-MAPLE-MATLAB.

Là où je suis en ce moment, à l'ENSEEIHT, on a un gros département de mathématiques appliquées et de calcul scientifique. Les gens qui travaillent dans ce domaine sont essentiellement des mathématiciens et on peut affirmer sans trop se tromper que ce sont eux aussi qui ont le rapport "le moins difficile" avec l'informatique, puisque la finalité est tout de même de produire du code.

Bien que ces gens-là soient capables de produire des algorithmes et des programmes extrêmement optimisés, il est très clair que l'informatique n'est pas réellement leur tasse de thé. Entre autres, on voit trop souvent des programmes entiers en un seul fichier (la programmation modulaire ne semble pas être pleinement rentrée dans les moeurs), des méthodes de conception et de "généricité" plus que douteuses (ou très alambiquées), des codes qui, bien qu'ils compilent avec à peu près la plupart des compilateurs de grande diffusion, ne sont pas standards (on voit encore trop de REAL*8 en FORTRAN 77 par exemple, ou des fonctionnalités dépendant trop d'une implantation particulière), etc...

Lorsqu'on les entend parler, le code est pour eux un détail (expression prise telle quelle), et on sent bien que, que ce soit du côté des numériciens comme du côté des physiciens ou autres, l'aspect "programmation" et numérique de la chose est sinon une tâche ingrate, une étape soit-disant "facile" sur laquelle il ne vaut mieux pas y passer trop de temps.

D'un autre côté, c'est normal, car ce n'est pas leur boulot.

Pour ce qui est de la programmation fonctionnelle, je pense qu'il s'agit réellement, en termes de langages de programmation, le meilleur paradigme qui soit ; en fait, la programmation fonctionnelle est tout simplement le meilleur choix technologique qui soit. Cependant, trop de raisons font qu'en réalité, son usage n'est pas toujours adapté : les concepts sont souvent trop abstraits, la syntaxe peut parfois laisser dubitatif, et le fonctionnement n'est pas naturel dans le sens où, une fois démuni de l'affectation, beaucoup perdent leurs repères car il faut raisonner "fonctionnel", c'est-à-dire penser le programme en termes de données et non en termes procéduraux (chose que les langages tout objet ont exacerbé à un point insuportable).

La programmation fonctionnelle, c'est avant tout un style de programmation dirigé par les données et non par les traitements... Haskell et les langages paresseux le prouvent admirablement bien : si un calcul (ou traitement) ne sert à rien, il n'est pas effectué !

[Garulfo]

Honnêtement, j'ai rarement vu des physiciens ou autres non informaticiens faire autre chose que du FORTRAN-MAPLE-MATLAB.

Je pourrais cependant t'en montrer beaucoup.
Nous avons ici le Mammouth, c'était il y a qqs mois encore le plus gros calculateur du Canada. C'est essentiellement les physiciens qui l'utilisent. Et ils font bien plus de C et de C++ que du Fortran (mais ils l'utilisent certes).

Dans à peu près toutes les universités nord-américaines, la programmation est obligatoire pour les physiciens et les mathématiciens. C'est plus de 75% du temps du C ou du C++.

[...]
Cependant, trop de raisons font qu'en réalité, son usage n'est pas toujours adapté : les concepts sont souvent trop abstraits, la syntaxe peut parfois laisser dubitatif, et le fonctionnement n'est pas naturel dans le sens où, une fois démuni de l'affectation, beaucoup perdent leurs repères car il faut raisonner "fonctionnel", c'est-à-dire penser le programme en termes de données et non en termes procéduraux (chose que les langages tout objet ont exacerbé à un point insuportable).

La programmation fonctionnelle, c'est avant tout un style de programmation dirigé par les données et non par les traitements... Haskell et les langages paresseux le prouvent admirablement bien : si un calcul (ou traitement) ne sert à rien, il n'est pas effectué !

Pas d'accord, la programmation fonctionnelle peut être dirigé par les données ou par les traitements indifféremments. Si tu fais de la programmation par flots pour faire de la traitement de signal en Scheme (exemple classique dans le Abelson/Sussman/Sussman) tu n'as rien de dirigé par les données. C'est le traitement que tu regardes. Quand tu fais de la programmation mathématique en ocaml, c'est pareil. Le fait de ne pas faire un traitement par paresse n'est pas une preuve que tu diriges ta programmation par les données. Données/traitement est une dualité qui n'a aucune corrélation avec la programmation fonctionnelle en soi. Si tu programmes par sous fonctions hiérarchiques (et c'est très classique en fonctionnel du à l'approche fortement teinté de mathématique) alors tu es plus proche du traitement que des données.

La syntaxe ne laisse en rien dubitatif. C'est la première que tu apprends qui influence normalement la suite en la faisant paraître « plus naturel. » Personnellement j'ai appris avec "Logo's turtle". Un mathématicien pense souvent « fonctionnel » car il réfléchit par récursivité et par fonction. Ce n'est pas l'habitude en programmation impérative. Pour peu que ton mathématicien soit un catégoriste c'est encore plus évident. Les concepts abstraits ne les dérangent pas trop en général

N.B. Au passage, si je suis maintenant prof d'info, je suis mathématicien/logicien de formation.

[Garulfo]

Que reproches-tu à l'exemple de InOCamlWeTrust ???? Syntaxiquement désagréable selon quel critère ?
Ca se lit comme ça s'écrit, et c'est extrêmement proche de la notation mathématiques (tu remplaces le <- par un appartient)... C'est l'écriture la plus élégante et la plus explicite du quicksort que je connaisse !
qsort de la liste vide donne la liste vide,
qsort de x cons xs donne (qsort des éléments inférieurs à x dans xs) concat x cons (qsort des éléments supérieurs ou égal à x dans xs)

Je sais bien qu'on peut faire pareil en Scheme, mais plus proche de la notation mathématique ou plus agréable à l'oeil (ça c'est une question de goût, personnellement les parenthèses à répétition je trouve ça confus, même si un bon éditeur de texte aide) ?

--
Jedaï

Je ne lui reproche rien en soi à cette écriture. Et j'ai bien mis un « pour moi » accompagnant le « syntaxiquement désagréable.»
Mais être extrêmement proche d'une écriture mathématique ne veut pas dire plus claire ni plus agréable à l'oeil De plus c'est proche, mais ce ne sont pas des symboles. Les méthodes formelles utilisant des symboles mathématiques sous forme ASCII embarque souvent des transformateurs en PS ou PDF car la lecture est difficile en ASCII (méthode B ou Z par exemple).
Dans ce cas, je trouve personnellement qu'un mot est plus clair. Mais c'est personnel tout ça: agréable ou désagréable est toujours une notion personnelle.

Pour information, d'après les données sur les mesures logiciels, il n'y a pas beaucoup plus de parenthèses dans le scheme qu'il y a de parenthèses, de crochets ou d'accolades dans le C (à nombre de lignes équivalent).
De nombreux dialectes de Scheme intègrent la gestion des accolades et crochets comme des parenthèses pour donner plus de choix. Parfois c'est effectivement agréable.

[InOCamlWeTrust]

Je pourrais cependant t'en montrer beaucoup.
Nous avons ici le Mammouth, c'était il y a qqs mois encore le plus gros calculateur du Canada. C'est essentiellement les physiciens qui l'utilisent. Et ils font bien plus de C et de C++ que du Fortran (mais ils l'utilisent certes).

Dans à peu près toutes les universités nord-américaines, la programmation est obligatoire pour les physiciens et les mathématiciens. C'est plus de 75% du temps du C ou du C++.

Je parlais de la France...

Pas d'accord, la programmation fonctionnelle peut être dirigé par les données ou par les traitements indifféremments. Si tu fais de la programmation par flots pour faire de la traitement de signal en Scheme (exemple classique dans le Abelson/Sussman/Sussman) tu n'as rien de dirigé par les données. C'est le traitement que tu regardes. Quand tu fais de la programmation mathématique en ocaml, c'est pareil. Le fait de ne pas faire un traitement par paresse n'est pas une preuve que tu diriges ta programmation par les données. Données/traitement est une dualité qui n'a aucune corrélation avec la programmation fonctionnelle en soi. Si tu programmes par sous fonctions hiérarchiques (et c'est très classique en fonctionnel du à l'approche fortement teinté de mathématique) alors tu es plus proche du traitement que des données.

Réfléchis !

Si la programmation fonctionnelle était dirigée par les traitements, celà voudrait dire que l'ordre d'évaluation des expressions aurait une importance cruciale ; or il n'en est rien, et c'est tout le contraire. Les langages paresseux ont justement été créés pour ça, pour ne pas induire le principe de l'ordre d'évaluation des expressions !

De plus, la programmation mathématique peut être classiquement de l'ordre du traitement, mais on peut aussi en faire à un niveau données !

[gorgonite]

La programmation fonctionnelle, c'est avant tout un style de programmation dirigé par les données et non par les traitements... Haskell et les langages paresseux le prouvent admirablement bien : si un calcul (ou traitement) ne sert à rien, il n'est pas effectué !

ben ce n'est plus une spécificité des langages fonctionnelles... il existe une optimisation relativement simple à effectuer (une fois qu'on est sous forme SSA), qui permet de ne garder que le code atteignable (au sens que si le résultat d'un calcul n'est pas utilisé pour une I/O il sera oublié )

[Garulfo]

Si la programmation fonctionnelle était dirigée par les traitements, celà voudrait dire que l'ordre d'évaluation des expressions aurait une importance cruciale ; or il n'en est rien, et c'est tout le contraire. Les langages paresseux ont justement été créés pour ça, pour ne pas induire le principe de l'ordre d'évaluation des expressions !

De plus, la programmation mathématique peut être classiquement de l'ordre du traitement, mais on peut aussi en faire à un niveau données !
[...]

L'évaluation dite paresseuse est à la base la « vraie » évaluation de la programmation fonctionnelle. Elle vient du lambda-calcul. Il est vrai qu'elle est arrivée après. Cependant ce n'est qu'un détail d'implémentation et non un paradigme (une manière de percevoir le monde). C'est pour cela que sans l'évaluation paresseuse, il faut des formes spéciales pour représenter le «if» par exemple, en scheme. Et tu utilises des macros pour induire une évaluation paresseuse.

Mais lorsque faire un programme en fonction du traitement, c'est voir ton programme selon sa simple fonctionnalité en mettant de côté, dans l'architecture de ton programme, les entités sur lesquelles tu agis. Faire selon les données, c'est réflechir en prenons en compte les données, abstraire sur elle, puis regarder leurs interactions. L'évaluation paresseuse peut très bien être dirigé par les traitements.

Je ne sais pas qui t'a appris ça, mais il avait une mauvaise interprétation d'un programme orienté par le traitement. C'est plutôt la programmation procédurale qui est en lien avec le traitement, et la programmation par objets/classes/aspect qui est en lien avec les données.
Dans les deux cas tu peux faire ou non de l'évaluation paresseuse.

Remarques c'est peut être juste qu'on a pas les mêmes définitions alors je vais y reréflechir... mais tu devrais toi aussi faire pareil.

[InOCamlWeTrust]

L'évaluation dite paresseuse est à la base la « vraie » évaluation de la programmation fonctionnelle. Elle vient du lambda-calcul.

Non : l'évaluation paresseuse s'explique très bien en termes de lambda-calcul, certes, mais le lambda-calcul est lui-même indépendant du fait que l'on commence à réduire à gauche (réduction paresseuse) ou à droite (réduction stricte). La seule stratégie sûre, si la forme normale existe, est l'évaluation paresseuse, mais évaluer de façon stricte une lambda-expression, a aussi son sens.

Mais lorsque faire un programme en fonction du traitement

...

Remarques c'est peut être juste qu'on a pas les mêmes définitions alors je vais y reréflechir... mais tu devrais toi aussi faire pareil.

La seule chose que j'ai dite, c'est que les programmes fonctionnels étaient dirigés par les données, c'est-à-dire que l'ordre des traitements est lui-même fortement correlé à la structure interne des données. La notion de filtrage, par exemple, en est un exemple : rien de tel dans langage plus procédural (mis à part le switch du C... et encore !).

Les langages plus impératifs/procéduraux retardent de beaucoup les traitements spécifiques à certaines données : un bon exemple en est la programmation tout objet où les traitements spécifiques sont souvents implantés par plusieurs sous-classes, de même niveau, héritant d'une super-classe ou implantant une interface. C'est ici un exemple de programmation où les données ne dirigentt que très sommairement les traitements.

En effet, si on a deux classes Class1 et Class2 implantant une même interface Interface, le code purement spécifique aux données de Class1 et Class2 se situe au niveau de l'initialisation, c'est-à-dire (en Java) :

Code :

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

1
2
3
4
5
6
Interface objet = new Class1(); // ou Interface objet = new Class2();

// ...

objet.traitement();

Voilà un exemple de code dirigé par les traitements.

En programmation fonctionnelle, on aurait utilisé un filtrage !