Discussion :

[InOCamlWeTrust]

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é )

On ne parle pas de la même chose : ton optimisation consiste en trouver les passages morts d'un programme, ceux qui ne s'exécuteront jamais. L'évaluation paresseuse le fait de façon dynamique (mais les compilateurs Haskell implantent aussi, bien entendu, ce genre d'optimisation... en fait, tout langage normalement constitué).

[Garulfo]

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

J'ai dit que cela venait du lambda-calcul. Pas que le lambda-calcul n'avait qu'une façon de faire...

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

Et tu as ajouté que la programmation paresseuse en est la preuve (pas en ces termes)... mais je ne suis pas d'accord.

D'une part la programmation fonctionnelle peut être dirigée par le traitement

Code :

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

1
2
3
4
5
6
 
let f x = x + 1
and g x = x + 2
in
   y = f 3 + f 5 
;;

est une exemple (certes très simple) qui n'est pas dirigé par les données.
La programmation fonctionnelle n'est donc pas automatiquement orientée par les données.
D'autre part, si tu dis que l'évaluation paresseuse en est la preuve, puisque le if dans tous les langages est une forme d'évaluation paresseuse; le filtrage étant un cas général du if.
Donc un programme en C est d'office d'après toi, un programme orienté par les données dès qu'il a un if ?
En effet, dans un if le traitement dépend de ta donnée ?

On pourrait le voir ainsi et dire que tous les programmes sont à la fois orientée par les données et par les traitements. Et c'est en partie vrai.

Cependant, l'orientation d'un programme, vient d'un paradigme, et remonte bien avant son mode d'évaluation, ou l'utilisation des structures internes.

Classiquement, on dit qu'on utilise un paradigme orienté par les données (DOP) si on réfléchit en terme de données et non en terme de traitement, en priorités (car il est absurde bien entendu de ne pas considérer l'autre).

C'est pour cela que je ne suis pas d'accord globalement. Je suis d'accord sur le fait qu'on tend souvent à partir vers un structure se préoccupant plus des données car on tend à réflechir plus facile dans des structures de données en fonctionnel. Cette structure de donnée étant éventuellement construite par un ensemble de fonctions. Cependant, c'est loin d'être la seule manière de réflechir en fonctionnel. Suivant la tâche à remplir, une approche purement orientée vers les tâches peut être plus intéressante et mise en oeuvre.
Un prof et collègue me rappelait
être orienté par les traitements c'est écrire f x alors qu'être orienté par les données c'est écrire x f.
C'est-à-dire que c'est une manière de voir et non une réalité en soi, et c'est totalement inversible dans un même langage. Je fais de la programmation orientée par les données quand c'est elle que je considère en premier. Quand tu fais un lissage de fonction en théorie du signal, et en général de la programmation numérique, tu ne réflechis que très rarement avec les données en premier. C'est le traitement qui prend le devant de la scène.

C'est ta généralité seulement que je remets en cause, pas tout ce que tu dis. Si je n'ai pas été clair, je m'en excuse.

[gorgonite]

On ne parle pas de la même chose : ton optimisation consiste en trouver les passages morts d'un programme, ceux qui ne s'exécuteront jamais. L'évaluation paresseuse le fait de façon dynamique (mais les compilateurs Haskell implantent aussi, bien entendu, ce genre d'optimisation... en fait, tout langage normalement constitué).

pas du tout... tu parles d'une autre optimisation

celle dont je parle va éliminer tous les calculs qui ne seront pas utilisés... ce qui aura aussi pour effet de supprimer le code mort

[gorgonite]

en ce qui concerne le débat sur le programmation paresseuse, selon moi elle vient surtout de la différence dans les méthodes d'appels des fonctions (appel par valeur "classique" vs appel par nom de la machine de Krivine )

[InOCamlWeTrust]

Et tu as ajouté que la programmation paresseuse en est la preuve (pas en ces termes)... mais je ne suis pas d'accord.

Les traitements produisent des résultats, c'est-à-dire des données, en fonction desquelles certains calculs ultérieurs seront effectués ou pas.

Quand je dis que la programmation fonctionnelle est dirigée par les données, je veux dire que l'on utilise beaucoup plus souvent ce genre de programmation que dans les langages procéduraux... si tu préfères, on peut dire qu'elle est principalement dirigée par les données.

Le if est bien-sûr paresseux, mais les langages impératifs sont dénués de beaucoup d'aspects permettant de filtrer et décomposer les données : le filtrage peut être, en C, implanté grâce au switch (et c'est, entre autres choses, ce qui me fait penser que le C, et surtout le C GCC, est un petit langage fonctionnel), mais dans la majorité des cas, les fonctionnalités pour décomposer une donnée sont limitées.

[Garulfo]

[...]

Tu m'as fait douté suffisamment pour que j'en parle autour de moi. Mais après une discussion avec mes collègues... je ne suis toujours pas d'accord avec toi.

Cependant, j'ai l'impression que c'est plus un problème sémantique que de fond

Pour le C comme langage fonctionnel, il lui manque l'essentiel : manipuler les fonctions comme des données quelconques. En fait, il est vrai que c'est faisable... comme en Java... mais pas de manière directe.

[gorgonite]

Pour le C comme langage fonctionnel, il lui manque l'essentiel : manipuler les fonctions comme des données quelconques. En fait, il est vrai que c'est faisable... comme en Java... mais pas de manière directe.

pas d'accord la manipulation de pointeurs de fonctions est immédiat en C


en revanche, selon moi, ce qui fait que C n'est pas un langage fonctionnel est l'absence d'évaluation partielle des fonctions

[InOCamlWeTrust]

en revanche, selon moi, ce qui fait que C n'est pas un langage fonctionnel est l'absence d'évaluation partielle des fonctions

Exact, même si on pourrait contourner l'affaire en englobant l'appel partiel dans la définition d'une fonction avec moins de paramètres.

En réalité, si on prend le C version GCC, il lui manque ce trait-ci et la possibilité de définir des fonctions anonymes.

Avec GCC, étant donné qu'un bloc entier peut être considéré comme une expression (ce qui n'est pas autorisé en C-ANSI) et que l'on peut définir des fonctions à l'intérieur d'autres fonctions, on voit bien qu'il manque relativement peu de choses au langage pour devenir réellement fonctionnel !

[gorgonite]

En réalité, si on prend le C version GCC, il lui manque ce trait-ci et la possibilité de définir des fonctions anonymes.

effectivement, je l'ai oublié celui-ci



ps: on arrete avec le C... on s'éloigne du débat initial

[InOCamlWeTrust]

Ben non puisque c'est un langage fonctionnel !

[Garulfo]

pas d'accord la manipulation de pointeurs de fonctions est immédiat en C

La définition d'un langage fonctionnel est que celui-ci manipule les fonctions comme les autres données. Donc dans une pure définition le C serait fonctionnel. Mais le Java aussi. Et le python. Comme toujours la définition est flou.

Je cite la définition de Mauny (in Functional Programming Using Caml Light, 1992) qui est plus précise: « Programming languages are said to be functional when their basic component is the notion of function and their essential control structure is function application.» (p.5)

La manipulation de fonction en C est effectivement là, mais ce n'est pas la composante de base. C'est en ça que je parle d'«indirecte». Ce n'est pas l'objectif premier des pointeurs (même sur void) de pouvoir manipuler des fonctions. Il n'y a pas d'opérateurs de créations d'une fonction par exemple en C. Mais c'est faisable... tout est faisable en C de toute façon. Sinon comment pourrions nous compiler du ocaml en C ?

[InOCamlWeTrust]

Jamais vu du Caml compilé en C, moi !

[Garulfo]

Jamais vu du Caml compilé en C, moi !

C'est pas grave un jour tu auras cette chance soit pas jaloux

En fait je pensais à Scheme et j'ai écris caml. Je ne suis pas sur des stratégies de compilation pour caml. Mais évites de lire le mot et lis l'esprit de ce que j'ai dit. Sinon on va s'ostiner en perdant notre temps. Tu as bien compris ce que j'ai voulu dire quand même ? Qu'il soit écrit caml ou scheme ou autre chose: le C permet de tout faire.

Maintenant, es tu convaincu à 100% que ocaml ne fait pas une conversion en C ? Génère-t-il directement le code objet sans passer par le C ? Ce n'est que détail mais je suis curieux.

[InOCamlWeTrust]

Il n'y a pas une traitre ligne de C ni dans les compilateurs Objective Caml (qui sont écrits en Objective Caml), ni dans la phase de compilation. Objective Caml est directement compilé en assembleur, ça j'en suis même plus que sûr car je passe beaucoup de mon temps libre (informatique) à lire et étudier les compilateurs Objective Caml.

Ce qu'il y a, par contre, c'est que le programme source est transformé en plusieurs arbres successifs. L'une des dernières représentations logiques du programme porte le nom de C--, qui n'a pas grand chose à voir avec le C en réalité : c'est une appellation que j'ai déjà rencontrée dans d'autres compilateurs (mais je ne me souviens plus très bien : GHC, peut-être ?).

Tu peux regarder le dossier asmcomp/ de la distribution source d'Objective Caml pour t'en convaincre.

En fait, si ça t'intéresse, Objective Caml a été un langage entièrement bootstrappé de A à Z : en clair, à aucun moment on n'a compilé les compilateurs Objective Caml avec autres chose que du Caml (ou des versions intermédiaires du langage, entre autres le langage reconnu par la machine virtuelle).

[Garulfo]

Il n'y a pas une traitre ligne de C ni dans les compilateurs Objective Caml (qui sont écrits en Objective Caml), ni dans la phase de compilation. Objective Caml est directement compilé en assembleur, ça j'en suis même plus que sûr car je passe beaucoup de mon temps libre (informatique) à lire et étudier les compilateurs Objective Caml.
[...]
Tu peux regarder le dossier asmcomp/ de la distribution source d'Objective Caml pour t'en convaincre.

Je te crois lol.
Quand je pose une question, c'est une question, pas un piège

En fait, si ça t'intéresse, Objective Caml a été un langage entièrement bootstrappé de A à Z

Ça m'intéresse effectivement pour d'autres projets. J'ai fait qqs recherches sur la compilation mais il n'y a pas grand chose d'explicite a priori. Cependant, ce n'est pas une priorité pour moi. Donc je maintiens ça a une vitesse secondaire. ^_^

[ol9245]

Bjr,

Je prend votre thread en cours de route et je le trouve très interessant.
Mon avis de programmeur de longue date est que le langage n'est pas important. Le choix est très conjoncturel.
Choisir un langage, c'est comme choisir une paire de chaussures.

1/ Ca dépend de là ou on va : mer, montagne, ville : il n'y a pas une paire de pompes idéale !

2/ ca dépend de la mode. C'est con à dire, mais il faut savoir s'adapter. Il y a 10 ans toutes ls grosses applis se programmaient en C++. Avec le recul les chefs de projets ont réalisé que le cout de maintenance de leurs codes en C++ était prohibitifs et ils ont laissé tombé. La mode est passé à Java et les jeunes sur le marché parlaient tous Java. Les chefs de projet ont suivi. Aujourd'hui, je ne sais plus, mais ça doit continuer à tourner avec la mode, ya pas de aison que ça change.

3/ Pour savoir si une paire de pompe te fera de l'usage, ce que tu as vu dans la boutique avant d'acheter n'est pas suffisant. Il faut essyer pour se faire une idée. Et pour ça il faut pratiquer beaucoup de langages différents.

Finalement, soyez curieux et pragmatiques. Meme quand vous vous perfectionnez sur votre langage de prédilection du moment, donnez une chance aux autres alternatives.

Dernier point : pour moi, la priorité n°1 c'est la taille de la communauté qui utilise un langage. Je ne suis pas un pionnier pour me faire c###r dans mon coin en solitaire et à devoir porter sur mon langage tous les codes que je trouve sur internet parcequ'il sont écrits sur autre chose. Si ma communauté change de pratiques, je suis !

En fonction de tous ces critères, au jour d'aujourd'hui, par exemple et en ce qui me concerne (recherche scientifique), c'est matab qui a la palme. Mais ça m'empêche aps d'écrire en VBA, C ou C++ et même Fortran quand j'en ai besoin.

A chacun de faire son analyse, d'être flexible, et d'éviter le piège des chapelles, des querelles de clocher et des discussions byzantines.

Savoir la structure du langage, sa beauté intrinsèque, je m'en fout complètement. c'est pas la beauté d'un langage qui produit mon code. Et si le llangage est pas beau mais qu'il y a dex millions de personnes qui l'utilisent dans le monde, je ferais mon shopping sr Internet et je développerais mes applis sans réinventer la roue.

Voila, c'était mon grain de sel. Merci d'avoir lu
Bonne journée à tous, OL

[InOCamlWeTrust]

Petite question : as-tu appris l'informatique dans une école (d'ingénieurs o autres), ou savais-tu déjà bien programmer avant de te former dans un établissement ?

J'aimerais bien continuer la discussion, mais avoir la réponse à la question m'intrigue.

J'ajoutterai une seule chose : travailler avec des outils que l'on aime, avec lesquels on se sent bien, c'est tout aussi important au moment d'être productif.

[ol9245]

Petite question : as-tu appris l'informatique dans une école (d'ingénieurs o autres), ou savais-tu déjà bien programmer avant de te former dans un établissement ?

J'aimerais bien continuer la discussion, mais avoir la réponse à la question m'intrigue.

Je suis chercheur. Dans les labos de recherche, nous ne recrutons pas d'informaticien. Donc les chercheurs qui programment ont tous appris sur le tas (Sauf ceux pour qui l'informatique est leur thème de recherche. Ceux là font de la recherche EN informatique, pas AVEC de l'informatique). Les chercheurs n'ont besoin pour leur propre usage que d'outils relativement simples. Quand il faut des trucs plus compliqués, comme du réseau, des serveurs, etc. ce sont effectivement des ingénieurs en informatique qui font ça. A chacun son métier.

Par contre les besoins peuvent être très variés, d'ou l'importance pour nous d'avoir accès à une large communauté Internet avec qui on peut échanger du code. C'est la raison pour laquelle Matlab a si bien réussi dans le monde de la recherche. Virtuellement tous les algorythmes de base ont au moins une version publique en Matlab. Le temps que nous passons à cracher du code n'est pas valorisé dans notre métier de chercheur. Seul la science que nous faisons avec est valorisée. Il est donc très important pour nous de cracher du code qui marche le plus vite possible.

Ceci dit, j'ai pas mal d'amis qui font de l'info dans le privé, banques, Bourse, gestion, etc. Quand on se voit, on bavarde...

J'ajouterai une seule chose : travailler avec des outils que l'on aime, avec lesquels on se sent bien, c'est tout aussi important au moment d'être productif.

aimer est un peu excessif. Disons "habitué à" : c'est moins noble, mais plus juste. Le piège c'est de s'en tenir à ce à quoi on est habitué (et comme tu dis qu'on a fini par aimer) parceque le cout d'une migration est (supposé) trop élevé. Avec suffisamment de curiosité et de gout de la nouveauté dans les veines, on arrive toujours à trouver un projet ou la pression de productivité est moins forte et ou on peut en profiter pour découvrir autre chose.

Et puis, dans un objectif de production ou il faut prendre en compte le cycle de vie du code et donc sa maintenance, pas forcément par celui qui l'a écrit, il y a bien d'autre considérations à prendre en compte pour le choix de la plateforme de développement.

Finalement, pour revenir à Matlab, le côté estétique dont tu parles n'y est pas : Matlab est très frustrant par bien des points : pas de pointeur, pas de passage d'argument en lecture/écriture par adresse, pas de typage des structures, pas de template, pas de structure de donnée évoluée genre liste ou arbre (ah les arbres avec Matlab ! Quelle aventure !) Bref, du point de vue esthétique c'est pas bandant !

Mais alors, quelle rapidité pour cracher du code !!! Je me régale ! J'ai porté l'autre jour une maquette Matlab en C++. Ca faisait un petit bout de temps que je n'avais pas utilisé mon compilo et ça m'a fait tout drôle la quantité de lignes à écrire pour dire pas grand chose ;-)

OL

[ol9245]

Finalement, en iformatique c'est comme dans la vraie vie : on apprend rarement une langue pour sa beauté (sauf si on est linguiste). On l'apprend pour la communauté à laquelle elle donne accès.
OL

[InOCamlWeTrust]

Si je t'ai posé la question, c'est bien parce que j'ai tout de suite senti la réponse.

En informatique, et parmis la faune des informaticiens, on peut faire deux catégories : ceux qui font de l'informatique parce que c'est leur boulot, et ceux qui en font parce que c'est leur passion.

On ne dirait pas comme ça, mais il y a un fossé énorme entre les deux catégories : d'un côté ceux qui cherchent, étudient, en plus de leurs études ou de leur travail, et ceux qui se contentent de faire ce dont ils ont besoin sans jamais se poser vraiment de questions.

Je comprends bien ce que tu dis à propos de MATLAB : je suis étudiant en mathématiques appliquées et informatique (en majeur mathématiques qui plus est, mais je fais beaucoup d'informatique chez moi), et je suis amené à utiliser tous les jours ce truc, pratique des fois, mais dont je ne suis absolument pas fan (si tu veux savoir pourquoi, c'est par message privé, car ce n'est pas l'objet de ce sujet).

L'objet de ce thread est avant tout le choix d'un bon langage fonctionnel, adapté à l'utilisation que l'on veut en faire.

Concernant ta remarque sur les langages de programmation et l'industrie, elle ne montre qu'une chose : l'échec

1- de la programmation tout impérative (C, ADA, FORTRAN, quoique, et autres...)
2- de la programmation tout objet et impérative (Java, C ++, Python, etc...)

En effet, si les modes passent, repassent... et si l'on change à chaque fois de langage pour espérer économiser quelques euros pour se rendre compte cinq ans après que l'on n'a rien économisé du tout, c'est bien parce que les outils (ici les langages de programmation) sont de mauvaise conception.

C ++ ? Java ? Python ? tout ça c'est la même merde.

La programmation tout objet implique une verbosité déconcertante et une façon de structurer l'application qui est mauvaise en termes de maintenabilité et de génie logiciel. En effet, si une classe est vue comme un module, ces modules peuvent faitre apparaître des dépendances croisées, frein à la maintenabilité : rien de ça en Objective Caml (ou alors, au sein de la même unité de compilation), ou en Haskell, par exemple. A celà s'ajoute le fait que les modules spécifient très bien ce qu'ils produisent, mais non ce dont ils dépendent (les méthodes d'un module extérieur nécessaires ne sont pas spécifiées), ce qui, ajouté aux dépendances croisées, augmente affreusement la fragilité du code.

Le fait que l'on ne cesse de changer de langage pour finalement prendre une chose équivalente, fait que les mauvaises habitudes de programmation sont enracinées dans "l'industrie". En fait, prendre l'industrie comme exemple est en soi une mauvaise démarche, à mon goût, car les cas de mauvaise programmation et de programmes bidon, mal foutus y sont légion.

Si l'on voulait un exemple plus pertinent pour mesurer les qualités intrinsèques d'un langage de programmation, je pense que prendre le cas de GNU serait mille fois plus intéressant, étant donné que toutes les applications GNU sont des références dans leur domaine : bash, make, GCC, G77, GNAT, Linux (si c'est du GNU...), etc... ou encore prendre le cas de la recherche en informatique et calcul scientifique intensif (C et FORTRAN 77 : les autres, ils vont directement à la poubelle !).

En recherche en informatique, le but est de proposer non seulement des applications qui sont à la pointe, mais aussi de montrer les bonnes et saines méthode de programmation, dans la mesure du possible. Les algorithmes sont compliqués, souvent, et avoir recours à un langage fonctionnel est un très bon choix car il permet une abstraction très élevée.

Ainsi, la mode ne peut être un bon argument ; ce n'est pas parce que Java est à la mode qu'il convient à ce que l'on fait (en tous cas, je me vois mal cet été proposer à mon directeur de stage de l'INRIA faire du Java...) : le cas du calcul scientifique et/ou numérique en est un exemple. De plus, il n'y a rien de pire qu'une chose à la mode : en général, les choses à la mode se démodent très vite (Java et les Doc Martens, que j'adore et porte toujours...), mais celles qui ne sont jamais à la mode restent (FORTRAN 77 et les mocassins).

La taille de la communauté ? Hmmmm... je dirais plus sa réactivité et son esprit : ce n'est pas parce qu'une communauté est grande que l'on trouvera facilement du soutien (Java...). Par contre, des communautés plus petites peuvent être beaucoup plus réactives (www.dvp.com ou encore Haskell...) !

Enfin, de nombreuses études ont montré que le passage d'un langage impératif/objetc à un langage fonctionnel pouvait être une très bonne solution pour économiser de l'argent (tu prends ton code Java, tu le divises par un facteur 4 ou 5, quand ce n'est pas 10 ou 20, et tu as la même chose en Objective Caml ou Haskell) et surtout fournir en très peu de temps un premier prototype. Je donne ici un lien très intéressant comparant divers langages aux paradigmes tous différents : le but est de concevoir une application, mesurer sa maintenabilité, le temps de développement et aussi ses performances :

http://haskell.org/papers/NSWC/jfp.ps

Ou ici, section 3.6 :
http://www.haskell.org/haskellwiki/Books_and_tutorials

On pourrait continuer longtemps ainsi...