Journal Language F# - Du microsoft, mais il y a un rapport avec le libre !

Posté par Anonyme le 14 septembre 2006 à 11:54.

Étiquettes : aucune

sept.

2006

Dans les labos de microsoft, on nous parle de ca :

http://research.microsoft.com/fsharp/fsharp.aspx

Et il ont joué beau jeu : ils avouent que oui c'est bien du pompé de ocaml, que oui on a reprit les supers concept d'inférence de type et le filtrage de motif.

Ce qui m'amuse dans l'histoire, c'est qu'a l'époque ou ocaml était l'étoile montante qui intéressait tout le monde, on discutait dans les couloirs qu'une superbe intégration avait été faite à VisualStudio mais que plus personne ne savait ou elle en était. Je me demande si F# n'en est pas le résultat final.

Bref, si cela peut pousser du monde a faire du fonctionnel bien comme il faut, il y a des chances que ça forme du monde et redonne de l'intérêt a ocamel (a qui la principale barrière est, je le rappelle, l'apprentissage - penser fonctionnel n'a rien a voir avec l'impératif, ni l'objet).

Enfin, si quelqu'un a des informations issues des coulisses de l'inria a ce sujet, je vous invite a les partager, parce que F# va jusqu'à être compatible avec le bytecode ocaml, ce qui titille mon petit doigt.

# lobbying

Posté par B16F4RV4RD1N le 14 septembre 2006 à 12:11. Évalué à 7.

voilà, on peut imaginer maintenant à quoi cela sert ce genre de truc :

http://www.recherche.gouv.fr/discours/2005/inriamicrosoft.ht(...)

ainsi les deniers publics de la France contribuent au développement du "framework" .NET de microsoft.

Ils auraient mieux fait de s'associer avec Novell / Red Hat / IBM / Mandriva et co pour promouvoir le développement de Ocaml sur les unix libres.

Du coup cela me donne envie d'en savoir un peu plus sur la programmation fonctionnelle :
http://fr.wikipedia.org/wiki/Programmation_fonctionnelle
mais je dois avouer que je ne comprends pas tout, déjà que j'ai du mal avec l'impératif...
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
- [^] # Re: lobbying
  
  Posté par TImaniac (site web personnel) le 14 septembre 2006 à 17:58. Évalué à 2.
  
  Pour info, le projet F# a été lancé avant ce labo commun entre Inria et MS (la version 1.0 date de janvier 2005). Le projet F# est un projet interne à MS visant à prouver que leur framework .NET peut supporter de nombreux langage, en l'occurence un langage de type fonctionnel (ML), au même titre qu'ils financent IronPython, une implémentation de Python visant à montrer que les langages dynamiques peuvent aussi s'y intégrer.
  Bref si tu veux mon avis, avec ou sans ce partenariat, F# existe.
- [^] # Re: lobbying
  
  Posté par pasBill pasGates le 14 septembre 2006 à 18:38. Évalué à 4.
  
  Ah oui bien sur, il vaut mieux que la France aide IBM plutot que MS, parce que MS c'est les vilains et IBM ce sont les beaux chevaliers blancs du libre, apres tout, F# c'est pas comme si on pourrait l'utiliser sur Mono par exemple alors que IBM ils ne font que du libre c'est bien connu.
  
  En fait MS pourrait faire des pots de Nutella 100% bio et avec des produits achetes a des prix decents aux producteurs de pays pauvres que certains y trouveraient toujours qqe chose a redire.
  - [^] # Re: lobbying
    
    Posté par lezardbreton le 14 septembre 2006 à 18:58. Évalué à 5.
    
    On ne récolte que ce que l'on sème tu sais... Mettre l'intégralité de .NET sous une licence compatible GPL, ça donnerait une image largement meilleure de MS ; Adopter les formats OpenDocument serait un minimum pour rétablir une certaine forme de décence sinon. Il y a plein de choses que MS pourrait faire si elle voulait éviter que certains la voit que comme le Mal absolu.
    - [^] # Re: lobbying
      
      Posté par pasBill pasGates le 14 septembre 2006 à 19:18. Évalué à 2.
      
      .NET est librement reimplementable, Mono en est la preuve.
      
      Remarque qu'IBM pourrait liberer un tas de code en OpenSource, arreter de mettre des patentes sur tout ce qui existe(devine qui detient le plus grand nombre de patentes sur cette petite planete...), ... mais bizarrement eux ce sont des heros parce que le libre leur convient dans 2-3 cas et qu'ils le poussent la tout en l'ignorant totalement partout ailleurs.
      - [^] # Re: lobbying
        
        Posté par mobutu le 14 septembre 2006 à 19:36. Évalué à 8.
        
        Je suis tout à fait d'accord sur le fait qu'IBM n'est absolument pas la panacée et encore moins le grand Chevalier du Libre. Cependant, IBM contribue pas mal en code source libre, ce qu'on ne peut absolument pas dire de Microsoft. Quand MS bossera sur un truc libre de la grosseur d'Eclipse/SWT, qu'ils nous fileront un système de fichier performant (JFS), qu'ils paieront des mecs pour bosser sur certaines parties du kernel linux, sur gcc, et j'en passe, ok, on mettra Microsoft au même niveau qu'IBM.
        
        Rien n'est tout blanc ni tout noir, c'est plein de nuances de gris. Ca n'empêche pas IBM d'être plus proche du gris clair et Microsoft du gris sombre. C'est normal de préférer s'allier avec IBM étant donné qu'ils ont déjà posé une certaine contribution. Qu'est-ce que Microsoft a fait pour le libre ? dis le moi.
        
        [^] # Re: lobbying
        
        Posté par pasBill pasGates le 14 septembre 2006 à 20:09. Évalué à 2.
        
        La question n'est pas de mettre MS au meme niveau qu'IBM, il est clair que c'est pas le cas vu qu'ils n'ont pas les memes interets(MS en fait 1%, IBM doit bien en faire 5-10% et ignore le libre les 90% restants). Mais se permettre de suggerer que l'etat subvientionne IBM plutot que MS sur un projet dont le resultat(F#) est totalement utilisable dans le monde du libre c'est du foutage de gueule et tient purement du delit de sale gueule.
      - [^] # Re: lobbying
        
        Posté par Cali_Mero le 14 septembre 2006 à 19:49. Évalué à 4.
        
        IBM s'est engagé publiquement à ne pas utiliser son portefeuille de brevets contre des projets libres. Ce sont donc des gentils.
        
        [^] # Re: lobbying
        
        Posté par pasBill pasGates le 14 septembre 2006 à 20:07. Évalué à 2.
        
        Non, ils se sont engages a le faire pour ~500 brevets, ils n'ont rien dit sur les autres.
        
        [^] # Re: lobbying
        
        Posté par fredix le 14 septembre 2006 à 22:09. Évalué à 2.
        
        IBM s'est engagés sur 500 brevets mais 0 chez MS, IBM reste donc les gentils.
        
        [^] # Re: lobbying
        
        Posté par pasBill pasGates le 15 septembre 2006 à 00:02. Évalué à 3.
        
        Perdu, MS a annonce il y a qqe jours qu'ils ne poursuivraient personne vis a vis d'un certain nombre(30 je crois) brevets sur les web services par exemple, et ce n'est pas le seul cas si je ne me trompe.
        
        [^] # Re: lobbying
        
        Posté par fredix le 15 septembre 2006 à 11:05. Évalué à 3.
        
        C'est toujours moins que 500. IBM reste toujours le gentil.
        
        [^] # Re: lobbying
        
        Posté par Nicolas Schoonbroodt le 15 septembre 2006 à 11:26. Évalué à 0.
        
        Foutaises.
        Imaginons que MS ait N brevets et IBM en ait N+2.
        MS dit : Sur nos N brevets, vous pouvez en utiliser N sans qu'on vous attaque. IBM répond : Vous pouvez en utiliser N+1. Avec ton raisonnement IBM est le gentil, et MS, pour être plus gentil, doit déposer plus de brevets.
        
        Réfléchit deux secondes.
        
        PS : ce que j'aime bien dans les débats avec pBpG c'est que les gens qui débattent avec lui donnent les batons pour se faire battre, alors que lui est très prudent et intervient souvent très justement. Enfin c'est mon avis.
        
        [^] # Re: lobbying
        
        Posté par B16F4RV4RD1N le 15 septembre 2006 à 12:26. Évalué à 2.
        
        sauf que justement en l'occurence Microsoft question d'avoir une floppée de brevets à la c** juste pour écraser les autres, ils se placent tout en haut de la barre (c'est eux qui ont breveté les bureaux virtuels comme on en a sous linux / unix depuis des années, et qu'ils n'ont même pas été foutu d'implémenter sur XP)
        Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
        
        [^] # Re: lobbying
        
        Posté par Nicolas Schoonbroodt le 15 septembre 2006 à 13:20. Évalué à -3.
        
        Reprennons un peu plus haut :
        カリメロ : IBM gentil ils n'utiliseront pas leurs brevets
        pBpG : Non, 500 seulement
        fredix : 500 contre 0, IBM gentil
        pBpG : MS 30
        fredix : 30 < 500 CQFD
        moi : N < N+1, et pourtant...
        toi : oui mais MS a plein de trucs à la con
        
        Alors sur la forme :
        1. tu es complètement hors du sujet de ce fil
        2. la prochaine fois, lit le fil auquel tu réponds
        et sur le fond :
        3. prouve que le pire brevet de IBM n'est pas pire que le pire de MS
        4. prouve qu'IBM n'a aucun brevet sur un truc qui existait déjà ailleurs avant
        
        Merci.
        
        [^] # Re: lobbying
        
        Posté par tene le 15 septembre 2006 à 16:49. Évalué à 2.
        
        Désolé les enfants, ce troll est breveté, je vous conseille d'arrêter immédiatement si vous voulez pas voir la police militaire de la garde nationale de la défence des gardes côté douanier débarqué... :p
        
        --> []
        
        [^] # Re: lobbying
        
        Posté par TImaniac (site web personnel) le 15 septembre 2006 à 13:03. Évalué à 2.
        
        Pour ceux que ca intéresse :
        http://www.microsoft.com/interop/osp/default.mspx
  - [^] # Re: lobbying
    
    Posté par PachaFonk le 15 septembre 2006 à 12:00. Évalué à 6.
    
    En fait MS pourrait faire des pots de Nutella 100% bio et avec des produits achetes a des prix decents aux producteurs de pays pauvres que certains y trouveraient toujours qqe chose a redire.
    
    Ton raisonnement est à mon avis un peu vrillé :
    
    Tu nous dis : Si MS était "lesgenti'" .. on continuerait à dire qu'ils sont Lémaichan... Ce qui prouve qu'ils sont "lesgenti" CQFD...
    
    Mémé, ortils, toussa...
# Commentaire supprimé

Posté par Anonyme le 14 septembre 2006 à 13:24. Évalué à 10.

Ce commentaire a été supprimé par l’équipe de modération.
# apprendre la programmation fonctionnelle

Posté par ɹǝıʌıʃO le 14 septembre 2006 à 20:33. Évalué à 2.

n'est pas plus difficile qu'apprendre la programmation impérative. Là où l'enseignement commence par l'approche fonctionnelle, les étudiants s'y habituent et trouvent bizarre les boucles et autres impérativeries lorsqu'elles sont introduites par la suite. L'université de Paris Sud a fait le choix inverse, ce qui va me conduire dès la semaine prochaine à expliquer que non, on n'a pas besoin d'une boucle while pour calculer ce que demande l'énoncé... Les autres approches (déclarative, réactive, etc.) ont du reste les mêmes problèmes d'image : elles ne sont pas plus difficiles, simplement moins répandues.
- [^] # Re: apprendre la programmation fonctionnelle
  
  Posté par Anonyme le 14 septembre 2006 à 21:47. Évalué à 6.
  
  Sans troll inutile, je trouve que l'on peut faire plus ou moins la même chose dans les langages fonctionnels (lisp, ocaml, F# donc), les langages objets (Java, ruby, je-ne-citerai-pas-C++-qui-fait-bondir-les-fanas-de-l'objet...), et les langages impératifs (C...); c'est avant tout une question de goût, goût qui dépend de la façon de penser du programmeur, de sa manière d'aborder les problèmes.
  
  Personnellement, je trouve les langages fonctionnels inutilisables, et même si je troll pas mal sur ce sujet, ça vient surtout du fait que je ne suis pas foutu de m'y faire. Certains diront que je suis un mauvais programmeur, mais rien à taper.
  
  Ce que je reproche *beaucoup* à l'université paris sud (eh oui, si je ne dis pas de bêtise, j'ai été l'un de vos élève l'an dernier ou il y a deux ans, mais je ne peux confirmer, ma mémoire des noms étant inexistante, par contre vous devez vous souvenir du mien), c'est le comportement radical des profs de caml qui essaient de nous convertir à l'ocaml en nous le présentant comme la solution miracle, le langage quasi parfait, qui écrase cette antiquité de langage C. Nous n'oublierons bien sûr pas que les profs de java font de même avec leur langage favoris (et un prof de maths m'a soutenu que les sondes martiennes utilisaient le java, ce qui avec des proco de - de 25 Mhz m'étonnerait énormément (http://www.cpushack.net/space-craft-cpu.html)).
  D'ailleurs j'ai remarqué qu'à chaque discussion sur ce sujet avec un prof, le résultat était le même: «tu dis ça parce que tu ne connais pas, tu verra plus tard».
  
  Bah je ne sais pas pour plus tard, mais en attendant, ce langage préhistorique qu'est le C m'auras permis de coder un window manager, et de travailler sur un server de jeu online multi-threadé (je ne compterai pas les milliers de lignes de code de bidouilles). Au passage, il aura aussi servis à coder Linux, BSD, Apache, GCC (qui compile également du C++, du java, du fortran...), xorg, une bonne part des jeux vidéos existants (domaine partagé avec le C++, et où les autres langages sont absents), et j'en passe.
  
  Comme quoi, pour une antiquité, je trouve qu'il vieillit bien (et contrairement à eclipse (java) ne prend pas des centaines de Mo de RAM à chaque lancement)
  - [^] # Re: apprendre la programmation fonctionnelle
    
    Posté par wahnby le 14 septembre 2006 à 22:15. Évalué à 2.
    
    De toute façon les 3/4 du code que l'on fait c'est pour transformer des données d"un format a un autre et pour afficher des fenetres alors bon le langage importe peu...
  - [^] # Re: apprendre la programmation fonctionnelle
    
    Posté par gasche le 14 septembre 2006 à 23:00. Évalué à 5.
    
    > Sans troll inutile, je trouve que l'on peut faire plus ou moins la
    > même chose dans les langages fonctionnels (lisp, ocaml, F#
    > donc), les langages objets (Java, ruby,
    > je-ne-citerai-pas-C++-qui-fait-bondir-les-fanas-de-l'objet...), et
    > les langages impératifs (C...); c'est avant tout une question de
    > goût, goût qui dépend de la façon de penser du programmeur,
    > de sa manière d'aborder les problèmes.
    
    Il me semble que l'on peut effectivement faire la même chose. La question c'est "comment" ?
    Un if/then/else en ocaml ça n'a rien à voir avec un if {} else {} en C. Le principe est totalement différent (d'un côté on a une valeur/expression, de l'autre on a plus ou moins des instructions/statement) et pourtant on peut faire les mêmes choses.
    C'est ce genre de différences qui est, à mon avis, vraiment fondamental. Effectivement, on a deux choses qui à la base sont faites pour correspondre à la même idée (programmer c'est à mon avis formuler sa pensée de manière à ce qu'un ordinateur la comprenne), et qui au final permettent de faire les mêmes choses (c'est pas le langage qui décide de ce qu'on fait, mais nous), mais la différence entre les deux reste importante/intéressante.
    
    C'est vrai pour OCaml, et j'imagine que c'est encore plus vrai pour les langages purement fonctionnels; en tout cas OCaml incorpore de nombreux traits impératifs (et je pense que c'est un avantage), mais qui sont intégrés dans le mécanisme global du langage, fonctionnel.
    
    C'est peut-être pour ça que les gens ont autant de mal avec les langages fonctionnels. Quand on met un codeur en C devant un cours de ocaml, pour ce que j'en ai observé, leur premier réflexe est de se dire "comment on fait une boucle for, comment on incrémente une variable, c'est quoi exactement la syntaxe de if/else, etc.". Forcément, si on retient "au lieu de if (prout) { foo(); } else { bar(); } on met if prout then foo() else bar()", on ne pourra pas comprendre pourquoi ça fait des trucs bizarres quand on met juste une valeur à la place des foo() et bar(), et on se dira "décidément, je n'arrive pas à comprendre les langages fonctionnels". Sans parler de la syntaxe de déclaration de fonction/valeurs qui a l'air complètement hallucinante.
    Dans ce cas là j'aurais tendance à dire que ce n'est ni la faute du langage, ni celle du codeur, mais celle de la méthode. Il faut arrêter de commencer un nouveau langage par ce qu'on connaît déjà, quitte à fouler au pieds la logique de base du langage si elle est en contradiction avec les autres langages que l'on connait : il faudrait débuter par ce qui est fondamental, et différent.
    - [^] # Re: apprendre la programmation fonctionnelle
      
      Posté par fmaz fmaz le 15 septembre 2006 à 10:28. Évalué à 1.
      
      D'un point de vue théorique, pour faire tout ce que du C fait en Ocaml, c'est simple: écrit un interpréteur C en Ocaml et appelle le c2ocaml. Après, au lieu de faire "foo monfichier", tu fais "c2ocaml foo.c monfichier". Tu as ainsi écrit un programme Ocaml (c2ocaml) qui fait tout ce que peut faire du C.
  - [^] # Re: apprendre la programmation fonctionnelle
    
    Posté par GTof le 15 septembre 2006 à 11:11. Évalué à 2.
    
    je trouve que l'on peut faire plus ou moins la même chose dans les langages fonctionnels [...], objets , [...] et impératifs (C...)
    
    On peut faire exactement les mêmes programmes dans tout ces langages, ils sont tous Turing complets. En revanche pour un problème donné, certains langages sont plus adaptés que d'autres.Pour le concours de programmation ICFPC [1], on devait programmer une machine virtuelle. Nombreux sont ceux qui ont commencé avec leur langage préféré puis se sont rabattu vers le C (où du moins ont réécris une grande partie en C pour l' interfacer avec leur langage). En effet les autres langages donnaient des machines virtuelle bien trop lentes.
    
    Le problème était clairement de nature impérative : gérer la mémoire à la main, interpréter les séquences d'instruction, etc ... En C, un malloc puis une gestion directe de la mémoire par des pointeur étaient parfait alors que dans les langages qui gèrent eux même la mémoire il fallait le simuler par une structure de donnée, d'où un surcoût. Le transtypage entre entiers et pointeurs était aussi très pratique en C. Bref pour CE problème le choix du C étaient judicieux.
    
    Notons aussi que pour certains langages, un bon nombre de leur bibliothèques viennent d'un interfaçage avec une bibliothèque en C comme GTK, SDL, etc ...
    
    Toutefois on ne code pas de machine virtuelle tous les jours et rares sont les programmes qui demandent de gérer à la main la mémoire autant qu'une VM. On a plus souvent besoin de structures de données (listes, arbres, etc ...) et là utiliser une implémantation de ses structures en C ne sera pas plus efficace qu'en fonctionnel, object, ...
    
    Utiliser des langages de haut niveau à de nombreux avantages : gestion automatique de la mémoire, typage, objects, exceptions, ordre supérieur, etc ... Ca évite des bugs, les programmes sont plus faciles à lire et à écrire. Certes c'est aussi faisable en C, mais simuler des des exception en C ne sera jamais aussi simple qu'un "try ... with ..." en OCaml et pas forcément plus efficace.
    
    Un serveur web ou un window manager n'ont pas de contraintes spécifiques sur la gestion mémoire, ils peuvent être codés aussi efficacement en haut niveau, la facilité en plus. Pour les jeux, l'approche de Slune est intéressante : le moteur graphique en C pour les besoin en performance et le reste du jeu en python pour les facilités du langage.
    
    [1] http://icfpcontest.org/
    - [^] # Re: apprendre la programmation fonctionnelle
      
      Posté par mobutu le 15 septembre 2006 à 11:58. Évalué à 2.
      
      "Pour les jeux, l'approche de Slune est intéressante : le moteur graphique en C pour les besoin en performance et le reste du jeu en python pour les facilités du langage."
      
      Pourquoi "l'approche de slune" ?
      Ca se fait depuis très longtemps. J'ai vu passer des jeux, entre autres, avec des bouts de lisp pour l'un, des bouts de lua pour l'autre, et même plus fort, des jeux avec un interpreteur crée exprès pour le jeu et un langage adapté. Bien sûr, selon les calculs mis en jeu, il reste quand même une belle partie de C/C++, et pas que pour le graphisme.
      
      Les jeux d'aventure sont les plus gros utilisateurs de script, et ça se comprends. (à part le graphisme, y'a rien qui fasse hurler une becanne dans un jeu d'aventure.. et encore, les graphismes dans la majorité des jeux d'aventure restent modestes.)
    - [^] # Re: apprendre la programmation fonctionnelle
      
      Posté par Mildred (site web personnel) le 15 septembre 2006 à 18:53. Évalué à 3.
      
      Le transtypage entre entiers et pointeurs était aussi très pratique en C.
      
      J'espère que tu ne veux pas dire un truc du genre int entier = (int) monpointeur car c'est MAL. Rien ne te garantit sizeof(int) == sizeof(void*)
  - [^] # Re: apprendre la programmation fonctionnelle
    
    Posté par ɹǝıʌıʃO le 15 septembre 2006 à 12:45. Évalué à 3.
    
    Je confirme, c'était effectivement l'année dernière.
    
    On peut faire la même chose avec tous ces langages, au moins en théorie, si l'on en croit Church et Turing. C'est une excellente raison pour choisir celui qui convient le mieux à la tâche à réaliser : C pour écrire un pilote de carte graphique, Fortran pour exploiter au mieux une grosse machine parallèle à mémoire partagée (le langage est horrible mais comme il est très utilisé par cette communauté, c'est pour lui qu'on a des compilateurs qui profitent pleinement du matériel), Prolog lorsque le problème s'exprime facilement sous forme déclarative, Lustre pour contrôler le système de sécurité d'un réacteur nucléaire, Caml pour le traitement de données structurées (langages, graphes, etc.). D'où l'intérêt d'enseigner plusieurs approches de la programmation. On n'est pas obligé d'aimer Caml, pas plus que Prolog ou Lustre, mais il faut au moins les connaître, sans quoi on manque quelque chose.
    
    Au-delà du langage, c'est l'approche qui compte vraiment. Un exemple en est gcc : comme il doit être capable de s'auto-compiler, il doit impérativement :) être écrit en C. Pourtant, la principale nouveauté de la version 4 est le passage à un nouveau modèle de représentation du code intermédiaire appelé tree-ssa. Ce modèle est directement issu de l'approche fonctionnelle de la programmation, où on s'intéresse à différentes transformations sur les données structurées. Pour gcc, les transformations utilisées servent à optimiser le code. C'est ce genre d'exemples qui mène à des boutades du style "C (ou C++, ou autre chose) est le langage fonctionnel du futur".
    
    C, un langage porté à bout de bras par le succès d'Unix, est un cas à part. Il bénéficie d'une gigantesque inertie : comme "tout" est écrit en C et que "tous les systèmes" ont un compilateur C, "tout le monde" apprend C et donc programme en C. Je ne sais plus qui remarquait que C n'est pas vraiment portable mais plutôt porté : on s'arrange pour que ça marche, puisqu'il le faut. À l'origine il était proche du matériel : on envoie au processeur une séquence d'instructions à exécuter, une par une, les données étant supposées disponibles. Très bien... pour une machine des années 1980. Maintenant nous sommes en 2006 et les machines ne fonctionnent plus du tout de cette manière, mais la base installée est tellement énorme et les progrès en traitement des langages tels que l'on adapte les compilateurs et on utilise des bibliothèques ou des services fournis par système (création et contrôle de processus) plutôt que réécrire les programmes. Personne ne sait si cette tendance va durer ou si d'autres langages vont s'imposer. Ce qui est sûr, c'est que chacun va pouvoir continuer de faire ce qui lui plaît. Pour ma part j'utilise généralement Caml quand j'ai quelque chose à écrire, mais ça ne m'empêche pas de garder de l'intérêt pour l'assembleur x86.
    - [^] # Commentaire supprimé
      
      Posté par Anonyme le 16 septembre 2006 à 20:14. Évalué à 2.
      
      Ce commentaire a été supprimé par l’équipe de modération.
      - [^] # Re: apprendre la programmation fonctionnelle
        
        Posté par Vivi (site web personnel) le 17 septembre 2006 à 18:08. Évalué à 2.
        
        J'ai du mal à voir en quoi faire des transformations sur des données structurées est l'apanage des langages fonctionnels.
        
        C'est pas exactement ça. Le principe des langages fonctionnels est de travailler avec des valeurs (non modifiables) et non avec des variables (au sens d'emplacement mémoire) modifiables. Le SSA impose qu'une variable ne soit écrite une seule fois, d'où la similarité avec les langages fonctionnels.
        
        cf. Andrew W. Appel, SSA is Functional Programming http://www.cs.princeton.edu/~appel/papers/ssafun.ps
        
        The SSA conversion algorithm is really...converting a C or Fortran procedure into a well-structured functional program with nested scope.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 19 septembre 2006 à 10:42. Évalué à 1.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Commentaire supprimé
        
        Posté par Anonyme le 19 septembre 2006 à 10:45. Évalué à 1.
        
        Ce commentaire a été supprimé par l’équipe de modération.
        
        [^] # Re: apprendre la programmation fonctionnelle
        
        Posté par Vivi (site web personnel) le 19 septembre 2006 à 12:15. Évalué à 1.
        
        L'article est un peu réducteur.
        
        Bof non je trouve pas. Le paragraphe que tu cites s'appelle "What functional programmers can learn from SSA" et s'adresse donc aux gens qui font du fonctionnel ; ça explique justement que les notations utilisées par la communauté SSA peuvent être utile pour les programmeurs de langage fonctionnels. Ce n'est donc pas un "détournement", c'est juste identifier un aspect du SSA qui peut être profitable dans un autre contexte. Ce n'est pas le propos de l'auteur de réduire le SSA à des flowcharts.
        
        Le SSA n'est pas plus qu'une représentation possible d'un programme
        oui et ? L'auteur ne dit pas le contraire.
        
        Enfin bon le but de l'article est de montrer l'équivalence entre ces deux notions: transformation SSA et programme fonctionnel. Pas que la technique SSA est issue du fonctionnel.
        Quand une même notion est découverte indépendemment par des approches différentes il y a souvent des choses intéressantes à tirer de "l'autre approche".
  - [^] # Re: apprendre la programmation fonctionnelle
    
    Posté par ɹǝıʌıʃO le 15 septembre 2006 à 16:20. Évalué à 2.
    
    J'oubliais... La NASA utilise des logiciels en Java pour piloter ses engins martiens à distance, mais ils fonctionnent au sol. Les robots eux-mêmes n'utilisent pas Java. Une source claire à ce sujet : http://www.sun.com/aboutsun/media/features/mars.html
- [^] # Re: apprendre la programmation fonctionnelle
  
  Posté par Mark Havel le 15 septembre 2006 à 10:58. Évalué à 0.
  
  Je serais très partisan de dire que si ces langages sont moins répandus, c'est que beaucoup de monde les trouve moins utilisables pour faire des applications classiques et communes telles qu'un système d'exploitation, un gestionnaire de fenêtre, une API graphique, un jeu... J'ai l'impression que ces langages servent surtout à résoudre plus facilement quelques problèmes particuliers d'algorithmie qu'à faire des applications finalisées.
  - [^] # Re: apprendre la programmation fonctionnelle
    
    Posté par Dr BG le 15 septembre 2006 à 11:48. Évalué à 4.
    
    Comme linux pour windows quoi... Si 95% des gens utilisent windows c'est bien parce qu'il est meilleur, et linux c'est nul, ça sert à rien, moi je fais tout avec windows et je le faisais avant linux !
  - [^] # Re: apprendre la programmation fonctionnelle
    
    Posté par ɹǝıʌıʃO le 15 septembre 2006 à 14:44. Évalué à 2.
    Je programme rarement un noyau de système, en revanche j'ai souvent besoin d'un petit programme très spécialisé qui doit être prêt rapidement, facile à lire et à modifier, et correct. Pour illustrer l'intérêt d'un langage comme Caml dans ce contexte, voyons ce que donne un micro-ls : afficher le contenu du répertoire courant dans l'ordre alphabétique.
```
open Unix

(* renvoie la liste des fichiers du répertoire donné *)
let rec lire_dir dir =
  try
    let d = readdir dir in
    d::lire_dir dir
  with End_of_file -> []

(* affiche une liste de chaînes de caractères *)
let rec afficher_dir = function
    h::t -> print_endline h; afficher_dir t
  | [] -> ()

(* programme principal *)
let _ =
  let dir = opendir (getcwd ()) in
  let l = lire_dir dir in
  afficher_dir (List.sort String.compare l);
  closedir dir
```
    Par rapport à C, on s'épargne la déclaration de nombreuses variables, on peut directement utiliser une liste que l'on trie d'un simple appel de fonction... Le résultat est un programme beaucoup plus court et qui contient moins de possibilités de bugs (que celui qui ne s'est jamais planté en bricolant à la main une liste en C me jette le premier transistor). Quand aux performances, il est fort possible que le passage à C permette de gagner quelques microsecondes, mais dans ce genre de cas ça ne change pas grand-chose.
    - [^] # Re: apprendre la programmation fonctionnelle
      
      Posté par Frédéric Péters (site web personnel) le 16 septembre 2006 à 14:50. Évalué à 1.
      
      Ce qui est dit plus haut, c'est d'utiliser un langage adapté au
      problème. Là, ton exemple, il m'apparait carrément plus adapté
      à un langage de script qu'à ocaml.
      
      import os
      for filename in sorted(os.listdir(os.getcwd())):
      print filename
      - [^] # Re: apprendre la programmation fonctionnelle
        
        Posté par ɹǝıʌıʃO le 16 septembre 2006 à 18:55. Évalué à 2.
        
        En effet, par extraordinaire, je donne une réponse différente à une question différente. Je présente mes plus plates excuses à ceux que ce concept peut choquer. Ici, la question concerne ceux qui trouvent que les langages fonctionnels ne sont pas adaptés pour écrire des programmes qui servent en pratique et l'exemple ne sert qu'à montrer qu'il n'y a pas de difficulté particulière. En pratique, si je veux afficher le contenu d'un répertoire, je fais comme tout le monde et j'utilise la commande ls de la coquille de service.
      - [^] # Re: apprendre la programmation fonctionnelle
        
        Posté par Vivi (site web personnel) le 17 septembre 2006 à 18:12. Évalué à 2.
        
        Oui bon après, ça dépend des détails. Olivier a une version assez élaborée mais dans ce cas précis ça peut s'écrire en une ligne aussi en caml:
        
        Array.map print_endline (Sys.readdir (Sys.getcwd ()))
        
        [^] # Re: apprendre la programmation fonctionnelle
        
        Posté par ɹǝıʌıʃO le 17 septembre 2006 à 22:30. Évalué à 1.
        
        presque
        let ls = Sys.readdir (Sys.getcwd ()) in Array.sort String.compare ls; Array.iter print_endline ls
        mais là, on a plutôt une illustration du côté "obscur" ;) de Caml, ce qui n'était pas mon but...
# Un peu déçu

Posté par gasche le 14 septembre 2006 à 21:27. Évalué à 3.

Je regarde F# depuis quelques temps, et j'ai quand même quelques critiques (j'espère un peu plus constructives que "bouh microsoft c'est nul").

En gros, je trouve ocaml vraiment bien, .NET je suis plutôt sceptique (mais j'essaie de ne pas avoir de préjugés), et j'ai tendance à trouver qu'il y a plus de trucs biens du Ocaml en moins que de truc supers du .NET en plus (forcément, eux je les ai pas vu).

Je me base sur le comparatif http://research.microsoft.com/fsharp/manual/ml-compat.aspx

Functors, OCaml-style objects, labels and optional arguments are not supported. Some common functors like Set.Make and Hashtbl.Make are simulated by returning records of functions.

Je trouve ça vraiment dommage : les labels c'est super cool (même si je ne sais pas encore m'en servir avec aisance) et le reste aussi.

Strings are Unicode and immutable.

Ça par contre, c'est plutôt intéressant.

Constraining a module by a signature may not make the values in the module less polymorphic.

Ça c'est super dommage.
Si on veut vraiment contraindre, il faut mettre les contraintes sur les arguments dans le .ml (let fun (arg: type) = ...)). C'est embêtant.

The C stub mechanisms to call C from OCaml are not supported. (F# has good alternatives that involve no coding in C at all.)

Paf.

(surtout qu'à vue de nez, le code pour passer de F# à C# n'est pas monstrueusement plus pratique/sympathique que celui pour passer de Ocaml au C. Mais n'ayant utilisé aucun des deux, je ne sais pas grand chose)

Pour résumer, je dirais qu'à mon avis le F# est vraiment diminué par rapport au OCaml, et que pour valoir vraiment le coup il faudra que les facilités apportées par .NET soient importantes.

Il faudrait aussi comparer l'efficacité d'un programme compilé avec le compilo Ocaml et un équivalent F# (Il doit bien y avoir un JIT ou quelque chose comme ça, non ?).
- [^] # Re: Un peu déçu
  
  Posté par Vivi (site web personnel) le 14 septembre 2006 à 23:33. Évalué à 1.
  
  Il faudrait aussi comparer l'efficacité d'un programme compilé avec le compilo Ocaml et un équivalent F# (Il doit bien y avoir un JIT ou quelque chose comme ça, non ?).
  
  Bah déjà tu peux comparer la vitesse d'exécution du bytecode OCaml et celle du programme F# sur le CLR.
  
  Enfin c'est intéressant comme comparatif, ça casse un peu le mythe du "on peut implémenter n'importe quel langage avec .NET".
  
  Sinon on peut citer OCamIL comme projet similaire: http://www.pps.jussieu.fr/~montela/ocamil/ modifier le compilo OCaml pour lui faire générer du bytecode pour .NET.
- [^] # Re: Un peu déçu
  
  Posté par TImaniac (site web personnel) le 15 septembre 2006 à 09:42. Évalué à 3.
  
  surtout qu'à vue de nez, le code pour passer de F# à C# n'est pas monstrueusement plus pratique/sympathique que celui pour passer de Ocaml au C.
  L'intérêt, c'est qu'un wrapper écrit en C# est portable (pas de code natif, rien à recompiler en changeant de plateforme).
  
  Sinon c'est clair que F# n'est pas aussi puissant que OCaml et aussi rapide. Alors quel est l'intérêt de F# ? La réponse est dans leur FAQ, que je vais essayer de traduire :
  Quels sont les objectifs de F# ?
  Une façon de voir les choses est de considérer que F# tente de résoudre les 7 problèmes majeurs décris dans la publication classique de Wadler : "Pourquoi personne n'utilise les langages fonctionnels ?" : Bibliothèques, Portabilité, Disponibilité, Facilité de déploiement, Outils, Entraînement et Popularité. Parmi ceux ci, F# résoud le problème des bibliothèques (en donnant accès immédiatement à des centaines de bibliothèques .NET de haute qualité ne nécessitant pas de wrapper), la portabilité (le bytecode .NET est portable, par exemple le projet Mono en donne une implémentation sur de nombreuses plateformes), déploiement (les assemblies .NET sont un excellent système de déploiement) et les outils (les outils pour .NET marchent également avec F#).Les autres problèmes sont en partis résolus par le fait que F# a un coeur conçu de la même manière que celui d'Ocaml, une implémentation de langage fonctionnel populaire pour lequel un bon nombre de document d'apprentissage sont disponibles, ainsi que pour la plateforme .NET où l'on trouve de nombreux document d'apprentissage sur le web.
  
  En gros F# n'apporte pas grand chose au langage proprement dit par rapport à OCaml (comme tu le soulignes, la grammaire est la même, en moins bien supporté), mais apporte de nombreux atouts sur tout l'environnement. Il est ainsi facile d'écrire un module d'un projet .NET en F# sans que les problèmes techniques d'intégration habituels entre environnement différents apparaissent.
  - [^] # Et si on partagait?
    
    Posté par cryx le 26 septembre 2006 à 03:14. Évalué à 0.
    
    pour répondre plus haut: "Quand MS bossera sur un truc libre de la grosseur d'Eclipse/SWT, qu'ils nous fileront un système de fichier performant (JFS), qu'ils paieront des mecs pour bosser sur certaines parties du kernel linux, sur gcc, et j'en passe, ok, on mettra Microsoft au même niveau qu'IBM."
    
    Je n'aime pas la philsophie actuelle de MS.
    Oui il commence à partager mais ils restent dans leurs coins, n'ayant aucun scrupule à réécrire des softs déjà existants au lieu d'aider les développeurs.
    Pour anecdote:MS a "pondu" Sandcastle, tool permettant de créer du help compilé (versions: 1.0 et 2.0) sous Windows sur base d'un XML généré avec VS.net...
    Sandcastle est annoncé comme le grand remplaçant de NDoc.
    Bref, NDoc c'est fini car le développeur en a eu marre de perdre son temps à développer en solo...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.