Le Fortran

• [^]Re: Le Fortran

  Posté par Troy McClure (page perso, ) le 23/03/2007 à 10:09. (lien). Évalué à 6.

  Et puis c'est quand même un des rares langages ou les espaces ne sont pas significatifs, ce qui fait donc que:
  
  DO I=1.42 est une assignation à la variable "DOI"
  alors que
  DOI=1,42 est une boucle sur I
  
  c'est pas génial ça ?
  
  Au fait, y'a des affreux qui veulent faire mourrir le fortran:
  http://www.fortranstatement.com/cgi-bin/petition.pl

  • [^]Re: Le Fortran

    Posté par Pierre Jarillon (page perso, ) le 23/03/2007 à 13:36. (lien). Évalué à 10.

    J'ai utilisé le Fortran en 1970, On remplissait des feuilles en écrivant des caractères en majuscules dans des cases, des "perforatrices IBM" (cétait un métier) perforaient les cartes, on les donnait le soir au centre informatique et on les retrouvait le lendemain posées sur le listing plus ou mois épais : c'était le résultat ou le core dump de la machine en hexadécimal.
    Je n'arrive plus à relire ce fortan qui est de la programmation spaghetti et qui a forgé la légende du fortran.
    
    J'ai ensuite utilisé le fortran 4x puis 77 de 1979 à 2002.Il est devenu un langage fort pratique, très commode pour gérer les chaines de caractères et surtout, il a inclus l'instruction : "implicit none".
    Je me suis aperçu que l'on gagnait toujours du temps avec "implicit none" dès que l'on avait un programme de plus de 100 lignes. Les types implicites du Fortran basés sur le premier caractère de la variable : [i..n]=integer, [c]=complex, [d]=double précision ont conduit à la perte d'une sonde spatiale à cause de ceci :
    
          DO 100 I=1,1000
          ......
    100 CONTINUE
    
    Ce qui signifie, faire 1000 fois la boucle jusqu'à l'étiquette 100.
    Il se trouve que la virgule avait été remplacée par un point et le compilateur a compris :
    DO100I=1.1000
    Il a créé la variable double précision do100i et lui a attribué la valeur 1.1
    Après cette affaire la NASA a interdit les déclarations implicites et a lancé un concours qui a abouti à ADA.

    • [^]Re: Le Fortran

      Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 24/03/2007 à 09:31. (lien). Évalué à 2.

      On est tous bien d'accord, c'est bien loin des langages plus haut niveau et plus beaux que l'on peut manipuler de nos jours, c'était le bon vieux temps mais aujourd'hui on peut se reposer sur une syntaxe plus claire et des paradigmes intéressants (OCaml, Ruby, y'a plein de beaux langages sympatiques de nos jours...).
      
      Pour moi John, il a fait un truc bien, c'est la notation BNF, après le Fortran, vite vite tournons la page :-p

      • [^]Re: Le Fortran

        Posté par Sytoka Modon (page perso, ) le 24/03/2007 à 14:01. (lien). Évalué à 9.

        > mais aujourd'hui on peut se reposer sur une syntaxe plus claire et
        > des paradigmes intéressants
        
        Tu as lu du Fortran 95 ? Si tu sais lire de l'Ada ou du Pascal, le Fortran est quasiment pareil. Pas d'accolade {} ni de parenthèses () à tour de bras, des beaux "begin ... end".
        
        Ensuite, j'aime beaucoup les langages de scripts mais on ne peut pas comparer le Fortran avec le Ruby. Cela n'a rien à voir. En Fortran, tout a été fait pour programmer en adressage statique, tous les passages de paramêtres se font par adresse, les fonctions ne sont pas récursive par défauts. Ce n'est pas pour se faire plaisir, c'est une question de performance et de parallèlisme.
        
        OCaml est très bien mais un non informaticien arrive-t-il a programmer dans ce langage ? Et quelles sont les performances dOCaml dans le calcul parallèle ?
        
        Fortran est un langage spécialisé dans le calcul scientifique. Si il était si mauvais que cela, il aurait été remplacé depuis longtemps. Or c'est un des rares langages de la préhistoire qui soit encore là et qui a su évoluer en profondeur.
        
        J'ai été il y a quelques temps à un séminaire sur la performance, notament sur la problématique de la machine pétaflop que les constructeurs envisagent pour peu.
        
        Tu fait un programme et tu le fait tourner sur 10 coeurs et tu regarde sa performance par rapport à un coeur. Tu fait de même avec 100 ou 1000 coeurs. D'après le conférencier (et mes souvenirs), les programmes utilisant OpenMP tiennent bien entre 10 et 100 coeurs. Entre 100 et 1000 coeurs, les programmes qui tiennent la charge utilisent généralement MPI. Très peu de programme dépasse les 1000 coeurs sans s'effrondrer. Or il est envisagé bien plus de 1000 coeurs pour une machine pétaflop.
        
        Les constructeurs travaillent énormément pour arriver à faire une machine pétaflop mais, pour qu'une application puisse tirer le maximum d'une telle machine, il faut d'après changer notre manière de coder.
        
        Si tu regardes du coté de Fortran 2008, il y a justement cette problèmatique du calcul matriciel parallèle au coeur des extensions.
        
        Je veux bien, Ruby s'est très bien mais c'est pas avec Ruby que tu calcule la météo du lendemain, ni que tu fait une prédiction pour les 50 ans qui viennent du réchauffement climatique, ou que tu calcule la propagation des ondes sismiques dans un bassin aluvionnaire entouré de montages (cas intéressant car il y a des phénoménes d'amplification du à la géométrie et à la composition des sols).
        
        Bref, il est idiot de vouloir programmer un site web dynamique en Fortran. De même, ne demandons pas aux langages de script de faire tourner un calcul sur une machine Itanium à 4096 coeur.
        
        Je trouve qu'il y a de plus en plus d'offre de compilateur Fortran 90 (95) sur le marché. Ma prédiction est que vu les problèmes écologiques à venir, le Fortran n'est pas près de prendre sa retraite.

        • [^]Re: Le Fortran

          Posté par Michel Galle () le 24/03/2007 à 15:21. (lien). Évalué à 2.

          monsieur Sytoka Modon, Merci.
          
          il est sain de rappeler que Fortran ne disparaît _pas_ et qu'il n'existe PAS qu'une seule informatique.

        • [^]Re: Le Fortran

          Posté par Troy McClure (page perso, ) le 24/03/2007 à 17:35. (lien). Évalué à 4.

          > Fortran est un langage spécialisé dans le calcul scientifique. Si il était si mauvais que cela, il aurait été remplacé depuis longtemps.
          
          Mouais mouais un peu comme windows, ou Matlab pour rester dans le domaine du calcul scientifique (en voilà un autre langage bien batard que celui de matlab)
          
          A mon sens Fortran est surtout resté parce que ses utilisateurs ne sont pas informaticiens (et ils ne se rendent donc pas compte de l'espèce d'horreur qu'est le mix de f77 et de f90 que pratiquent aujourd'hui la plupart d'entre eux), et qu'ils n'ont pas envie d'apprendre un autre langage. C'est aussi le seul langage qui soit "dédié" au calcul scientifique. Pourtant il n'a pas grand chose à proposer à part un support natif des tableaux multidimensionnels, et le fait que le code compilé par un compilo f77 est vraiment rapide (pour le f90 c'est déjà beaucoup moins clair)
          
          Le f90 est au f77 ce que le c++ est au c ( et même un peu plus). En gros il n'a rien à voir, mis à part qu'on peut encore coller des bouts de f77 au milieu d'un code f90 et ça compilera. Je trouve qu'ils auraient du carrement faire un nouveau langage plutot que cet espèce de frankenstein qui ne gère pas les lignes de plus de 132 caractères (c'était 80 en f77 mais les visionnaires concepteurs de f90 ont décidé que 132 should be enough for everyone. Alors il y des compilateurs qui arrêtent de lire après le 132ème car. Que du bonheur à débugger). f90 a aussi gardé l'espère d'ignominie qu'est le système d'i/o de f77, qui était surement très adapté au temps des cartes perforées, mais le monde a changé depuis. On a aussi inventé la ligne de commande entre temps, mais c'est dommage f90 ne permet pas de lire les arguments de la ligne de commande. Je ne m'étendrais pas sur le support des chaines de caractères, qui est éminement rustique et peu orthodoxe. Petit détail esthétique: l'usage du '%' pour accèder aux membres d'une structures, là où tous les autres langages utilise un '.'
          
          Tout ça pour dire que je trouve que le cas du fortran est desespéré. Que la bête meure! et vive Fortress!

          • [^]Re: Le Fortran

            Posté par Loïc d'Anterroches (page perso, ) le 24/03/2007 à 18:37. (lien). Évalué à 2.

            j'ai eu la chance de participer à un workshop pour du calcul scientifique avec des experts de Sun. Résultat des courses, si vous voulez vraiment tirer le maximum des serveurs avec 72 procs, mangez du Fortran.
            
            Bien propre, les compilateurs de Sun font des merveilles pour paraleliser le tout. Et pour répondre à la critique sur les problèmes d'I/O etc... on interface notre code avec du Python...

          • [^]Re: Le Fortran

            Posté par Sytoka Modon (page perso, ) le 25/03/2007 à 00:29. (lien). Évalué à 4.

            Tu critiques le Fortran mais tu dis aussi qu'il est irremplacable...
            
            Pour les entrées sorties, cela ne m'a jamais géné. Ce n'est pas du printf à la C mais les printf du C sont parait-il soumis au buffer overflow...
            
            Au niveau de la ligne de commande, tu peux avoir les arguments depuis tous les compilateurs que j'ai croisé. Certes, cela n'était pas normalisé . Justement, ce manque est résolu avec le F2003. A ce sujet là, Java est contre la ligne de commande...
            
            Quand au %, certes c'est pas très beau mais il ne pouvait pas prendre le . car celui-ci est déjà pris pour les opérateurs. En effet, tu peux définir autant d'opérateur que tu veux en fortran avec des petits noms, par exemple un opérateur 'scalar' qui serait le prodiut scalaire de deux vecteurs ou de deux tenseurs. En gros un opérateur qui te donne le résulta d'une mesure sur un objet. Tu l'utilise ensuite en écrivant :
            
            m = X .scalar. Y
            
            Et lorsque tu programme un code de cacul avec plein de formule, c'est hyper pratique de coder ainsi. Dans les autres langages, je ne connais pas d'équivalent aussi pratique et parlant. Je ne parle pas de la surcharge de l'operateur * qui représente un produit mais lequel ?
            
            Bref, surcharger * rend souvent le code illisible, il est bien plus pratique de définir ses propres opérateurs.
            
            Tiens un truc bien, en Fortran 90, pas de ses fichiers d'en tête à la Ada ou tu dupliques tout ou à la C qui fait des inclusions récusives qu'il faut bidouiller avec des #define... Non, c'est le complateur qui en analysant ton code te génère ton fichier d'en tête !
            
            Comme quoi, la diversité n'est pas plus mal.

            • [^]Re: Le Fortran

              Posté par let antibarbie = xp <- xp - 1 (page perso, ) le 21/04/2007 à 20:18. (lien). Évalué à 1.

              En ocaml on peut déclarer des opérateurs infixes de la même façon.
              OCaml, l'avenir du fortran ? :-) non non je ne trollerai pas là dessus,
              mais ça méritait d'être signalé.

  • [^]Re: Le Fortran

    Posté par l0stman () le 23/03/2007 à 19:48. (lien). Évalué à 2.

    Etant donné que les affreux en question ont écrit leur site en Perl, on peut soupçonner quelques fanatiques de ce language. Ceci dit à propos de Fortran, je citerais quelqu'un qui avait une avie très nette sur la question:
    
    

    
    FORTRAN, the infantile disorder, by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use. —Edsger Dijkstra, circa 1970.
    

    
    
    *tousse* *tousse*

    --
    ``Whatever it is, I'm against it'' -- Marx Groucho

    • [^]Re: Le Fortran

      Posté par Sytoka Modon (page perso, ) le 23/03/2007 à 20:28. (lien). Évalué à 7.

      Le Fortran 90 a changé beaucoup de chose et le Fortran 2003 amène la programmation objet, 8 ans après Ada95 mais plus de 40 ans après sa création. Pas si mal pour un langage qui a vu un nombre impressionant de cadavre sur sa route.
      
      J'avais remarqué qu'il y avait des personnes qui étaient à la fois dans le comité Ada et dans celui de Fortran. Cela n'empêche pas Fortran de ne pas suivre bêtement Ada mais d'avoir sa propre trace. Par exemple, les pointeurs introduits en Fortran 90 sont petits à petits éliminés au profit d'objet "allocatable" bien plus facile à gérer pour un compilateur en terme de ressource.
      
      Je te conseille d'aller voir du coté de la norme Fortran 2003 pour te rendre compte par toi même. Si tu veux développer un client de courriel ou un traitement de texte, passe cependant ton chemin. Le Fortran est clairement orienté calcul scientifique et malgré mes réticences au début, il faut avouer qu'il remplit pas mal son rôle.
      
      http://en.wikipedia.org/wiki/Fortran
      
      Un présentation faites par l'IDRIS
      
      http://www.idris.fr/data/cours/lang/fortran/f2003/Fortran_20(...)

      • [^]Re: Le Fortran

        Posté par lasher () le 23/03/2007 à 23:54. (lien). Évalué à 2.

        Mmmmh, franchement, autant je vois beaucoup de code F77 et un peu de F90 autour de moi, autant F2003 m'a l'air un chouilla mort-né.

        • [^]Re: Le Fortran

          Posté par benoar (Jabber id, ) le 24/03/2007 à 02:29. (lien). Évalué à 4.

          Un peu comme COBOL 2002 ? ...
          http://en.wikipedia.org/wiki/Cobol#COBOL_2002_and_object-ori(...)

        • [^]Re: Le Fortran

          Posté par med (page perso, ) le 24/03/2007 à 08:42. (lien). Évalué à 3.

          En quoi il serait mort-né ? Il faut pas mal de temps pour intégrer les améliorations dans le compilateur, ça ne se fait pas du jour au lendemain. Pour autant que je me souvienne il y a quelques fonctionnalités de fortran 2003 qui sont en cours d'intégration dans gfortran. Peut-être que le google SoC permettra d'en apporter un peu plus. Cependant ce serait bien que gfortran implémente complètement fortran 2003 avant la sortie de fortran 2008.

        • [^]Re: Le Fortran

          Posté par Sytoka Modon (page perso, ) le 24/03/2007 à 13:23. (lien). Évalué à 2.

          En pratique, on code en F95 et peu en F90. On dit F90 car c'est le gros changement.
          
          Le F2003 permet de faire de la programmation objet simple. Pour les projets auquels j'ai participé, c'est suffisant et cela permet d'éviter d'émuler l'objet.
          
          Il faut bien voir que programmer en objet n'est pas toujours bon pour la performance. La programmation objet a un peu trop tendance a crée trop d'objet intermédiaire avec de l'allocation et de la dé-allocation de la mémoire.
          
          Encore une fois, le Fortran est un langage spécialisé conçu pour la performance, pas pour le "Desktop".

          • [^]Re: Le Fortran

            Posté par lasher () le 25/03/2007 à 09:42. (lien). Évalué à 1.

            On est bien d'accord. Lorsqu'on parle de programmation pour le HPC, rajouter tout un tas de machins à Fortran n'est pas très intéressant. Cela dit, FORTRAN (77|90), malgré toutes les qualités qu'on peut bien vouloir lui trouver, c'est moche. Même le C fait figure de langage moderne à côté.

            • [^]Re: Le Fortran

              Posté par Sytoka Modon (page perso, ) le 25/03/2007 à 10:57. (lien). Évalué à 3.

              C'est sur que la gestion des pointeurs du C est génial, notament celle des pointeurs de pointeurs ;-)
              
              Soyons honnête, le Fortran 95 et maintenant 2003 sont bien plus lisible que du C. Evidement, je ne parle pas pour une personne qui fait du C toute la journée !
              
              Regardes un peu le pdf que propose l'IDRIS sur le Fortran 2003 et tu verras qu'il n'a pas à rougir du C pour son objectif à lui, c'est à dire le calcul intensif.

        • [^]Re: Le Fortran

          Posté par Michel Galle () le 24/03/2007 à 15:24. (lien). Évalué à 1.

          quand on travaille en fortran, on est pas là pour adopter les dernières nouveautés
          à la mode par plaisir.
          
          
          il faut du temps pour que les outils de calculs, les projets et les gens intègrent les évolutions.
          
          mais je confirme que fortran est toujours d'actualité, qu'il est dans le milieu industriel et académique et non on ne fait pas de migration pour s'en débarrasser, j'ai encore pléthore de progiciels conçus et pensés pour travailler avec fortran, et ils évoluent régulièrement.

          • [^]Re: Le Fortran

            Posté par lasher () le 25/03/2007 à 09:47. (lien). Évalué à 1.

            Ah ça, c'est bien vrai. Lorsqu'on code en FORTRAN, on a tellement peur de retoucher à certains codes (BLAS, LaPACK, etc) qu'on laisse souvent les vieilles implémentations telles quelles, alors qu'elles ne sont pas forcément programmées dans une optique parallèle.
            
            Et je ne parle pas du combo magique FORTRAN + MPI, avec des gens qui utilisent les I/O asynchrones pour aller plus vite (ce qui est bien) mais en pratique font des MPI_send(...) ; MPI_wait(...); (pas bien, gérer les I/O async en synchrone, faut le faire quand même).
            
            Et justement, FORTRAN permet peut-être la performance, mais dans le cadre du HPC, si t'es pas foutu d'optimiser ton code correctement (et c'est le problème de beaucoup de scientifiques non informaticien, et oui c'est normal, puisqu'ils ne sont pas infoteux), tu perds tellement de temps lors de l'exécution qu'on se demande bien à quoi peuvent servir tous ces mécanismes faits pour rendre le calcul efficace.

            • [^]Re: Le Fortran

              Posté par Sytoka Modon (page perso, ) le 25/03/2007 à 11:13. (lien). Évalué à 2.

              Je suis d'accord, Fortran n'est pas parfait pour faire du code parallèle mais la concurrence ?
              
              Aujourd'hui, en Fortran, on s'en sort plus ou moins bien et c'est exactement ce que j'ai dis dasn un post. Pour pouvoir profiter de la future machine pétaflop, il faut modifier notre manière de programmer, la machine ne peux pas complètement s'adapter malleureusement à notre manière actuelle.
              
              Le langage que j'ai beaucoup aimé était Sather avec une version pSather. L'objetif de ce langage était clairement de faire un langage objet à la Effeil mais très orienté calcul intensif et parallèle. Malheureusement, il est mort.
              
              Pour ce qui est des bibliothèques de base comme BLAS ou Lapack, cela évolue, lentement mais surement. Je connais des gens qui ont leur propres versions moins optimisé mais qui ne veulent pas en changer car leur bibliothèque est validé depuis des années. Il faut dire que tu veux éliminer toutes erreurs possibles lorsque tu lances un calcul qui dure plusieurs semaines sur une machine SMP. Un des problèmes ici est que les chercheurs manquent de ressources de calculs (et aussi de bras) et qu'ils ne peuvent pas par exemple se permettent d'utiliser 40 coeurs pendant 3 semaines de la machine NEC SX8 de l'IDRIS pour rien.
              
              Il faut bien voir que ce ne sont toujours pas des chercheurs en informatique qui font du Fortran mais plutôt des chercheurs du domaine des études faites. Les contrats de recherche qu'ils obtiennent ne sont pas destinés à financer l'amélioration de BLAS par exemple.

              • [^]Re: Le Fortran

                Posté par lasher () le 26/03/2007 à 21:09. (lien). Évalué à 2.

                Je suis d'accord, Fortran n'est pas parfait pour faire du code parallèle mais la concurrence ?
                
                Ben justement. La concurrence n'est pas meilleure du point de vue langage. Du point de vue des bibliothèques qui vont bien, le C est muni depuis un bout de temps de machins types threads, de bibliothèques à deux niveaux pour les threads, etc.
                
                
                Pour ce qui est des bibliothèques de base comme BLAS ou Lapack, cela évolue, lentement mais surement.
                Mouais. Pour ne prendre qu'une bibliothèque ultra-utilisée, à savoir hypre, peut-être bien que les préconditionneurs sont vraiment géniaux, mais en ce qui concerne les BLAS, ils ont fait un simple f2c d'une implémentation « libre » qui date de ... 1977. Ça fait peur, vraiment.
                
                Pour ce qui est de l'argument des bibliothèques moins bonnes mais qui au moins n'ont pas de bugs, pour ne reprendre que des briques de base (oui, encore les BLAS ;-)), on se retrouve à la fin avec des gens qui ont des algorithmes qui ne passent pas du tout à l'échelle (parce que passer sur 16 ou 32 processeurs n'assure pas du tout que ça pourra passer au-delà), et qui vont être tout content de quadrupler le prix de leur calculateur, en doublant les processeurs ainsi que le système de refroidissement qui va avec, pour finalement obtenir une accélération de ... deux (je parle de machines qui sont déjà équipées d'au moins 16 ou 32 processeurs, justement).
                
                Il faut bien voir que ce ne sont toujours pas des chercheurs en informatique qui font du Fortran mais plutôt des chercheurs du domaine des études faites. Les contrats de recherche qu'ils obtiennent ne sont pas destinés à financer l'amélioration de BLAS par exemple.
                
                Et c'est bien ce que je leur reproche -- silencieusement, parce que le sismologue qui explique qu'il n'est pas informaticien, mais qu'il a codé tout son machin de maillage adaptatif en FORTRAN/MPI a quand même tout mon respect, optimisation ou pas optimisation.
                
                Je sais bien qu'il s'agit de scientifiques autres que des infoteux qui codent tout ça (ce qui explique aussi pourquoi ils font toujours du FORTRAN). N'empêche : embaucher quelqu'un (un ingé de recherche) pour reprendre les bibliothèques fondamentales et les optimiser pour des architectures d'aujourd'hui (parce que le NUMA, avec l'hypertransport et le futur CSI d'Intel, c'est vraiment aujourd'hui) ne serait pas du luxe. D'ailleurs, certains labos l'ont compris, et commencent à prendre des gens compétents dans le domaine de l'optimisation.

                • [^]Re: Le Fortran

                  Posté par Sytoka Modon (page perso, ) le 26/03/2007 à 21:32. (lien). Évalué à 2.

                  Je connais aussi un code utilisé dans le génie-civil qui a entièrement été recodé en C++ par une personne embauchée en CDD par l'INRIA je crois. Depuis, cette personne est partis et le code doit continuer à vivre... sans informaticien à plein temps.
                  
                  Pour avoir fait du C++, c'est facile et rapide de transformer un code bien écrit en une soupe horrible et peu performante...
                  
                  Il est clair qu'il manque d'ingénieur de développement (et aussi d'ingénieur système pour pas que le dev fasse du système) dans les laboratoires non liés à l'informatique directement et hors grand équipement de type physique (l'IN2P3 a quand même des moyens que les autres n'ont pas).
                  
                  Pour être positif, il y a quand même des bibliothèques qui bougent, par exemple, en prenant la bonne version de la fftw, on a facilement un facteur 2 à 3 sur un code, et cela, qu'on soit en Fortran ou en C ;-)
                  
                  Par contre, ce qui est pénible en Fortran, c'est que le mapping des fonctions dans les .o n'est pas normalisé donc il faut se tapper de recompiler les bibliothèques pour chaque version de compilateur. Lorsqu'on fait un nouveau langage, cela devrait être dans les spécifications de base.

• [^]Re: Le Fortran

  Posté par med (page perso, ) le 23/03/2007 à 13:35. (lien). Évalué à 4.

  Personnellement je trouve le fortan 77 insupportable et bourré d'archaïsmes. En revanche la fortan 90 a apporté une véritable révolution. Écriture vectorielle, liberté de mise en forme du code source, pointeurs, objets, etc. Je connais un certain nombre de numériciens dont la plupart utilisent fortran, mais aucun n'utilise encore le fortran 77.

  • [^]Re: Le Fortran

    Posté par Sytoka Modon (page perso, ) le 23/03/2007 à 21:26. (lien). Évalué à 3.

    Je suis d'accord avec toi, le F77, c'est du passé aujourd'hui. D'ailleurs cela à plus de trente ans ! Tous les codes que je vois développé aujourd'hui sont en F90 minimum, en pratique, assez souvent du F98.
    
    Je vais me faire incendier, mais le C, c'est un peu pareil, insupportable et bourré d'archaïsmes ;-) D'ailleurs, comparativement au Fortran, le C a vachement evolué !

    • [^]Re: Le Fortran

      Posté par Michel Galle () le 24/03/2007 à 15:26. (lien). Évalué à 3.

      aucune raison d'être incendié
      
      le C n'est pas l'alpha et l'omega de la programmation (et encore heureux) même si je vous recommande de l'apprendre, hein (je dis ca aux petits jeunes qui lisent linuxfr :) )

• [^]Re: Le Fortran

  Posté par Matthieu Lemerre () le 23/03/2007 à 19:12. (lien). Évalué à 3.

  Surtout, fortran c'est je crois le premier language compile. A l'epoque les gens etaient pas convaincu du concept de compilateur par rapport a coder en assembleur a la main. Donc beaucoup de techniques pionnieres dans la compilation sont issues de cette premiere version de Fortran.
  
  Les premieres versions de fortran n'avaient pas de if then else qui a ete invente plus tard avec Lisp, c'est dire l'etat de l'art en langage de prog de l'epoque.

Article du Turing Award

• [^]Re: Article du Turing Award

  Posté par reno () le 23/03/2007 à 11:36. (lien). Évalué à 2.

  >et pourquoi selon lui les langages fonctionnels sont extrêmement prometteurs.
  > [ coupé ]
  > sans trop de trolls
  
  Pour rétablir la moyenne en troll:
  
  Petit coups d'oeil a la date du papier: 1978.
  En pourcentage, on utilise probablement encore moins les langages fonctionnels en 2007 qu'en 1978, c'est une promesse longue à réaliser.
  
  Bon plus sérieusement, il est vrai que certains concept promus par les langages fonctionnels ont été adopté par des langages utilisé par le commun des mortels: Ruby, etc.
  
  Et Scala est probablement un des seuls langages fonctionnel (hybride en fait) qui m'a intéressé, les autres bof..
  

  • [^]Re: Article du Turing Award

    Posté par Zakath (page perso, ) le 23/03/2007 à 11:39. (lien). Évalué à 7.

    Ce n'est pas parce que windows est utilisé par 98% des ordinateurs alors qu'on a Unix depuis au moins 30 ans que Windows est meilleur ou je ne sais quoi.
    
    Par ailleurs, des langages comme Haskell, scheme ou OCaml sont utilisés par le commun des mortels. Pas autant que C++, java ou même python, mais tout de même de manière non-négligeable.

    --
    Vous devriez vraiment visiter Aperture First !

    • [^]Re: Article du Turing Award

      Posté par yim yom (page perso, ) le 23/03/2007 à 12:08. (lien). Évalué à 2.

      en fait la notion de programmation fonctionnelle s'est retrouve de maniere implicite dans des langages comme le C ( et par consequent le C++, le Java, le C# etc...).
      
      Ces langages utilisent un mecanisme d'evaluation d'expression tres puissant qui leur permet de reproduire tout simplement une notion de programmation fonctionnelle.
      
      Pour resumer, la notion de "procedure" n'existe pas en C mais seulement la fonction. Alors pour aider un peu on a ajouter des function dite void qui ne renvoit rien et qui font comme les procedures (au sens pascal par exemple). Ca n'en reste pas moins des fonctions. Pour le reste tout est fonction et un expression et simplement la combinaison de fonctions. Ceci permet l'evaluation d'expression composees tres complexes et qui s'optimisent fortement. C'est une des forces mal connues du C. Essayez l'exercice qui consistent a concevoir la majeure partie d'un algorithme C en terme d'evaluation d'expressions (comme vous le feriez en Lisp).
      
      Je vous conseille la lecture d'un bouquin bien vieux maintenant mais qui reste une reference agreable sur le C, qui s'appelle simplement le langage C aux editions Dunod ecrit par un D. Galland. La premiere partie de ce bouquin prend le contre-pied de la plupart des autres bouquins en presentant d'abord l'evaluation des expressions en C puis ensuite les instructions de controle de flot (for, if, while, etc...). Ca donne une idee de cette notion tres puissante d'expression.
      
      Ce que je dis s'applique en gros aux autres langages comme C++, Java, C# et tout ceux qui se sont fortement appuyes sur le C (c'est aussi sans doute valable ailleurs mais je ne sais pas).
      
      De la a dire que le C = Lisp, il n'y a qu'un pas a franchir et je le fais volontiers dans de nombreux cas. :-)

      • [^]Re: Article du Turing Award

        Posté par moksha () le 23/03/2007 à 12:34. (lien). Évalué à 3.

        ouais enfin le principe de la programmation fonctionnelle, est qu'une fonction renvoie systematiquement le meme resultat en sortie si tu lui fournis la meme entree. Ca s'approche clairement plus de la notion de fonction en mathematiques...
        
        En C pour faire ca il faut se priver d'utiliser des variables statiques dans tes fonctions, ce qui est relativement contraignant, et que le compilateur puisse le detecter pour faire des optimisations du genre func(a,b) + func(a,b) equivalent a 2 *func(a,b)

        • [^]Re: Article du Turing Award

          Posté par Guillaume Gimenez (page perso, ) le 23/03/2007 à 13:42. (lien). Évalué à 2.

          \o/ gcc
          
          int func (int, int) __attribute__ ((pure));
          
          mes 2 cents

      • [^]Re: Article du Turing Award

        Posté par Hal9000 () le 23/03/2007 à 12:57. (lien). Évalué à 7.

        Tres honnetement, ton raisonnement me semble extremement tire par les cheveux. Le C est, me semble-t-il, totalement inadapte a la programmation fonctionnelle.
        
        L'element de base indispensable (en pratique) a la programmation fonctionnelle, c'est la possibilite de definir des fonctions a la volee (on appelle ca lambda-expressions), et ca le C ne sait pas faire (contrairement au Python, par exemple).
        
        Sans vouloir t'offenser, je ne suis pas sur que tu ais vraiment compris ce qu'est la programmation fonctionnelle, car ca n'a rien avoir avec le fois de pouvoir definir des fonctions, comme ton 3eme paragraphe le suggere. Ca, tous les langages le font. Cela dit, j'ai peut-etre simplement mal interprete ton message.
        
        Ce qui caracterise la programmation fonctionnelle, c'est que _tout_ est fonction, au sens strict du terme, c'est a dire sans effet de bord. En particulier, la notion d'affectation de variable n'existe pas. Je renvoie le lecteur a l'article "Programmation Fonctionnelle" de Wikipedia, il n'est pas trop mal fait.
        
        
        
        

[] --->

• [^]Re: [] --->

  Posté par Victor STINNER (page perso, ) le 23/03/2007 à 13:16. (lien). Évalué à 9.

  Vous savez comment on appelle un mec qui abuse d'algorithmique ? Un algoligue. Arf arf Arf. (blague que nous a fait un prof)

  • [^]Re: [] --->

    Posté par Édouard SIHA-ARCELUZ (page perso, ) le 23/03/2007 à 17:02. (lien). Évalué à 3.

    À mettre avec l'histoire de Boucle For et les 3 Ours... :-)

    • [^]Re: [] --->

      Posté par Jiel (page perso, ) le 23/03/2007 à 17:55. (lien). Évalué à 5.

      C'est l'histoire d'un admin système qui modifie une variable d'environnement... et *path*, le chemin!

      • [^]Re: [] --->

        Posté par l0stman () le 23/03/2007 à 19:41. (lien). Évalué à 2.

        Toujours dans la même veine:
        
        God is REAL unless declared INTEGER
        
        (Dieu est réel à moins d'être déclaré entier)

        --
        ``Whatever it is, I'm against it'' -- Marx Groucho

C'est encore rare les décès de célébrités de l'informatique.

• [^]Re: C'est encore rare les décès de célébrités de l'informatique.

  Posté par lurker () le 24/03/2007 à 06:12. (lien). Évalué à 4.

  Computer Science has always been a discipline where the founders were still around. That’s changing. Phil Windly.
  
  Dijkstra, Backus, Khan, Knuth, Wirth, Hoare, Milner, Wadler, Cousot, McCarthy...
  
  (Liste partielle, partiale et désordonnée)

  --
  /o/

  • [^]Re: C'est encore rare les décès de célébrités de l'informatique.

    Posté par Sytoka Modon (page perso, ) le 24/03/2007 à 14:06. (lien). Évalué à 2.

    Charles H. Moore

[+] Et inventeur de la fondue du même nom...