Comme annoncé dans l'article http://linuxfr.org/2006/03/09/20473.html la conférence donnée par Benoit Sonntag c'est déroulée aujourd'hui.
Je tient d'abord remercier B. Sonntag qui est une personne très sympatique et qui nous a fait un exposé intéressant et synthétique durant les trois heures de la présentation publique. Petit detail sympa la présentation a été affichée avec un portable tournant sous Isaac.
Nous avons pu ensuite essayer en pratique le compilateur qu'il a écrit et ainsi constater la qualité du travail fournie de nos propres yeux (et doigts). Et ceci malgré la grande jeunesse du projet. A noter qu'une autre session sera probablement organisée.
Personellement j'était plutot sceptique sur quelques point du projet (qui ont d'ailleur été discuté ici) que je trouvais choquant comme :
- l'intéret d'un langage ne proposant pas de condition (if then else) ou d'itérateur (for while) dans la syntaxe du langage.
- la capacité d'un langage objet a se plier aux exigences de la programmation système
- l'utilitée de passer d'un langage objet à classe (le standard pour plus au moins tout le monde) a un langage objet à prototype (que je ne connaissais pas)
Finalement j'ai été très impressionné pas les réponses qui m'on été donnée ! J'aurai aimé que ce ne soit pas moi qui les exposes ici (on aurait du faire une video, l'exposé était très clair).
Malheureusement le projet en est à ses tout début d'ouverture au public et je me rend compte qu'il n'existe pas de document écrit syntétisant ce qui a été dit oralement. Les slides de la présentation sont disponibles mais présentent uniquement des figures illustratives. (figures a haut pouvoir trollifere d'ailleurs, surtout le début avec en apothéose le slide 7 de project_st_overview.pdf :)) cf site)
Pour essayer d'expliquer les choses quand même, je dirais que le modèle objet à prototype ajoute un réel pouvoir expressif à la programmation objet. Et contrairement à la plupart des extensions récentes des langages, cela rend le langage plus simple et plus cohérent. Et cela en conservant les avantages déjà acquis avec les langage à classes.
Une fois qu'on a posé les bases de la syntaxe on se rend compte que les structures de controles définies dans la bibliothèque sont la seul manière de faire logique dans ce contexte.
Finalement les quelques extension nécessaire à la programmation système (les interruptions et la gestion des masques de bits principalement) se fondent totalement dans le modèle à prototypes. De plus ces méchanismes ont montré leur efficacité lors du développement par B. Sonntag d'un système sur un nouveau processeur qui a été réalisé plus rapidement que les ingénieurs de la société travaillant en C.
En conclusion je voudrai ajouter que loin de sortir de nulle part ce projet propose une synthèse du meilleur que l'on peut trouver dans le domaine objet avec des inspiration comme smarteiffel, self et smalltalk.
(malheusement assez peu connu, quoique smarteiffel est réputé pour la rapidité de son code produit, d'ailleurs l'encadrant de thèse de B. Sonntag est le principal développeur de smarteiffel, et smalltalk possède une machine virtuelle libre qui fait régulierement l'objet de depèches enthousiastes ici).
Et plus de cela, le projet possède, à mon humble avis, deux principales innovation :
- Un compilateur extrement performant associé a un langage très expressif (je ne pense pas avoir déjà vu mieux). On a vraiment l'impression d'avoir affaire à la souplesse d'un langage de script alors qu'on a la performance des langage compilé.
- Réussir a faire le grand écart entre un langage de haut-niveau et les préoccupations matériels des ordinateurs et des système d'exploitation. Pour ce rendre compte de ca il faut surtout regarder le travail accompli sur le (prototype) de système d'exploitation isaac.
PS : Désolé pour les fautes, je me désespère moi même :) C'est loin d'être exaustif de la présentation, je voulais surtout présenter un point de vue personnel.
PS2 : la disponibilité de la totalité des sources sous licence libre est apparement bien engagée.
Journal Un compte rendu de la conf sur isaac/lisaac
23
mar.
2006
# Autres langages à prototype
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Sinon pour plus de détails, je vous recommande la lecture de l'article sur wikipedia http://en.wikipedia.org/wiki/Prototype-based_programming (la version française est plutôt maigre..)
[^] # Re: Autres langages à prototype
Posté par outs . Évalué à 3.
Mais lisaac est typé statiquement et compilé, il est donc plutot sur et efficace. Donc il répond à la plupart des critiques.
A part la dernière sur le fait que les developpeur ne sont pas familier avec cette technique. Mais bon ca c'est comme n'importe quel innovation. Genre y'a plein de gens qui sont boulonné au C et qui ne veulent surtout pas changer, quelque soit les arguments qu'on leur donne. A mon avis c'est le peur de quitter un environnement familier où ils exercent un position privilégiée ... surtout quand la nouvelle technique rend caduque un travail autrefois fait à la main !
Mais bon y'a pas de gens comme ça ici ! non ? :)
[^] # Re: Autres langages à prototype
Posté par Ontologia (site web personnel) . Évalué à 2.
Non, juste 95 % ;-*)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Pffff...
Posté par Anonyme . Évalué à -5.
Oui, je sais, je suis amer, mais quand ça fait 1 an qu'on se bouffe cette daube de Caml à la fac, on finit par devenir méchant.
Quand je vois que le Caml, prétendumment très à l'aise avec le typage, pas foutu de faire la différence entre un entier et un flottant si on ne rajoute pas un point à l'opérateur, ça me fait plus pitié qu'autre chose...
Allez, je sais, je vais encore me faire moinser, mais bon, cpas grave...
[^] # Re: Pffff...
Posté par Fanf (site web personnel) . Évalué à 1.
[^] # Re: Pffff...
Posté par outs . Évalué à 8.
mdr, c'est sur que faire la différence entre (je veux un entier) 3+4 et (je veux un flottant) 3+4 c'est réalisé par tout les compilo du monde.
C'est exactement pareil pour tout les langage a un moment donné il faut que tu dise au compilo quel type tu veux utiliser. Or il n'y a pas de déclaration de type en Caml donc ils utilisent des opérateur différent "+" et "+.". Dans le contexte c'est la seul manière de faire.
Apparement tu a encore des progres a faire en prog fonctionnelle :)
Sérieusement ce qui est vraiment dommage c'est qu'ils n'ont pas utilisé l'extension objet de OCaml pour définir un type Nombre et uniffier l'interface des opérateurs entre les entiers et les flottants.
Pour en revenir au sujet : ce point la est traité correctement en Lisaac. On manipule les différentes type de nombres (entiers ...) suivant la même interface.
[^] # Re: Pffff...
Posté par Anonyme . Évalué à -3.
Quand tu écris 3 + 4, ce sont des entiers. Quand le nombre contient un ".", c'est un flottant, et puis c'est tout.
Donc un compilo qui lit 3 + 4, il conclut binop(+, int(3), int(4)), et quand il lit 3.5 + 4.3, il conclut binop(+, float(3.5), float(4.3)), c'est pourtant pas compliqué...
[^] # Re: Pffff...
Posté par Midilaïr (site web personnel) . Évalué à 2.
3 + entrée = ??? entier ou flottant
[^] # Re: Pffff...
Posté par Anonyme . Évalué à 1.
Ton entrée est un nombre de touches frappées ? c'est un int.
Ton entrée est "quelqu'un a cliqué ?" c'est un bool.
[^] # Re: Pffff...
Posté par outs . Évalué à 4.
Mais ce n'est pas suffisant ici :
exemple :
let add x y = x + y ;;
Dis moi quelle est le type des paramètres formels x et y suivant ta méthode ? int ou float ?
[^] # Re: Pffff...
Posté par Anonyme . Évalué à 2.
Et si ce n'est ni des entiers, ni des flottants ? Et bien soit l'opérateur + a été redéfinis pour le type correspondant, soit on lance une exception.
[^] # Re: Pffff...
Posté par lolop (site web personnel) . Évalué à 4.
Tu me montreras ton compilateur qui "s'en tape joyeusement".
Comme tu dis: "pour le type correspondant".
Alors le nombre 1, dis moi, c'est un entier ou un flottant ?
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Pffff...
Posté par Vivi (site web personnel) . Évalué à 4.
En OCaml les types entiers ont une arithmétique d'anneau, modulo 2^31 (ou 2^63). Mais les flottants suivent l'arithmétique IEEE 754 avec tous ses comportements bizarres (valeur NaN non comparable aux autres valeurs, non-associativité a priori des opérations, etc.)
Et ça évite ce genre d'erreur facile à faire en C: double x = a / b; où a et b sont des entiers.
[^] # Re: Pffff...
Posté par Yusei (Mastodon) . Évalué à 6.
Tu pas du principe que la surcharge d'opérateurs est quelque chose qui va de soi, malgré le fait que l'opération "addition" est très différente selon le type des données. La surcharge d'opérateur, c'est du sucre syntaxique pour faire plaisir au développeur, rien de plus.
OCaml a fait le choix de renoncer à ce sucre syntaxique pour proposer autre chose qui fait plaisir au programmeur: l'inférence de type. L'inférence de type permet de supprimer la plupart des erreurs de typage à la compilation, donc c'est quelque chose qui apporte un bénéfice évident.
Or toi, au lieu de reconnaître que c'est un choix, avec lequel tu peux être d'accord ou non, tu prétends que c'est de l'incompétence. Il y a des moments où on préfère que son code soit garanti valide, et il y a des moments où on préfère que son code soit facile à écrire. En particulier, il y a des moments où on voudrait se rendre compte à la compilation que l'opérateur "+" n'existe pas pour l'objet manipulé, et pas à l'exécution quand l'exception est levée.
[^] # Re: Pffff...
Posté par Vivi (site web personnel) . Évalué à 1.
hmm non, pour ça les langages fonctionnels utilisent plutôt des type classes cf. http://en.wikipedia.org/wiki/Type_class .
Mais ça n'existe pas en OCaml.
[^] # Re: Pffff...
Posté par lolop (site web personnel) . Évalué à 6.
Peux-tu m'indiquer le langage qui sait deviner l'intention du codeur?
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Pffff...
Posté par Thomas Douillard . Évalué à 7.
Non pas pour te dénigrer, mais en tant qu'étudiant qui fait du Ocaml depuis un an, qui est énervé par les contraintes de typages, t'as pas forcément beaucoup de recul sur ce qui est bien ou mal dans un typage si fort. Surtout si t'as fait du PHP avant. C'est bien, c'est facile, peu de contraintes, mais une horreur à debugger (c'est que mon avis, mais j'ai pratiqué, et je le partage).
[^] # Re: Pffff...
Posté par salvaire . Évalué à 5.
- Pays-bas avec Python, un succès
- La France avec Ocaml et Lissac, marginal
- Japon avec Ruby, qui est encore peu utilisé
Au USA, il n'y a rien eu depuis l'innommable C++, et Java, toujours empêtré avec Sun ... C# étant un ramassis du reste (C et Perl existant depuis des lustres)
Je ne saurai conseiller d'organiser des VRAIS conférences, avec TOUTES les composantes du CNRS utilisant massivement l'outil informatique, les industrielles, et ouverte sur l'international. Un peu comme "International Conference on High Energy Physics". Montrer des transparents en Français devant une cinquantaine d'étudiant en informatique, c'est pas de la com ...
[^] # Re: Pffff...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Quitte a parler du java et du C#, t'aurais pu évoquer le petit frère du C++, l'ObjectiveC, qui en ai la grande source d'inspiration.
[^] # Re: Pffff...
Posté par salvaire . Évalué à 3.
Bjarne Stroustrup at Bell Labs initially developed C++ during the early 1980's.
Exacte, mais ça fait un baille.
ObjectiveC est postérieur à C++, et fortement inspiré de smaltalk. Je n'en est pas parlé, car il est trop marginal. Et un peu boiteux: une couche oo très couteuse en cpu sur un dérivé de l'assembleur.
[^] # Re: Pffff...
Posté par Anonyme . Évalué à 2.
Chaque langage a ses avantages et ses inconvénients ; pour l'instant, le seul intérêt que j'ai trouvé au caml, c'est de permettre aux matheux/théoriciens d'écrire du code comme des maths, on croyant que voui madame ça marchera aussi bien que du C...
Et quand je vois les algos qu'utilisent certains mes profs (pas tous, hein), dès fois, je me pose des questions... Dire qu'un prof est compétent parce qu'il est prof, c'est typiquement français, l'expression "l'habit ne fait pas le moine" étant systématiquement ignorée dans notre pays.
Quand au C/C++, tu juges ça inommable, mais c'est eux qui composent 95% des gros programmes, et ce n'est pas pour rien.
[^] # Re: Pffff...
Posté par outs . Évalué à 2.
C'est de moins en moins vrai, pour les appli utilisateur desktop oui mais en entreprise ca a beaucoup évolué vers Java. Et cela évoluera encore, c lent mais ca bouge qd même
[^] # Re: Pffff...
Posté par salvaire . Évalué à 3.
[^] # Re: Pffff...
Posté par Sebastien . Évalué à 1.
C++ est inommable. La STL en particulier. C'est un plaisir pour touver la source d'un bug. Les infos du compilateur et de gdb sont absolument incompréhensible pour un humain.
Est-ce que ca ne met pas en lumiere les manques du compilo et du debugguer plutot que la STL ?
Parce qu'a mon avis, si tu te plains de la STL et des erreurs a la compilation que l'on peut rencontrer au cours de son utilisation... ne va _jamais_ voir du cote de Boost ;)
Expanser 2000 lignes de code à chaque usage, c'est du délire.
Je suppose que la encore c'est un manque provenant du compilateur et, supposition encore, ca devrait_etre/est resolu avec les headers precompiles.
En fait j'ai l'impression que ce que tu n'aimes pas dans le C++ ce sont les templates.
Serais-tu le fils cache a Rene Brun (HEP private joke inside) ?
Il me semble que C++0x devrait resoudre la plupart de tes griefs a l'encontre des templates[*].
Cela se resume a: "make templates a first class citizen".
[*] encore faut-il que les compilos suivent derriere, je le concede volontiers.
[^] # Re: Pffff...
Posté par outs . Évalué à 2.
Comme dans lisaac quoi ? :)
[^] # Re: Pffff...
Posté par Sebastien . Évalué à 2.
Mais bon, lisaac c'est combien de personnes ?
GCC c'est quand meme a base de vachement plus de monde [1] meme s'il faut bien sur retrancher toutes les personnes qui ne contribuent pas directement a G++.
[1] : http://gcc.gnu.org/onlinedocs/gcc/Contributors.html
[^] # Re: Pffff...
Posté par outs . Évalué à 3.
Et il se repose compltement sur gcc puisque il génére du C avec quelques extension de gcc.
Et quand je disais que c'était comme dans Lisaac, c'est parcque les templates sont réellement des citoyen de premiere classe et que le compilo est déjà efficace.
Et la syntaxe et la sémantique de C++ ne permettront jamais d'avoir un compilo qui génére du code aussi performant que celui de lisaac. t'aura beau mettre 400 personnes dans le projet g++ ca ira pas
Parceque justement un bon paquet d'optimisation automatique dans lisaac sont prévue pour être fait à la main en C++. Et que le langage est trop complexe
[^] # Re: Pffff...
Posté par pastro . Évalué à 4.
"Quand au C/C++, tu juges ça inommable, mais c'est eux qui composent 95% des gros programmes, et ce n'est pas pour rien."
je modifie 2/3 truc :
Quand à Windows, tu juges ça inommable, mais c'est eux qui equipe 95% des ordinateur, et ce n'est pas pour rien.
enfin j dit ca comme ca hein, faut pas y voir une attaque personelle
[^] # Re: Pffff...
Posté par Anonyme . Évalué à 2.
Quand un codeur choisit un langage pour son prochain programme, généralement, il choisit un poil plus en connaissance de cause.
Je pense par exemple que les développeurs d'apache ont de vraies raisons de prendre le C...
D'ailleurs, tu ne t'es jamais demandé pourquoi on ne voit jamais de vrais programmes utilisés en dehors de l'INRIA, écris en Caml ?
(oui, je sais, je connais mldonkey, le prog qui se fait virer des server p2p (parenthèse, je viens de me prendre 3 ans de prison et 300k euros d'amende...) parce qu'il envoit des requêtes en série comme un porc).
Code apache en caml, on a pas fini de rigoler...
[^] # Re: Pffff...
Posté par agmk . Évalué à 6.
>généralement, il choisit un poil plus en connaissance de cause.
Bof, moi j'aurais plutôt dit qu'il choisissait souvent le plus connu/répandu/éprouvé avec de nombreuses bibliothèques, mais pas forcément le plus adapté.
>Je pense par exemple que les développeurs d'apache ont de vraies
>raisons de prendre le C..
Parce qu'Erlang n'a été disponible sous licence libre qu'à partir de 1998 ?
>D'ailleurs, tu ne t'es jamais demandé pourquoi on ne voit jamais de
>vrais programmes utilisés en dehors de l'INRIA, écris en Caml ?
>(oui, je sais, je connais mldonkey, le prog qui se fait virer des server
>p2p (parenthèse, je viens de me prendre 3 ans de prison et 300k
>euros d'amende...) parce qu'il envoit des requêtes en série comme
>un porc).
Y a Unison aussi http://www.cis.upenn.edu/~bcpierce/unison/ Il me semble qu'il est assez utilisé, et de l'avis général assez "malin".
Dans les projets de recherche également (bien sur tu vas me dire que ça ne compte pas) : le fameux Coq, ASTRÉE...
Si OCaml est aussi médiocre que tu sembles l'inférer (ahah), je me demande pourquoi il est utilisé par Microsoft dans certains projets de recherche (appliquée, tu peux le remarquer) comme http://research.microsoft.com/terminator/ . La même entreprise qui a d'ailleurs conçu un clone^Wcousin sur .NET, F# : http://research.microsoft.com/fsharp/fsharp.aspx
>Code apache en caml, on a pas fini de rigoler...
Ça manque singulièrement d'arguments, donc en effet, je rigole. Je ne dis pas que tu peux tout faire en OCaml, ni que ce soit intéressant/utile, mais je doute de l'impossibilité de la tâche (sans prétendre qu'OCaml soit la panacée universelle).
Sinon, un petit aparté. La réaction de certaines personnes dès qu'on évoque (O)Caml ou Lisaac ("ah, c'est ça la recherche française ? Encore un langage inutile de l'INRIA, qui finira inconnu et mort") me choque, d'autant plus qu'il est rare de voir des projets aussi pratiques... Surtout quand ces réflexions viennent de gens qui seraient les premiers à hurler à la publication de travaux théoriques, exigeant des résultats immédiats qui ne sont de toute évidence pas le but de la recherche fondamentale scientifique.
[^] # Re: Pffff...
Posté par Yusei (Mastodon) . Évalué à 4.
C'est comme pour tout, il y a une minorité de gens qui maîtrisent plusieurs langages et qui sont capables de choisir le plus adapté à la tâche à effectuer, et puis il y a les autres, qui ont appris un ou deux langages et qui partent du principe que c'est la panacée.
[^] # Re: Pffff...
Posté par outs . Évalué à 3.
Lisaac (avec deux a) est beaucoup plus jeune que Ocaml.
Ca ne fait que très recement qu'il y a une version utilisable de Lisaac. En plus le développement a été réalisé par une seule personne (+un ingé pendant 2 ans).
On est au tout début pour Lisaac alors que Ocaml a déjà une longue histoire et est mature.
Perso je trouve que Caml a un bon succes ...pour un langage fonctionel, je ne pense pas qu'on puisse attendre beaucoup plus.
Alors que Lisaac est impératif objet et bien adapté pour faire des choses efficaces.
[^] # Re: Pffff...
Posté par Yusei (Mastodon) . Évalué à 3.
Mais OCaml est un langage qui permet de code à la fois en fonctionnel, en impératif et en objet (tout comme Common Lisp, d'ailleurs).
[^] # Re: Pffff...
Posté par outs . Évalué à 2.
D'un point de vue syntaxe et sémantique on marie des choses par la force. Et au final on se retrouve avec un langage tres tres gros (ML + impératif + classe + module). Perso j'aurai préféré qu'ils gardent la simplicité du langague d'origine, bon ce n'était pas forcement possible
C'est tout a fait l'opposé de la philosophie de lisaac. cf la grammaire http://isaacos.loria.fr/li_docs.html qui est très courte mais le langage reste quand même tres expressif.
Par exemple voici la définition de la boucle for. En fait c'est très proche d'un itérateur sur les entier tel que l'on aurait pus le définir en Caml.
to limit_up:SELF do blc:BLOCK <-
(
(self<=limit_up).if {
blc.value self;
(self+1).to limit_up do blc;
};
);
en caml (pas objet) ca aurait fait un truc du style
let rec for i limit_up blc=
if i<limit_up
then blc i;for (i+1) blc
else blc i
;;
du type int -> int -> (int -> ()) ->() (a vue de nez)
(mon caml est rouillé donc ca doit être faux, mais j'ai pas envie d'installer le compilo)
Je trouve que c'est un exemple très réussit d'intégration de concept plutot fonctionnel à l'intérieur d'un langage objet mais sans rajouter des construction plus ou moins étrangère dans la syntaxe de base. En fait ce qu'il ont eu besoin de rajouter c'est le type BLOCK correspondant a un suite d'instruction séquentielles. Comme ca on peut passer des blocs a itérer au la commande for (enfin to do : on peut définir plusieur mot clef).
[^] # Re: Pffff...
Posté par Vivi (site web personnel) . Évalué à 1.
[^] # Re: Pffff...
Posté par outs . Évalué à 2.
[^] # Re: Pffff...
Posté par Vivi (site web personnel) . Évalué à 2.
L'impératif et le fonctionel sont trés bien intégré, tant au niveau de la syntaxe que de la sémantique. C'est vraiment un aspect fondamental dans la conception des langages de la famille ML. D'ailleurs le logo des anciens langages caml était un symbole ying-yang avec un lambda dans une case et l'opérateur d'affectation en caml (:=) dans l'autre [1].
Pour la boucle, ça s'écrit comme ça:
for i = 0 to limit_up do f i done
Voilà il faut vraiment être d'une mauvaise foi noire pour prétendre que c'est moins naturel que la version utilisant une fonction récursive ou que le gloubiboulga syntaxique de lisaac.
[1] http://cristal.inria.fr/~weis/books-fra.html
[^] # Re: Pffff...
Posté par outs . Évalué à 3.
D'un autre coté je me souviens pas d'avoir été aussi agressif avec toi !
Cette syntaxe est effectivement tres naturelle.
Mais ceci n'est pas une definition du for mais une utilisation du for comme définie dans la grammaire de caml. Donc ca n'a rien a voir avec mon discours.
[^] # Re: Pffff...
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
for (i=1, 1000) {....}devient Idem pour whilewhile (test) {....}qui devient L'itérator while! est appellé sur aucun objet. En fait, on pourrait le mettre sur un objet booléen #BOOL, true ou false et considérer que cette notation n'est que du "syntatic sugar". Bref, tout un tas de structure devienne bien plus simple avec cette notion d'itérator.-
http://www.gnu.org/software/sather/docs-1.2/tutorial/iterato(...)
La contruction de l'itérator while! est très simple (les autres aussi), en voici un exemple d'implémentationwhile!(pred:BOOL) is -- Yields as long as 'pred' is true loop if pred then yield; else quit; end; end; end;Si on s'authorise l'opérateur ? : du C, cela raccourci carrément le codewhile!(pred:BOOL) is loop pred ? yield : quit; end; end;[^] # Re: Pffff...
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Lire pour la derniere URL
http://www.gnu.org/software/sather/docs-1.2/tutorial/iterators1034.html
[^] # Re: Pffff...
Posté par ɹǝıʌıʃO . Évalué à 10.
En ce qui me concerne, Lisaac prend tout son sens en tant que langage évolué pour la programmation système. Actuellement, je n'en connais pas. C'est un domaine qui nécessite de pouvoir mettre le clavier dans le cambouis plus que ne le permet normalement un langage de haut niveau : par exemple, alors qu'un ramasse-miettes est très pratique en temps normal, il est catastrophique pour écrire un pilote de périphérique. Il reste à voir comment ça se passe dans la pratique, ce qui signifie lire la doc, le code, etc. Du temps à passer dessus en perspective...
Puisque je passe par là, j'en profite pour quelques mises au point. J'ai failli prendre un troll sur la tête en arrivant : vous pourriez ranger vos affaires, quand même...
Sur l'INRIA : c'est un très grand institut, assez disparate. J'ai eu l'occasion de voir que les chercheurs étrangers ont parfois du mal à en comprendre l'organisation, ce qui leur donne un point commun avec les Français. Notamment, elle contient de grands théoriciens et... de grands praticiens. En gros, dans mon projet, lorsque les gens ne codent pas en C, c'est qu'ils codent en Fortran. Ou qu'ils ne codent pas.
Sur la valorisation de la recherche, comme dit plus haut, les développeurs d'Objective Caml, par exemple, s'en occupent en compagnie de quelques très grosses entreprises. Cela ne doit pas faire oublier que c'est avant tout un langage expérimental, donc qui change souvent et profondément. Les chercheurs ont besoin de tels langages. Pour expérimenter, pas pour vendre.
Sur les nouveaux langages et nouveaux paradigmes, je me demande bien ce qui peut pousser à croire qu'il n'y en a pas, aux États-Unis ou ailleurs. Pict, fondé sur le pi-calcul, est l'exemple qui me vient là tout de suite, mais c'en est juste un. Il en apparaît tout le temps de nouveaux, ce qui est une excellente chose pour l'informatique en général.
Sur les anciens, il faut comprendre qu'un langage donné, plus largement un paradigme donné a son champ d'application. Par exemple, la programmation fonctionnelle s'applique très bien au traitement de données structurées, en particulier les langages de programmation. Ce n'est pas pour rien que les développeurs de gcc se sont donné tant de mal pour implanter tree-ssa dans la version 4 : cette traduction du code impératif et spaghetteux en une forme fonctionnelle favorise l'analyse et la transformation du code, et particulièrement son optimisation. Il est tentant de croire qu'un langage donné va sauver le monde, mais c'est illusoire. Écrire un serveur http en Caml, par exemple, serait possible mais difficile, du moins avec de bonnes performances.
Ah tiens, les performances. En voilà un domaine où les idées reçues ont la vie dure, sans doute en grande partie en raison d'une méconnaissance des architectures actuelles. En écrivant des boucles et des affectations plutôt que des fonctions récursives et des liaisons, on a l'impression d'être plus proche de la machine : on envoie une instruction, on enregistre le résultat, on passe à la suivante. Sans le dire comme ça, les gens ont en tête une machine de von Neumann. C'était vrai, en gros, jusqu'à l'arrivée du Pentium. Maintenant, on est passé à l'autre modèle : celui du flot de données. Les instructions sont exécutées dans le désordre, en parallèle tant que c'est possible, et le facteur limitant est généralement la latence de la mémoire : dès qu'une donnée arrive, elle réveille les instructions qui l'attendaient. Ainsi, le modèle le mieux adapté est la description du calcul en fonction de la disponibilité des données, en séparant autant que possible le code en morceaux indépendants. C'est ce qu'on fait, entre autres, en programmation fonctionnelle, où une évaluation est possible quand on a les résultats d'autres évaluations dont elle dépend, et pas en programmation impérative où on impose un ordre sur l'exécution des lignes du code (généralement du haut vers le bas, mais on trouve de tout dans le folklore).
C'est pour ce genre de raisons que, paradoxalement, on arrive très bien à convaincre des matheux du bien-fondé de la programmation fonctionnelle, mais on a plus de mal avec des informaticiens (ou plutôt des "informatheux", comme dirait une de mes connaissances) - sauf, comme c'est le cas dans certains établissements, quand on commence par là avec des étudiants ne sachant pas programmer (entendu dans un amphi brestois, deuxième semestre de MIAS : "les boucles c'est nul, la récursivité c'est vachement plus facile"). Les étudiants arrivent avec des idées qui reposent sur leur expérience et leurs connaissances, et un nouveau paradigme les bouscule plutôt violemment. Or, on ne peut guère parler d'analyse de langages de programmation à des gens qui n'ont pas encore les bases de la compilation, ou d'architectures parallèles alors qu'ils ne sont même pas initiés aux architectures séquentielles. En gros, les principaux avantages du paradigme fonctionnel ne leur sont pas encore accessibles, et il faut bien reconnaître que la fonction factorielle, fût-elle récursive terminale, montre assez vite ses limites. Alors on trouve toutes sortes de réactions, d'opinions qui peuvent durer ou changer. En tous cas rien de bien inquiétant.
Bon je vous laisse, j'ai comme l'impression que ma propension à écrire des pavés a encore frappé. Je vais donc aller exécuter un script : logout ; shutdown ; sleep.
[^] # Re: Pffff...
Posté par outs . Évalué à 3.
Mais concernant le troll, je pense qu'au contraire la prochaine fois que j'écrit un journal je vais en inclure 2-3 dedans :) . Regarde, sans le troll sur Ocaml on aurait jamais eu ton commentaire ! Ici ca marche au troll...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.