Langages et performances : les Français à l'honneur !

Posté par  (site web personnel) . Modéré par Nÿco.
Étiquettes :
0
19
mai
2005
Technologie
Pour nourrir les débats sans fin sur les performances relatives des langages, voici une source de données bien faite : The Computer Language Shootout Benchmarks.

Le dernier site similaire n'étant plus mis-à-jour depuis 2003, Brent Fulgham a repris le flambeau, et s'est installé sur un serveur Debian.

Ce site permet de soumettre des benchs, de proposer des réalisations de ces benchs pour un langage, et surtout de consulter les résultats sous différentes formes (y compris graphiques) suivant différents critères (en particulier CPU et utilisation mémoire).

La base des résultats actuels est bien remplie, de nombreux langages et compilateurs y figurant avec un bon nombre de benchmarks (il n'est pas nécessaire de tous les réaliser pour figurer dans le classement).

Surprise, juste derrière un C à la domination chancelante, figurent trois technologies dans lesquelles les Français jouent un rôle important (voire qui sont exclusivement française). Il s'agit respectivement de OCaml, Ada et Eiffel. Je ne rentre pas dans les détails de la participation française à la définition de ces langages, ou/et à la réalisation de ces compilateurs libres.

Parlons plutôt des langages eux-mêmes, dont les qualités mériteraient d'être utilisées plus souvent. J'espère que leur présence en tête de classement incitera plus de développeurs à la curiosité.

L'argumentaire usuel de ces trois langages se base plutôt sur une sémantique de haut niveau, sur des choix guidés par les besoins du génie logiciel, sur l'efficacité dans le développement, la portabilité, la qualité obtenue, etc. Les excellentes performances sont rarement évoquées. Et pourtant !

Étant donné que tous trois sont disponibles sur une large gamme de plateformes (CPU/OS), ce sont des alternatives à considérer, au moins en lieu et place de C : on peut utiliser un langage bien plus puissant sans rien sacrifier des performances.

Enfin, tous trois sont assez différents des langages "mainstream". Si vos neurones commencent à macérer dans le jus d'accolade, ils vous feront l'effet d'un chewing-gum fortement mentholé.

Notons que ce classement ne fait pas du bien à tout le monde : C++ est loin du peloton de tête, à tel point que Java fait presque aussi bien. C# s'en sort mieux en particulier en CPU. Quant à gcj, bon dernier des deux classements, soyons charitables : laissons lui encore quelques années pour arriver à maturité.

Vous trouverez certainement tous des résultats surprenants dans ces données. Qui aurait dit, par exemple, qu'Ada monterait sur le podium, avec un score quasiment double de C++ ? Je vous laisse faire votre marché aux conclusions. Je n'en suggère qu'une seule : méfions nous des préjugés !

Pour éviter les trolls trop faciles, je termine sur quelques précisions :

- tout d'abord, le bench est bien sûr sujet à discussions et interprétations interminables. Comme il est répété à plusieurs endroit sur le site de Shootout : "benchmarking without analysis is bogus". Il ne faut pas prendre les résultats au pied de la lettre.

- il faut bien identifier le besoin : les logiciels ont rarement besoin d'une empreinte mémoire optimisée, ou de performances aux stéroïdes. Il suffit de considérer la grande quantité de logiciels donnant pleinement satisfaction écrit dans les langages de script les plus populaires.

- il y a bien d'autres critères que les performances pour choisir un langage.
La liste des critères et leur pondération est à considérer à chaque développement (enfin bon, là je parle pour ceux qui font des choix rationnels :-). En bref, ne psychotez pas parce que votre langage favori n'est pas sur le podium.

- enfin, n'oublions pas que ce qui est évalué n'est pas le langage, mais le couple langage/compilateur. Bien que l'on puisse identifier immédiatement quelques caractéristiques du langage qui vont avoir une influence lourde sur les performances, il reste difficile de faire la part des mérites respectifs de la conception du langage et de l'optimisation du compilateur. Si le compilateur n'est pas déjà très bon, il reste une certaine marge de progression, les résultats peuvent changer.

Aller plus loin

  • # Remarque...

    Posté par  (site web personnel) . Évalué à 10.

    A noter:

    And remember, languages that implement more benchmarks will move to the top of the list, and those with many missing benchmarks will stay at the bottom!


    Ca peut expliquer certains résultats, quand on voit qu'il manque 9 benchmarks sur le C, et que 3 sur Ocaml, 2 sur l'ADA, ou qu'il en manque 15 sur le C++ Intel...

  • # Un petit test custom

    Posté par  . Évalué à 5.

    En ne sélectionnant que le sous-ensemble implémenté par tous les langages cités voilà le résulta :

    1er C Intel 34
    2eme C GCC 31
    3eme Ocaml 22
    5eme C# Mono 13
    6eme Java 11

    PS: inclure les C++ aurait néxessiter de désactiver trop de benchs

    Ceux qui auront suivi/participé au troll Java v.s C# comprendront qu'ils feraient mieux de se mettre à OCaml s'ils cherchent un langage à la fois puissant et performant. Si tant est qu'on peut qualifier les deux derniers de puissant quand on les compare à OCaml lol.

    • [^] # Re: Un petit test custom

      Posté par  . Évalué à 10.

      On aura beau troller sur les performances de java vs C#, le choix d'un langage est aussi souvent lié au framework qu'on peut utiliser, et les composants open source disponibles en java sont très nombreux.

      OCaml est un langage reconnu pour ses qualités, mais finalement assez peu utilisé; nul doute qu'il serait beaucoup plus utilisé s'il existait un équivalent du projet jakarta pour OCaml.

      • [^] # Re: Un petit test custom

        Posté par  (site web personnel) . Évalué à 3.

        Idem pour Smarteiffel très bon langage, mais bon le framework est un peu pauvre

      • [^] # Re: Un petit test custom

        Posté par  . Évalué à 9.

        Ce qu'on oublie trop souvent, c'est que 99% des applications utilisées par les gens "normaux" (c'est à dire ni physiciens, ni administrateurs de serveurs) sont des applis qui demandent une charge cpu ridicule. J'ai quand même passé une semaine avec un athlon 1800+ tournant à 662 MHz suite à quelques futilités ludiques involontaires en root, et j'ai pas vu la différence (sauf peut-être au démarrage, mais je me demande si ça n'est pas l'effet placebo). Pourtant, j'utilise plein d'applications courantes, bureautique, jeux, icônes qui bougent, transparence, bref, tous ces trucs indispensables qui nous font acheter des bêtes de courses (ne riez pas, c'en était une à l'époque de l'achat).

        Qu'une appli soit écrite en C ou en Turbo Pascal, du moment qu'elle fonctionne correctement, ça ne me fait ni chaud ni froid...

        Bien entendu, je fais brûler vif le premier qui écrit un driver en java. Faut pas non plus abuser.

        • [^] # Re: Un petit test custom

          Posté par  . Évalué à 2.

          Tu as raison, c'est sûr.

          Mais le programmeur, lui, veut une chose: pouvoir programmer vite
          et bien. Pour cela, il y a deux choses commplémentaires:
          1. avoir un grand nombre de bibliothèques. Genre, je veux coder un
          navigateur web:
          #include <navigateur_web.h>

          2. avoir un langage qui évite le plus possible d'erreurs.

          Je suis d'accord qu'Ocaml n'a pas de bibliothèque pour piloter
          automatiquement la cafetière mais c'est un langage qui aide à
          coder juste. Un critère objectif qui vaut ce qu'il vaut: le nombre de
          lignes de code. C'est l'un des langages les plus denses du comparatif.

          • [^] # Re: Un petit test custom

            Posté par  . Évalué à 7.

            Ce n'est pas vraiment le nombre de lignes de code qui détermine la simplicité d'un langage (sinon Perl peut gagner haut la main...), mais le nombre d'atomes lexicaux.
            Un exemple, en Python :
                if True:
                    print "yop"
                    sys.exit(0)
            est aussi simple et dense que :
                if True: print "yop"; sys.exit(0)

            En développement sur le même thème, le texte de Paul Graham "Succinctness is Power" :
            http://www.paulgraham.com/power.html(...)

        • [^] # Re: Un petit test custom

          Posté par  . Évalué à 3.

          J'ai quand même passé une semaine avec un athlon 1800+ tournant à 662 MHz [...](ne riez pas, c'en était une à l'époque de l'achat)


          C'est encore tout à fait honnête. Enfin personnellement, j'utilise souvent une machine à 166 Mhz (bon, pas d'OOo, et le browser c'est w3m) qui tourne très bien.

          Ce qu'on oublie trop souvent, c'est que 99% des applications utilisées par les gens "normaux" (c'est à dire ni physiciens, ni administrateurs de serveurs) sont des applis qui demandent une charge cpu ridicule


          En effet, aussi, il n'est pas très interressant pour le développeur d'une telle application de se compliquer avec un langage peu expressif et/ou des optimisations ridicules, et je pense que le présent article veut souligner ca. Et ce qui est interressant de voir dans ces benchmarks, c'est le dernier petit indice: lines. Les trois quarts du temps, le code OCaml est (beaucoup) plus petit que l'équivalent C: soit, c'est des benchmarls, donc à prendre à la légère, mais en pratique, de mon expèrience, un code OCaml est beaucoup plus compact qu'un code C, ce qui ajoute encore à sa lisibilité et à sa facilité de compréhension.

          Bien entendu, je fais brûler vif le premier qui écrit un driver en java. Faut pas non plus abuser.


          Tiens, tu vas pouvoir faire un bucher avec tous les developpeurs du projet JNode: http://www.jnode.org(...) ;)

          • [^] # Re: Un petit test custom

            Posté par  (site web personnel) . Évalué à 7.

            un code OCaml est beaucoup plus compact qu'un code C, ce qui ajoute encore à sa lisibilité et à sa facilité de compréhension

            Attention à ne pas en faire une généralité : il n'y a aucune corrélation entre longueur et facilité de compréhension.
            Fait lire un test même OCaml par un non informaticien, et le même test Ada dont le source est peut-être quatre fois plus long, vois ce qu'il comprend et tu en aura la preuve.

            Personellement, je trouve ce critère tellement non significatif que je me demande ce qu'il fait sur ce comparatif.

            • [^] # Re: Un petit test custom

              Posté par  . Évalué à 2.

              Tout a fait d'accord!
              Pour parler d'un autre langage fonctionnelle, Scheme, on peut ecrire en tres peu de ligne quelque qui necessiterait des dizaines de ligne en C mais a part celui qui ecrit personne va comprendre ca facilement.

            • [^] # Re: Un petit test custom

              Posté par  . Évalué à -2.

              C'est clair que son affirmation est totalement fausse fait un
              List.fold_right .... de List.map d'un autre truc ca prendra une ligne de code pour faire un truc super complexe, mais bonjour la lisibilité du code.

              OCaml permet de faire des trucs super bien, mais je dirais pas que c'est un grand langage pour sa lisibilité.

            • [^] # Re: Un petit test custom

              Posté par  . Évalué à 2.

              C'est sur qu'on peut écrire un truc parfaitement incompréhensible en Caml (je suppose que c'est pareil en OCaml) en très très peu de ligne. Du genre une fonction qui prend en paramètre une fonction récursive d'ordre 2 et qui l'applique sur son deuxième paramètre, le résultat est aussi une fonction qui elle permet de trier une liste, ce genre de chose .
              C'est très puissant mais prévoir des aspirines pour comprendre ces quelques lignes.

            • [^] # Re: Un petit test custom

              Posté par  . Évalué à 2.

              Oui, j'ai un peu dit n'importe quoi en disant "plus court -> plus lisible": magnifique contre-exemple: le Perl.

              Mais je reste convaincu que pour des fonctions assez courtes, un code "clair" OCaml sera plus court qu'un code "clair" C et a priori, un informaticien qui relira les deux, comprendra plus vite le premier. Je pense que ceci est du essentiellement à deux choses: l'aspect fonctionel d'OCaml permettant d'exprimer très simplement certaines idées pas forcèment intuitive (le fait que OCaml dispose aussi d'outils impératifs lui évite d'être largué par le C quand le besoin s'en fait sentir), et le fait que OCaml soit un langage de plus haut-niveau que le C et disposant d'une bibliothèque standard complète.

              • [^] # Re: Un petit test custom

                Posté par  (site web personnel) . Évalué à 1.

                Je suis déjà tombé sur du code en Caml de 3 lignes en passant 10 minutes à comprendre.

                Une fois compris, j'ai effectivement réalisé que cela prendreait 10 fois plus de code en langage impératif classique. Mais je pense que j'aurai compris avant.

                Après c'est jutse une question d'habitudes

                « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

              • [^] # Re: Un petit test custom

                Posté par  . Évalué à 1.

                Oui enfin parfois ca reste vrai. En Perl:
                my $obj = pop @list;
                Va faire un truc aussi comprehensible en sans cacher ton code derriere un appel de fonction.
                L'extreme, evidemment, c'est le code de Perl monk:
                if (pop)
                ...
                Et la le neophyte se demande sur quoi on pop. Mais il y a un niveau de Perl ou on peut coder clairement tout en gagnant beaucoup de lignes sur le C. Ca vaut aussi en Python, Ruby, bref tous les langages de plus haut niveau.

    • [^] # Re: Un petit test custom

      Posté par  . Évalué à 5.

      Euh, la puissance et la performance ne sont pas les seuls critères pour choisir un language: la lisibilité est mon critère favori.

      Et là, Ruby enfonce totalement Ocaml auquel je trouve une syntaxe pas terrible..

      • [^] # Re: Un petit test custom

        Posté par  . Évalué à 4.

        En fait le principal argument de caml n'est pas la performance ni la puissance mais vraiment le typage fort (avec inférence de type) qui refuse à la compilation tout programme qui risque de planter. Ce qui fait de caml l'un des langages les plus sûrs. Quand ça compile, ça tourne. Pas de segmentation fault possible. Ce qui fait que l'on programme plus vite en Caml (même s'il faut parfois réfléchir un peu plus, on gagne énormément en temps de débogage).

        Pour aller plus loin encore dans cette direction l'INRIA développe COQ, qui a un sytème de types tellement fort qu'il assure que le programme non seulement ne plante pas, mais fait exactement ce que l'on veut. Au prix d'une programmation plus difficile (écrire un programme en COQ c'est écrire une preuve mathématique).

        Quant à la syntaxe... histoire de goût et de couleurs... celle de caml fait couler de l'encre en tout cas...

        • [^] # Re: Un petit test custom

          Posté par  . Évalué à 1.

          En fait le principal argument de caml n'est pas la performance ni la puissance mais vraiment le typage fort (avec inférence de type) qui refuse à la compilation tout programme qui risque de planter.

          Je ne suis pas trop d'accord, je dirais que le typage fort c'est l'avantage d'ADA. L'avantage de Caml c'est que c'est un langage fonctionnel.

          L'inférence de type est très souvent génante pour les développeur car cela demande une très grande rigueur. De plus l'inférence de type provoque des surprises à la compilation, tu peux faire une erreur de logique à un endroit et te retrouvé avec un syntaxe error quelques lignes plus bas car le compilateur continue l'analyse tant qu'il arrive à typer ton terme.

          Enfin Caml reste quand meme un de mes langages préférés ^^

          • [^] # Re: Un petit test custom

            Posté par  (site web personnel) . Évalué à 2.

            Je ne suis pas trop d'accord, je dirais que le typage fort c'est l'avantage d'ADA. L'avantage de Caml c'est que c'est un langage fonctionnel.


            OCaml est un language fonctionnel, impératif, modulaire et objet, pas uniquement fonctionnel, sinon, il serait beaucoup plus limité. Perso, j'aime ce typage fort, et je trouve que c'est un grand avantage.

            L'inférence de type est très souvent génante pour les développeur car cela demande une très grande rigueur. De plus l'inférence de type provoque des surprises à la compilation, tu peux faire une erreur de logique à un endroit et te retrouvé avec un syntaxe error quelques lignes plus bas car le compilateur continue l'analyse tant qu'il arrive à typer ton terme.


            Oui, ca c'est sur... ;-)

      • [^] # Re: Un petit test custom

        Posté par  (site web personnel) . Évalué à 3.

        la lisibilité est mon critère favori
        Moi aussi. Et sur ce critère je pense que le C doit être parmi les derniers de tous les benchs (il n'y a qu'à voir IOCCC), et C++ est bien pire.

        Rappelez-vous qu'un code source est lu bien plus souvent qu'il n'est écrit.

        (Un programmeur frustré qui fait du C++ parce que son chef lui a dit que c'est le meilleur langage puisque tout le monde l'utilise.)

        • [^] # Ah les langages

          Posté par  . Évalué à 3.

          Mouais, ils ont bon dos les langages de programmation, hein ...

          Je pense que tu rejetes le problème sur la mauvaise personne. Une API moisie, mal documentée, un programme incompréhensible, complètement bancal serait la faute du langage ? Ben voyons, si c'était si simple, ça se saurait.

          Le problème numéro 1, c'est quand même l'interface chaise-clavier. Je mettrais ma tête à couper que ta frustration vient d'une API mal faite, pénible à utiliser et très certainement mal documentée, qui a du évoluer chaotiquement, comme tant d'autre ont du se farcir ici. Je n'aime moi non plus pas particulièrement le C++, mais je ne pense pourtant pas qu'il soit mauvais, loin de là.

          Chaque langage à son domaine où il s'illustre un peu mieux que les autres, qui est fortement conditionné par l'api de base fournit avec. Aux programmeurs de faire les bon choix ... ou d'être motivé pour combler les lacunes de l'api (ce qui n'est franchement pas fun, c'est clair).

          • [^] # Re: Ah les langages

            Posté par  (site web personnel) . Évalué à 6.

            Hélas, je ne parlais pas des API mais bien du langage lui-même. Une ligne de code vaut mieux qu'un long discours:
            while (*ptr2++ = *ptr1++) ;
            C'est typiquement le genre de code qu'on trouve à longueur de programme C et qui fait la joie des bidouilleurs, ce qui explique sans doute le succès du langage, mais personnellement ça me donne des boutons...

            • [^] # Re: Ah les langages

              Posté par  . Évalué à 1.

              Bah c'est comme strcpy cte ligne, ca ce lit et comprend instentanément par tout bon hacker ;)
              Ceci étant dit il est aujourd'hui débile d'utiliser ce genre de ligne plutot que strcpy :)

              • [^] # Re: Ah les langages

                Posté par  (site web personnel) . Évalué à 2.

                Surtout que sans validation des pointeurs ci dessus, ce code est dangereux... heureusement que des gens se battent pour renforcer ce genre de fonction pour éviter les buffer overflow...

                Quand on code, il faut aussi absolument faire rentrer en jeu un brin de bon sens...

      • [^] # Re: Un petit test custom

        Posté par  . Évalué à 2.

        Personellement je trouve le C tres lisible et je ne doit pas etre le seul sur terre. Le fait d'utiliser des { et } pour les bloc est une tres bonne idée a mon avis.
        Ceci dit c'est peut etre une habitude pour moi mais il me semble qu'un { est plus facilement repérable qu'un begin (regardez ce post de loin...)
        sinons la syntaxe du python n'est pas mal non plus mais cela donne du code un peut trop compacte a mon gout (et je prefaire qd les variables sont déclarées)

        • [^] # Re: Un petit test custom

          Posté par  . Évalué à 1.

          il me semble qu'un { est plus facilement repérable qu'un begin (regardez ce post de loin...)

          Tu oublies l'indentation. Le nom de la primitive est beaucoup plus lisible, surtout lorsqu'elle n'est pas précédée de scories telles que extern, static, private, virtual, etc. ainsi que de son type ou de sa classe, dont le nom peut être composé (unsigned long), lorsque le nom de cette primitive est le plus à gauche dans le bloc de texte, et que le texte s'y rapportant est visuellement présenté comme y attenant. En tout cas pour moi, il y a une sacrée différence à lire des programmes en Ada ou en Eiffel et d'autres en C, C++, Java, C# et j'en passe, à soin de présentation égal.

          • [^] # Re: Un petit test custom

            Posté par  . Évalué à 2.

            suffit de passer a la ligne avant d'ecrire le nom de la fonction

            • [^] # Re: Un petit test custom

              Posté par  . Évalué à 1.

              Il y a sûrement plein de monde qui fait comme ça mais, je ne dois pas avoir de chance, je ne suis jamais tombé sur du code C présenté ainsi. En tout cas j'ai assez souvent à coder en C sur des microcontrôleurs et ça ne m'est jamais venu à l'idée de m'écarter des manières habituelles d'éditer le code. Je ne tiens pas à ajouter d'autres défauts à ceux intrinsèques du langage.

              Par contre je ne comprends pas du tout que l'on fasse hériter de ce genre de syntaxe des langages censés être de plus haut niveau.

              • [^] # Re: Un petit test custom

                Posté par  (Mastodon) . Évalué à 2.

                «je ne dois pas avoir de chance, je ne suis jamais tombé sur du code C présenté ainsi.»

                Avec n'importe quel éditeur plus évolué que notepad, tu peux:
                1 - indenter automatiquement pour avoir le style que tu veux
                2 - utiliser de la coloration syntaxique pour faire ressortir les éléments importants du code

                C'est presque indispensable pour rendre du code C lisible, mais ça ne me viendrait pas à l'idée de m'en passer sur un langage comme Eiffel, même si sa structure est plus claire. Quel que soit le langage, il est difficile de faire ressortir les éléments importants simplement avec des blancs...

                • [^] # Re: Un petit test custom

                  Posté par  . Évalué à 2.

                  Oui, je suis au courant de ces évidences que tu assènes. M'exprimé-je si mal pour qu'elles constituent une réponse à mon commentaire précédent ? Pour mémoire le point de départ était que les langages comme Ada et Eiffel de par leur syntaxe mettent mieux en évidence le nom des primitives.

                  Oui c'est sûr, et je suis bien d'accord avec toi, l'enluminure syntaxique permet de lire plus facilement du code de tout langage. Et je plaide non-coupable : je n'ai jamais utilisé Notepad sous Linux.

  • # interesting alternative programs

    Posté par  (site web personnel) . Évalué à 7.

    > - il faut bien identifier le besoin : les logiciels ont rarement besoin d'une empreinte mémoire optimisée, ou de performances aux stéroïdes. Il suffit de considérer la grande quantité de logiciels donnant pleinement satisfaction écrit dans les langages de script les plus populaires.
    mmm, j'ajouterai même que les aspects "il faut utiliser l'agortithme tralali tralala" pénalisent les langages qui utilisent les tournures idiomatiques et autres constructions particulières à gogo. Typiquement sur le 1er test (ackermann donc) faut quand même noter qu'à côté du gagnant:
    OCaml 0.11 516 0.11 6
    en 11 1/100èmes de secondes on trouve tout de même:
    C gcc #2 0.07 10,656 0.07 54
    C Intel #2 0.07 188 0.07 54
    Perl #3 0.07 1,464 0.07 8
    les 3 en 7 1/100èmes de secondes, ce qui est remarquable.
    Ces dernières versions ne respectent pas à 100% la règle du jeu, mais quand même...

    Après il est vrai que si on ne s'impose pas de suivre les mêmes algorithmes on risque de tester les algos plutôt que le langage lui-même. Moi j'aurais eu tendance à autoriser tous les coups. Mais l'approche du test est intéressante car au fond, l'expérience montre que ce qui fait souvent la lenteur des langages de script c'est qu'ils sont parfois utilisés "comme si c'était du C". Je veux dire par là que souvent la transition d'un langage en un autre se résume à un changement de syntaxe et ne s'accompagne pas (en tous cas c'est ma démarche naturelle si je ne m'impose pas de faire les choses "comme il faut") des changements de méthodologie, de paradigmes, qui sont pourtant essentiels.

    Cela se traduit par exemple par "vas-y que je te fais un tri à la mimine avec un for 100% scripté" alors qu'il existe des constructions qui permettent de s'en débarasser en une ligne, avec un temps d'exécution divisé par 100. Cet aspect plombant les performances des langages de script dans le monde de la vraie vie, il n'est peut-être pas idiot que ça ressorte quand-même dans le test. Enfin bon pour un puriste tout de même on se dit que s'imposer de faire un programme en Perl en utilisant "cette méthode là et pas une autre" c'est vraiment marcher sur la tête. TIMTOWTDI qu'y disait.

    • [^] # Re: interesting alternative programs

      Posté par  (site web personnel) . Évalué à 3.

      Je me suis amusé à comparer perl et C, la plus part du temps perl est 20x plus lent que le C (par contre le C est 5 fois plus verbeux).

      Sauf dans un teste, ou il est plus rapide. En effet, le code perl ne contient que quelques lignes et utilise à fond les hash et autre.

      Tout cela pour dire que les constructions de base haut niveau des langages de script permète d'avoir des perfs meilleurs qu'en C si on ne veut pas se casser la tête lors du codage.

      "La première sécurité est la liberté"

      • [^] # Re: interesting alternative programs

        Posté par  . Évalué à 3.

        C'est curieux dans la mesure où souvent les instruction shell sont mappées sur des appel à des fonctions développées en C (pour le TCL au moins c'est certain).
        En gros, les développeurs des interpréteurs sont plus compétents que les développeurs des codes C testés sur ce site. Ce n'est plus une mesure des performances induites par les langages à ce niveau.

        • [^] # Re: interesting alternative programs

          Posté par  . Évalué à 5.

          En gros, les développeurs des interpréteurs sont plus compétents que les développeurs des codes C testés sur ce site.

          Sans aucun doute. Mais les micro-benchmarks du Shootout sont souvent très calculatoires et trop basiques pour être optimisés en tirant parti des spécifités du langage.

          Sans compter que, par exemple, réécrire un tri par tas (heapsort) en Python au lieu d'utiliser les fonctions intégrées, c'est complètement idiot.

          • [^] # Re: interesting alternative programs

            Posté par  . Évalué à 4.

            > Sans compter que, par exemple, réécrire un tri par tas (heapsort) en Python au lieu d'utiliser les fonctions intégrées, c'est complètement idiot.

            C'est idiot en production mais lorsqu'il s'agit de mesurer les performances à travail équivalent peut-être pas. On tente de se mettre dans une situation au pire pour laquelle aucune fonction intégré n'existe.

            Ce qui est peut-être idiot, c'est de comparer des développements en langage compilé et des développements dans des langages interprétés par des interpréteurs eux-mêmes développés dans un langage compilé, peut-être le même. Non ?

          • [^] # Re: interesting alternative programs

            Posté par  . Évalué à 4.

            Au moins une des raisons : ces micro-benchmarks sont trés courts et prennent en compte le temps de lancement des interpréteurs qui sont alors fortement défavorisés.

            Comme d'habitude, ces benchs ne valent que par ce qu'ils testent et ne sont intéressants que si tu comptes développer le même genre de programme.

            Je ne parierai pas un seul kopek sur une formule 1 pour gagner le Paris-Dakar.

            • [^] # Re: interesting alternative programs

              Posté par  . Évalué à 3.

              Au moins une des raisons : ces micro-benchmarks sont trés courts
              Court peut etre. Tres court, a voir. Certains font plusieurs minutes. A l'echelle d'une boucle et de 2/3 fonctions c'est pas mal.

              prennent en compte le temps de lancement des interpréteurs qui sont alors fortement défavorisés.
              C'est d'ailleur pour cela qu'ils essayent d'estimer le temps de chargement. D'ou le "CPU time" et le "Full CPU time". Je te laisse lire la documentation pour comprendre la difference.

          • [^] # Re: interesting alternative programs

            Posté par  . Évalué à 0.

            Sans compter que, par exemple, réécrire un tri par tas (heapsort) en Python au lieu d'utiliser les fonctions intégrées, c'est complètement idiot.

            Pas tant que ca, mais cela depend surtout de l'objectif de la comparaison. Si tu veux comparer le langage lui meme et pas la qualite des extensions...

            • [^] # Re: interesting alternative programs

              Posté par  . Évalué à 2.

              Comme tout ce bench est inepte, c'est également stupide de ne pas utiliser les fonctions intégrées des langages: quand qq va utiliser Python, à moins d'être taré, il va pas s'amuser à réécrire un tri par tas (sinon on pourrait également interdire les pointeurs en C, les listes en OCAML, etc...).

              • [^] # Re: interesting alternative programs

                Posté par  . Évalué à 4.

                Question bete, elle est ecrite en quoi la fonction integree en question ? Parce que pour peu qu'elle ne soit pas ecrite dans le langageque tu veux tester mais en langage X, c'est sur l'implementation en X que tu fais un bench, agrementee d'un appel dans le langage d'origine. La, le bench devient vraiment vide de tout sens.

  • # Un peu fumeux...

    Posté par  . Évalué à 3.

    Le site Web le dit lui-même : ces benchmarks sont éminemment faillibles. D'abord ce sont tous des micro-benchmarks, des tests sans commune mesure avec l'échelle d'une application sérieuse. Ensuite la règle de chaque test est arbitraire, et peut favoriser certains langages par rapport à d'autres. Enfin, la plupart des tests interdisent d'utiliser des bibliothèques tierces, bien que celles-ci puissent quelquefois donner d'énormes améliorations.

    Surtout, ce type de comparaison isole le temps d'exécution en ignorant un autre temps tout aussi important : le temps passé à écrire, débugger, maintenir un programme. Les utilisateurs de langages comme Python ne sont pas dupes, ils savent que le C est plus "rapide" à l'exécution... mais uniquement si on dispose de beaucoup de temps pour écrire un programme aussi soigné et bien conçu qu'on le ferait en Python.

    « Are your programs even like these benchmarks?

    * Do your programs startup and finish within a few seconds, like these benchmarks?
    * Are your programs tiny, like these benchmarks?
    * Do your programs avoid library re-use, like these benchmarks?     »

    http://shootout.alioth.debian.org/miscfile.php?sort=fullcpu&fil(...)

    • [^] # Re: Un peu fumeux...

      Posté par  . Évalué à 1.

      Non, ce type de site mesure la qualité d'un résultat (un programme) selon des critères de vitesse d'exécution et d'occupation mémoire et classée suivant le langage utilisé pour produire le code.

      Le temps de conception, la durée du développement, sa difficulté (temps de débuggage) et la maintenance soulèvent des problèmes de productivité et de coût de production. Ces problèmes ne sont tout simplement pas traités par le site.

      Lorsqu'on doit faire un choix, je trouve pratique de disposer d'une base de donnée en ligne comme celle là qui donne une idée grossière sur l'un des critère (important à mon avis) à prendre en compte : les performances attendues du futur produit en fonction du langage de programmation utilisé. Il est clair que d'autres critères sont à examiner qui, suivant les contraintes, peuvent se révéler prépondérants mais ils ne sont manifestement pas du ressort de Shootout et on ne peut pas le leur reprocher.

      Il est également à noter que de nombreux facteurs d'efficacité sur un projet ne sont même pas conditionnés par le langage utilisé (doit-on sous-traiter, quel outil de gestion du projet, du workflow, quel IDE, quel gestionnaire de versions, combien de développeurs utiliser pour diviser les délais, quelle contrepartie est acceptable en gestion du projet, quelle tolérance d'erreur au résultat, ...). Un site comme celui-ci n'a pas vocation à faire les choix à notre place mais veut donner un éclairage sur l'un des aspects techniques importants. Je trouve qu'il ne le fait pas mal dans la mesure où l'affichage des résultat est très customisable.

      • [^] # Re: Un peu fumeux...

        Posté par  (site web personnel) . Évalué à 2.

        Il y a quand même une estimation du temps de développement : la taille du code.

        Il faudrait regarder comment fait sloccount pour être précis. Mais à la louche, on peut dire que le temps de codage est proportionnel à la taille du code.

        "La première sécurité est la liberté"

  • # C comme les sondages ce truc :)

    Posté par  (site web personnel) . Évalué à 2.

    C'est un peut comme les sondages ce truc : plein de chiffres qui ne veulent rien dire, des classements sur des bases non pertinentes, ...

    Bref aucun des langages n'est testé à la même manière, pour certains, il manque plein de tests. Comparer des résultats sur un langage/compilo sans avoir effectué les mêmes/même nombre de test ça ne veut rien dire.

    De plus, comment faire un truc pareil sans appeler au troll, genre ouais mais il a utilisé gcc 3.4.4 pou gcj alors qu'il y a la 4.0.0 qui est mieux ou inversement. Il a utilisé tels optimisations de compilation alors que pour ce truc, il aurait mieux valu tel ou tel option,il ne sait pas codé en tel langage, et a écrit sont truc comme une procasse, il aurait du coder la même de telle ou telle manière et mon langage aurait tout torcher.

    Bref ces benchmarks ne sont aucunement significatifs et ne veulent rien dire du tout !!!

    • [^] # Re: C comme les sondages ce truc :)

      Posté par  (site web personnel) . Évalué à 2.

      Bref ces benchmarks ne sont aucunement significatifs et ne veulent rien dire du tout !!!

      n'importe quoi : ça veut bien dire quelque chose mais il faut analyser. Il faut un peu faire marcher son cerveau, aller lire le code des différents benchs, comprendre pourquoi ça été ecrit comme ça, et en tirer les conclusions qui conviennent.

      C'est stupide de prendre tous ces chiffres pour argent comptant (« mon langage est 23% mieux que le tien ! ») mais c'est encore plus stupide de tout rejeter en bloc.

    • [^] # Re: C comme les sondages ce truc :)

      Posté par  . Évalué à 3.

      > C'est un peut comme les sondages ce truc : plein de chiffres qui ne veulent rien dire

      On sait plein de choses sur les sondages, et notamment, qu'un sondage sur 1000 personnes est fiable à 5 points prets à 95%; et que pour que le sondage soit fiable à 1/2 point près, avec le même risque, faudrait interroger 100 000 personnes.

      C'est pas parfait, mais ça vaut ce que ca vaux.

      • [^] # Re: C comme les sondages ce truc :)

        Posté par  . Évalué à 5.

        Selon mes calculs, c'est plutôt + ou - 3% pour N = 1000. Si les proportions dans la population sont de l'ordre de grandeur de 50/50, alors on s'attend à avoir en moyenne 500 oui, avec une variance de 0.5*(1-0.5)*1000, soit 250. En approximant par une loi normale, on a une moyenne de 500 et un écart-type de 250^1/2 soit 15,9. On prend un risque bilatéral de 5%, on a donc un intervalle de confiance de x - 1,96*15,9 < X < x + 1,96*15,9, soit, si x = 500 dans l'échantillon, 469 < X < 531 (en pourcentages : 46,9 < p < 53,1).

        Je ne connais pas les détails de la fameuse "méthode des quotas", mais je pense qu'ils échantillonnent de manière biaisée pour diminuer l'écart-type (tout en biaisant l'échantillonnage, évidemment), mais l'idée est là quand même : les sondages 51/49, et autre "oh le oui a augmenté", c'est vraiment du pipeau de journaliste inculte ou de politicien de mauvaise foi.

        C'était quoi, à la base, le thème de la discussion?

        • [^] # Re: C comme les sondages ce truc :)

          Posté par  . Évalué à 2.

          Pourquoi 1,96 ?

          • [^] # Re: C comme les sondages ce truc :)

            Posté par  . Évalué à 4.

            C'est comme 42, c'est un nombre magique :-)

            En fait, on a 95% de la loi normale entre moyenne - 1,96*écart-type et moyenne + 1,96*écart type . Quand on fait un intervalle de confiance à 95% (c'est à dire qu'on veut avoir 19 chances sur 20 de ne pas se planter), il faut donc prendre 1,96. Si on veut un intervalle de confiance à 99%, c'est 2,58.

            • [^] # Re: C comme les sondages ce truc :)

              Posté par  (site web personnel) . Évalué à 5.

              Si on admet que l'évaluation de l'erreur sur la la valeur moyenne d'une gaussienne suit une loi de Xhi2, on peut démontrer que le rapport entre deux évaluations suit une loi de Fisher-Snedecor.
              C'est assez évident et je ne pense pas qu'il soit nécessaire de vous le démontrer ;-))

        • [^] # Re: C comme les sondages ce truc :)

          Posté par  . Évalué à 4.

          Le problème majeur des sondages, c'est les erreurs systématiques. Le sondé ne sait pas quoi répondre, le dîner est entrain de cramer, frontiste menteur ... Sa explique beaucoup de chose quant on sait de quoi on parle, n'est ce pas Mr/Mme les politiciens/journalistes!

          Dans le même registre, la baisse miraculeuse du mois pour le chômage: 0.0001%, fluctuation statistique ou politique efficace?

          Un jour, j'ai trouvé un livre écrit par un américain sur le sujet. Si je me souviens bien le titre était "L'illusion statistiques". En bref, les politiciens gouvernent à partir de données qu'ils ne comprennent pas ...

          • [^] # Re: C comme les sondages ce truc :)

            Posté par  . Évalué à 3.

            Ils peuvent aussi tres bien comprendre les donnees... et leur faire dire ce qu'ils veulent que l'on comprenne...

  • # benchmarks bidons

    Posté par  . Évalué à 8.

    je n'ai pas lu les modalités, mais quand je vois des comparaisons à coup de centièmes de millisecondes, je me dis que c'est pas très sérieux. Il faut des temps d'exécution de l'ordre de la minute pour commencer à avoir des résultats significatifs et que les "dérangements" extérieurs prennent une portion non-significative.

    • [^] # Re: benchmarks bidons

      Posté par  . Évalué à 1.

      Qui plus est quand l'on compare des langages compilés et interprétés dans le même teste, personnellement j'attribue au chargement et a la charge fixe de l'interpréteur les très mauvais score de python. De plus la qualité du code de chaque teste celon chaque langage peut varier, ce genre de test fait intervenir énormément de paramétres, et comme cela déjà été dit plus haut la vitesse pure n'est pas forcement le principale critére de choix d'un langage sans quoi on coderait encore tous en ASM.

      • [^] # Re: benchmarks bidons

        Posté par  (site web personnel) . Évalué à 2.

        personnellement j'attribue au chargement et a la charge fixe de l'interpréteur les très mauvais score de python.
        Autant le chargement on pourrait l'enlever, autant l'interprêteur, comme tu l'indiques, est "fixe". Il contribue donc au score de Python de manière "régulière".

        comme cela déjà été dit plus haut la vitesse pure n'est pas forcement le principale critére de choix d'un langage sans quoi on coderait encore tous en AS
        Tout est une histoire de compromis et de polyvalance. l'ASM et un langage inteprêté comme Python sont un peu les extrêmes. Je te laisses te faire tes propres conclusions.

  • # Ocaml va t'il remplacer C++?

    Posté par  . Évalué à 4.

    Ce qui est intéressant avec ce benchmark. C'est dévalué la perte de performance avec un langage de haut niveau.

    Dans le domaine du calcule numérique en physique, C++ a remplacé Fortran. C++ est un langage oo rapide, mais c'est une horreur. Sa syntaxe est indigeste (surtout pour un physicien). L'introspection est beaucoup trop limité, pas de oo dynamique à la ObjectiveC. Le système d'arguments par défaut est une belle saloperie, vive les labelles. La stl est une aberration (code dans l'interface, code bloat). Il n'y a pas d'interpréteur valable. etc ...

    Grâce à ce benchmark on peut voir qu'Ocaml semble peut pénalisant au niveau vitesse par rapport à C++. Je me demande bien qu'elle va être l'intérêt du C++ d'ici quelques années avec les processeurs 4 cores. Il y a 10 ans, on pouvait comprendre son design. Aujourd'hui, j'ai des doutes! Car mêmes en calcule intensif, le temps d'exécution est très relatif par rapport au temps cumulé d'écriture, de compréhension et de mise au point.

    • [^] # Re: Ocaml va t'il remplacer C++?

      Posté par  . Évalué à 1.

      Dans le domaine du calcule numérique en physique, C++ a remplacé Fortran.

      Le fortran n'est pas si mort que ca : il existe des tas de biblioteque que les entreprises rechignent a migre, le language est encore en evolution et je crois que certain aspet du language (pas de pointeur ???) facilite l'optimisation au niveau de la compilation.

      • [^] # Re: Ocaml va t'il remplacer C++?

        Posté par  . Évalué à 3.

        Le fortran n'est pas si mort que ca : il existe des tas de biblioteque que les entreprises rechignent a migre

        Je pense qu'il parlait des nouveaux developpements.

        e language est encore en evolution et je crois que certain aspet du language (pas de pointeur ???) facilite l'optimisation au niveau de la compilation.

        En theorie, oui. Malheureusement il faut trouver un compilateur qui le fasse correctement. Certains le font, mais faute d'utilisation a grande echelle, on a souvent des surprises. "Calcul rapide mais resultat incorrecte" remonte a mon oreille assez souvent a propos des compilos fortran.

    • [^] # Re: Ocaml va t'il remplacer C++?

      Posté par  . Évalué à 2.

      Tu estimes qu'Ocaml est à la fois plus agréable à écrire, mieux conçu et plus performant. Si tu as raison, je crois que tu tiens la réponse à ta question.

      Il faut quand même se méfier des raisonnement logiques. On doit aussi tenir compte des parcs installés, de l'importance des communautés d'utilisateurs, éventuellement de l'existence d'un plus ou moins grand nombre d'API et de bibliothèques (encore que le partage de bibliothèques développées en des langages différents mais compilés reste assez simple hors problème de prototypage si on ne dispose pas du .h adapté au langage utilisé, ordre, stockage et format des arguments passés et peut-être d'autres détails). Il y a de l'inertie dans ce domaine. Exemple, il paraît que le Cobol est mort depuis 20 ans.

      • [^] # Re: Ocaml va t'il remplacer C++?

        Posté par  . Évalué à 2.

        Il parait oui, mais ce n'est pas le cas pour les 12 personnes (dont je fait partie) qui viennent de suivre une formation de 6 semaines pour en faire au cours de leur missions...

    • [^] # Re: Ocaml va t'il remplacer C++?

      Posté par  . Évalué à 2.

      On retrouve effectivement le C++ derrière le C, ce qui peut sembler surprenant étant donné que les choix de conception du C++ étaient justement que toutes les fontionnalités du C soient disponibles sans perte de performance.
      Ce choix de conception a donné des résultats comme la compilation en statique des templates (Liste<int> et Liste<Widget> sont compilés comme deux classes séparées, parce que les templates ne devaient pas rajouter de coût); de manière générale la taille du code est à peu près 5 fois plus grosse pour pouvoir faire en statique tout ce qui peut l'être, et au final on se retrouve avec des résultats moins performants.
      L'explication est sans doute que les binaires plus gros utilisent moins efficacement le cache du processeur, mais en tout cas on voit que concevoir un langage pour la performance en s'attaquant à des cas bien précis ne donne pas de bons résultats.

      • [^] # Re: Ocaml va t'il remplacer C++?

        Posté par  . Évalué à 6.

        La gestion des exceptions en C++ font aussi grossir les binaire fortement : il faut decrire en format dwarf chaque operation sur la pile (sauvegarde/restauration de pointeur, empillage/depillage) pour pouvoir revenir a un etat coherent...
        Par contre en cout d'excecution ca devrait etre negligeable.

        PS : pour la petite histoire, y en a qui on fait du traitement d'exception en asm (dans la nptl) et c'est comment dire assez horrible.
        Hereusement que les nouvelles version de gas supporte les instruction dfi qui permette de generer le dwarf automatiquement...

  • # Dommage ...

    Posté par  (site web personnel) . Évalué à 10.

    Salut,

    Je suis un peu déçu par la rédaction de la news. En effet, elle insiste beaucoup sur l'aspect benchmark lui-même, sans ouvrir le débat plus large sur l'utilisation de langages de haut-niveau. Du coup, le débat tient plus du troll mon langage est mieux que le tien, non, c'est le mien qu'il est le mieux, etc... (trolls qu'on a déjà dans la news sur OpenOffice et Java).

    Ce qui est intéressant, c'est de voir que les langages de haut niveau ne sont plus sous-performants par rapport à des langages comme le C de base. L'important, ce n'est pas de savoir si Ocaml s'exécute 0.5% plus vite que du Java ou du C++ dans tel cas précis, mais bien de voir que les performances globales des langages de haut niveau sont tout à fait honnêtes.

    À partir de là, on pourrait se demander si il ne serait pas judicieux d'arrêter de développer tous les logiciels avec des langages préhistoriques comme le C. Je ne dis pas ça parce que je ne sais pas programmer en C (je bosse sur de la programmation système, donc que du C), mais parce que pour moi coder gkrellm, thunderbird ou grisbi en C, c'est une perte de temps. Des langages de haut niveau existent, ils rendent le code plus lisible, plus abordable pour des contributeurs et ils permettent d'éviter les bugs foireux de débordement de buffers, de mémoire pas libérée et autres. Pour moi, ces langages de haut niveau, c'est vraiment un atout pour le programmeur. Pourquoi ne pas les utiliser plus massivement pour toutes les applications de bureau ?

    La performance ne me semble pas être la bonne raison : la plupart des logiciels "de bureau" ne font pas du calcul scientifique qui nécessite d'être optimisés aux petits oignons.

    En fait, j'ai l'impression que pour l'instant, le langage C est pris parce que c'est le seul suffisamment répandu. Aucun langage de haut niveau n'a vraiment réussi à s'imposer : ni Ocaml, ni Eiffel, ni Java, ni C#.

    Quand je vois Novell qui essaie d'utiliser C# et Mono dans ses nouveaux outils et logiciels, je trouve que c'est plutôt une bonne idée. Une bonne idée dans le principe d'utiliser un langage de haut niveau, mais on sait tous que C# et Mono peuvent peut-être poser des problèmes (pouvoir de Microsoft ? brevets ?).

    Qu'en pensez-vous ? Pourquoi les applications sont-elles toutes développées en C ?

    • [^] # Re: Dommage ...

      Posté par  (site web personnel) . Évalué à 2.

      tout dépent des applications, il y a de moins en moins qui sont écrit en c

      dans le commerce c'est haut la main C++ qui gagne...

      faut pas raconter n'importe quoi, java s'est imposé en entrerprise, dans les gros système

      s'imposerra-t'il sur le marché du bureau avec mustang et dolphin?

      gnome utilisera t'il java ou mono?

      www.solutions-norenda.com

    • [^] # Re: Dommage ...

      Posté par  . Évalué à 3.

      Moi j'aime bien la news:
      Parlons plutôt des langages eux-mêmes, dont les qualités mériteraient d'être utilisées plus souvent.

      Enfin, tous trois sont assez différents des langages "mainstream". Si vos neurones commencent à macérer dans le jus d'accolade, ils vous feront l'effet d'un chewing-gum fortement mentholé.

      L'aspect langage pour ses capacités d'expression mérite d'être développé.

      Quand à savoir pourquoi le C est utilisé, il faut dire qu'il est facilement identifiable et qu'il permet de rassembler des contributeurs plus facilement. Et il permet d'écrire du code qui sera facilement lib-ifié et pourra s'imposer. En ce qui concerne ses qualités propres, il ne rend pas impossible la programmation de haut niveau (mais sans garde fou).
      Par contre, utilisé en tant que langage de haut niveau il coûte beaucoup plus en refactorisation, il est difficile à faire évoluer et à réutiliser. Donc les nouveaux projets ont intérêt à éviter.

    • [^] # Re: Dommage ...

      Posté par  . Évalué à 6.

      Qu'en pensez-vous ? Pourquoi les applications sont-elles toutes développées en C ?

      Au hasard :

      Disponibilité de compilateurs nombreux, efficaces et sûrs (enfin, raisonnablement) => indépendance vis-à-vis du fournisseur du compilateur.

      Disponibilité de nombreux développeurs => indépendance (relative) vis-à-vis des développeurs (je parle du point de vue de la méchante entreprise, s'entend), facilité à auditer le code (essayez d'auditer une jvm codée en whitespace :-D ... )

      Expérience disponible en interne.

      Forte quantité de code libre de qualité facilement réutilisable ("On s'en fout, que ce soit du GPL, puisqu'on le garde en interne", "Tiens? du BSD!"); bibliothèques nombreuses.

      Technologie éprouvée, parfaitement maitrisée, problèmes connus (tout le monde sait que le C est sensible aux problèmes de dépassement de tableaux, il suffit d'y faire attention); frilosité des décideurs ou des codeurs.

      Maîtrise du code produit, et liberté de faire ce que l'on veut dans le programme (comment fait-on pour faire un lien matériel entre deux fichiers en Java, déjà? - Je VEUX faire un buffer overflow à cet endroit, et je ne comprend pas pourquoi je n'y arrive pas dans en Ada).

      Portabilité raisonnable.

      Tous les arguments qui précèdent, réunis dans un seul langage.

      • [^] # Re: Dommage ...

        Posté par  (site web personnel) . Évalué à 7.

        Je VEUX faire un buffer overflow à cet endroit, et je ne comprend pas pourquoi je n'y arrive pas dans en Ada).

        C'est une caractéristique essentiel d'Ada : tout est possible, y compris un buffer overflow.
        Mais pour faire une goretterie pareille il faut faire un effort une fois. (Je me demande bien pourquoi, au passage).
        Dans d'autre langage c'est pour éviter le buffer overflow qu'il faut faire des efforts... tout le temps.

        L'esprit n'est pas le même, et ca fait une grosse différence.

      • [^] # Re: Dommage ...

        Posté par  . Évalué à 1.

        Rofl, bientôt un troll OCaml contre Whitespace :-)))

        Pour ma part, je pense qu'au dela de la disponibilité en nombre de programmeurs, bien que de plus en plus de jeunes en fassent à l'école, il manque aussi à OCaml certains critères pour que le patron moyen (et un patron, c'est malheureusement un patron) ose se pencher un peu dessus :

        - Une réputation... actuellement c'est plus du genre "un truc de chercheurs"
        - Une belle IDE présente sous Win, Mac et Linux, qui soit pleinement fonctionnelle
        - Un débuggeur potable et visuel (i.e. facile à utiliser)

        Montrez moi les trois et je tente le coup avec mon patron (on passe notre code delphi en OCaml - ça peut pas être pire que Delphi 5.0 !)

    • [^] # Re: Dommage ...

      Posté par  . Évalué à 5.

      Peut être parceque les developpeurs de LL font généralement ça pour le plaisir (et pas pour le rendement, les deadlines etc.) ?

      Je pense aussi qu'un grand plaisir est d'utiliser un langage dont l'apprentissage permet aussi de mieux maitriser et comprendre le système sur lequel on l'execute. Ici le C est roi.

      Et puis je pense que les devs de LL n'ont pas besoin de se conformer aux lubies des decideux préssés comme en entreprise ; et qu'on ne leur vend pas si facilement du java-c-est-portable et autre c-sharp-c-est-universel à coup de campagnes de marketing sur 01.net ...

      • [^] # Re: Dommage ...

        Posté par  (site web personnel) . Évalué à 3.

        Je comprends bien ce que tu dis sur l'aprentissage.
        Mais concernant le développement, il ne s'agit de rien d'autre que de ton temps : tu le gaspilles ou tu l'utilises.

        Débuggez ou développez, that is the question.

        La plupart des dev Ada utilisent leur debugger tous les trois mois. Ca parait incroyable, mais c'est la stricte vérité.

        Et pour ta dernière phrase, je me félicite que les dev de LL ne fassent pas le même choix que les entreprises, car curieusement les entreprises ne sont que rarement rationnelles, et elles vivent dans la psychose de prendre du retard et ne pas être dans le "mainstream".

        • [^] # Re: Dommage ...

          Posté par  . Évalué à 3.

          La plupart des dev Ada utilisent leur debugger tous les trois mois. Ca parait incroyable, mais c'est la stricte vérité.

          J'fais la meme chose en C, incroyable non ? :)

          Globalement je pense qu'un langage permissif permet certe de faire n'importe quoi facilement, mais qu'un peu de rigueur suffit à creer des trucs fiable et bien écrit pas trop lentement. Mais je ne me fait pas d'illusion, le haut niveau permet de bonne économie de temps de devel, et force les gens à ne pas écrire n'importe comment. J'insiste sur le fait que cela a un cout à l'execution (quelqu'il soit : empreinte mémoire, charge CPU, pires cas, ...) ou un cout à l'acces au langage (changement de modèle de developpement, framework), et qu'il faut determiner son degré d'acceptabilité.

          • [^] # Re: Dommage ...

            Posté par  (site web personnel) . Évalué à 2.

            J'insiste sur le fait que cela a un cout à l'execution

            Tout à fait, mais justement le bench montre que ce coût peut-être faible.

            Par ailleurs, dans le cas de Ada, de nombreux checks sont fait à la compilation, car le source est sémantiquement riche. Ceci est sans conséquence au niveau du code généré.

            Quand aux vérifications à l'exécution, tu as la possibilité de les enlever là ou tu le souhaite, soit par les options de compilation, soit directement par des pragmas dans le source. Ceci est utile par exemple lorsque qu'un outils externe te fournit une preuve formelle de ce que ces vérifiations sont inutiles.
            Mais en fait, c'est rarement utile, car le compilateur fait un très bon boulôt d'optimisation.

            Tu as donc le beurre et l'argent du beurre :
            - vérif en abondance à la compil,
            - vérif à l'execution pour le reste,
            - performance quand il le faut.

            Pour finir, il y a un compilateur Ada qui fait très fort car il ajoute de nombreux warnings et optimisations par dessus ce qui est imposé par le langage (et même des suggestions de corrections pour les erreurs bateau et les typos).

            Et pour la chance du monde du libre, il se trouve que c'est justement GNAT, le compilo Ada de gcc.

    • [^] # Re: Dommage ...

      Posté par  (site web personnel) . Évalué à 5.

      Salut Thomas,

      Tu as raison, j'en ai trop fait sur le bench, et les précautions pour éviter les trolls sont parfaitement inutiles sur ce genre de sujets. J'ai en fait commencé une réponse dans la discussion Java et OOo, mais ca m'embettait de participer à ce troll.
      Alors, j'ai fais un article.

      Toutefois, ce que tu dis est exactement la première moitié de la news. Ta conclusion sur la l'inutilité de C dans la plupart des développement moderne est exactement l'essence de l'article.

      L'autre message que je voulais faire passer, c'est que les solutions "mainstream" ne sont pas forcément les meilleures, mais, bon, c'est si rassurant d'être dans la masse. Utiliser une solution originale demande d'être cultivé déjà rien que pour en avoir eu connaissance, encore plus pour bâtir un argumentaire comparatif (alors que si tu fais du C personne ne te demande rien).
      Faut être un peu couillus ou associable, je trouve :-).

      Tiens, sans le faire exprès je t'ai donné une réponse à ta question sur pourquoi C domine toujours outrageusement :-)

    • [^] # Re: Dommage ...

      Posté par  . Évalué à 4.

      Mets-toi à la place du programmeur débutant. Pour se mettre à programmer, quelles docs trouve-t-il en premier à Carrouf dans le rayon des bouquins Sybex/Microapp à 10 euros -> C++/Java ! Et même s'il a appris que OCaml est un super langage, et qu'il se décide à acheter un bouquin pour s'y mettre (50 euros mini quand même), quel genre de bouquin trouve-t-il ? Une grosse intro très rigoureuse à la programmation fonctionnelle (voire au lambda-calcul), de l'algorithmique avec des arbres/listes chaînées, etc. Des choses très bien pour comprendre, acquérir de la rigueur et devenir un bon programmeur mais qui vont décourager notre programmeur débutant qui voudrait savoir rapidement faire des applis qui cartonnent comme avec Python... A quand un "Ocaml pour les nuls" ? :o)

      Et si le programmeur connaît le C/C++ (comme moi), il veut aussi pouvoir s'y mettre rapidement en se raccrochant autant que possible à ce qu'il connaît. Ce serait une bonne chose si les concepteurs de OCaml écrivaient un bouquin/tutoriel visant le programmeur moyen (pas forcément étudiant en informatique) avec un peu plus de concrêt, genre un "OCaml pour les programmeurs C/C++, avec des exemples utilisant QT, OpenGL, SDL...

      Enfin, apparemment (je ne maîtrise pas le sujet) il semble y avoir une véritable barrière à l'entrée pour les débutants qui voudraient utiliser OCaml avec des libs en C (pour lesquelles aucun binding officiel n'aurait été écrit). Notamment je crois qu'il faut faire gaffe à des détails liés au gc...

      • [^] # Re: Dommage ...

        Posté par  . Évalué à 1.

        Je suis d'accord. Même si ce n'est sûrement pas aux programmeurs de caml d'écrire ce livre, ils ont probablement beaucoup mieux à faire.

        Cela dit, le livre O'Reilly sur OCaml (dispo en ligne) est assez facile d'abord et ne part pas dans des considérations trop théoriques (même s'il manque une partie lablgtk2 pour faire de vraies interfaces graphiques).

      • [^] # Re: Dommage ...

        Posté par  (site web personnel) . Évalué à 2.

        Je ne parlais pas forcément d'Ocaml. J'ai également beaucoup de mal à me faire à ce langage. Je parlais en général des langages de haut-niveau sans présumer d'un quelconque choix.

        Des langages comme Ada ou C# sont par exemple des langages assez simples, mais proposant des abstractions et une bibliothèque moderne.

        En fait, dans le C, ce qui m'embête, ce n'est pas seulement le langage en lui-même et la manipulation des pointeurs, mais c'est aussi la bibliothèque standard C, en particulier la manipulation de chaînes de caractères : fgetc, getc, gets, fgets, putc, puts, fputs, fputc, getchar, putchar, toutes les fonctions genre strncpy qui font pas bien le boulot, sans parler des sockets qui sont assez difficiles à utiliser correctement, etc... Il me semble qu'il y a des langages de plus haut niveau proposant des bibliothèques standard mieux conçues, permettant de développer plus vite, avec moins de bugs.

        Le problème, c'est qu'aucun langage ou plateforme ne s'est réellement imposé à ce jour pour développer des applications "de bureau" avec un langage de haut-niveau. Je veux développer une appli simple avec une interface graphique. Je dois le faire en quel langage si je veux un langage de haut-niveau, avec de nombreuses bibliothèques et connu par de nombreux développeurs ? Ruby ? Python ? Java ? C# ? Ada ? Ocaml ?

        Actuellement, je le fais en Python, mais l'absence de typage et de déclaration de variable me gêne vraiment.

        • [^] # Re: Dommage ...

          Posté par  (site web personnel) . Évalué à 1.

          Je proteste, tu n'as pas cité Perl :)
          Surtout que dans ton cas, ça peut régler le problème des déclarations de variables (et éventuellement celui du typage avec "use types" et compagnie).

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # bidon

    Posté par  . Évalué à 1.

    Les tests sont assez marrants, je prends l'exemple d'un langage que
    je connais bien, le Java. En rajoutant dans le test de ackermann une boucle,
    on peut observer ceci

    [rabbit speedball] time java -server ackermann 9 1
    Ack(3,9): 4093
    java -server ackermann 9 1 0.30s user 0.29s system 72% cpu 0.818 total

    [rabbit speedball] time java -server ackermann 9 100
    Ack(3,9): 4093... etc
    java -server ackermann 9 100 5.39s user 0.33s system 61% cpu 9.267 total

    [rabbit speedball] time ./ackermann.gcc_run 9
    Ack(3,9): 4093
    ./ackermann.gcc_run 9 0.05s user 0.00s system 4% cpu 1.089 total

    Qu'est ce que l'on voit ? que plus le code tourne et plus il est
    efficacement éxécuté. Lancer le test 1 fois ne donne aucune
    indication sur la rapidité de java ... ... tester une jvm "à froid"
    donne toujours des résultats décevants

    • [^] # Re: bidon

      Posté par  (site web personnel) . Évalué à 2.

      Tu as parfaitement raison, et c'est pourquoi le test est lancé trois fois de suite, et que seul le meilleur temps est retenu (tandis que pour la conso mémoire c'est la plus grande qui est conservé).

      Ceci répond également partiellement a l'objection faite plus haut sur le désavantage des interpréteurs par rapport au test compilés : le désavantage est réel, mais pas si important que celà.

      • [^] # Re: bidon

        Posté par  . Évalué à 0.

        justement non, que le programme soit lancé 1 fois ou 50 ni change rien ...

        C'est pour 1 lancement du programme, qu'il faut tout d'abord laisser la jvm "chauffer" puis a ce moment la mesurer les performances.

        • [^] # Re: bidon

          Posté par  (site web personnel) . Évalué à 0.

          Le fait de lancer trois fois le test fait que la JVM est encore dans la mémoire (si la machine n'est pas intensivement utilisée en parallèle du bench). La première fois tu vas la chercher sur le disque.

          Alors je serai surpris que ca ne fasse pas une belle différence, même si ce ne sont pas encore les conditions idéales.

          • [^] # Re: bidon

            Posté par  . Évalué à 1.

            Ca ne suffit pas. Les JVM modernes sont dites Just In Time. En gros à la première execution d'une fonction le code n'est pas optimisé. Il le sera par la suite si la machine virtuelle détecte que la fonction est suffisamment utilisée pour que le coût d'une recompilation native à la volée se justifie. C'est pour cela qu'au début les performances de Java sont assez merdiques et qu'elles s'améliorent ensuite fortement. Je parle par expérience, c'est vraiment flagrant.

            A chaque relancement du programme ce processus repart de zéro (c'est un peu con d'ailleurs). Le fait que la JVM soit déjà en mémoire n'y change rien.
            Prendre en compte d'ailleurs le lancement de la JVM d'ailleurs devrait sérieusement plomber les perfs...

            Sinon les perfs varient fortement selon les JVM et leur configuration. La JVM d'IBM me semblait plus performante que celle de SUN mais plus lente à "chauffer".
            La JVM de SUN a 2 modes: mode client (par défaut) qui se lance plus vite mais optimise moins le code; et le mode server, plus lent au début mais qui optimise plus au final.

            • [^] # Re: bidon

              Posté par  . Évalué à 2.

              Tout à fait d'accord sur la chauffe de la jvm.

              Je rajouterais, qu'en fait le mode client ou serveur défnit (entre autre) le nombre de passes néccessaires dans une portion de code pour compiler nativement ce code. Il est aussi possible de modifier cette valeur en ligne de commande.

              Au temps du 1.4.2 le mode serveur augmentait d'environ 10% le temps de démarrage ainsi que la consommation mémoire. ( la gestion de la mémoire ne se fait pas de la meme maniere )

              Maintenant, avec le 1.5, java n'offre malheureusement toujours pas le partage des jvm, mais propose néanmoins une "sorte" de préloading/partage des classes, permettant un démarrage plus rapide des applications ainis qu'une réduction de l'empreinte mémoire.

    • [^] # Re: bidon

      Posté par  . Évalué à 2.

      J'ai fait aussi mes benchmarks à 0.02 EUR, je confirme que java se rapproche de C++ en vitesse d'exécution. Des benchmarks "prouvent" que java va plus vite, mais bon ...

      Mais comme il s'agit d'une réflexion sur les langages, il serait intéressant de comparer les résultats d'un gcj réellement efficace à une jvm afin de comparer la perte (ou le gain ?) de performance induite par la jvm.

      Car, après tout, il serait intéressant de connaitre la véritable efficacité des programmes java, et non l'efficacité de la jvm, du garbage collector, et du bytecode intermédiaire.

      Je pense qu'encourager gcj est fondamental, car le langage java me plait, mais pas la jvm (ou plutot la réputation de la jvm). En plus, gcj est libre, ce qui est fondamental pour un compilo.

      D'après les benchmarks favorisant java par rapport à C++, le garbage collector serait plutôt favorable à la localité des données. Idem pour la compilation dynamique lorsqu'elle est stabilisée (lorsque la jvm est "chaude").

      <mode wish>A quand une possibilité de faire du java sérieusement en utilisant exclusivement du libre, avec toute l'API et les dernières fonctionnalités en date ?</mode>

  • # OCaml, oui mais...

    Posté par  . Évalué à 2.

    Je vois dans tous les commentaires ou presque des éloges sur OCaml. J'ai commencé ce langage en première année de prépa (MPSI option info), mais avec Caml-light, ce qui n'est pas si différent. Au début j'ai trouvé ça ignoble par rapport au C, et à tous les autres langages que je connais.
    Le problème d'OCaml c'est qu'il est un peu "rude" à apprendre, car trop différent des langages "impératifs", et oblige à pas mal de réapprentissage pour comprendre l'utilité de la récursivité, des variables non modifiables, et des filtrages. Passé cette étape, c'est en effet surement un des langages les plus agréable à utiliser, quoi que pour ce qui est de la POO je n'en ai pas l'expérience (en plus il peut être compilé ou compilé vers du bytecode, un peu comme Java). C'est pour ça que je pense qu'il ne s'imposera malheureusement pas.
    De plus, il reste encore quelques problèmes, en ce qui concerne les manipulations "bas niveau", ce n'est pas très aisé. Sans oublié le "problème" des entiers codés sur 31 bits au lieu de 32, ce qui est génant pour les opérations bas niveau.
    En somme, un bon langage, mais qui peut devenir génants dans certains cas (en plus du manque de bindings).

    • [^] # Re: OCaml, oui mais...

      Posté par  (site web personnel) . Évalué à 2.

      Si tu avais commencé à apprendre un langage fonctionnel, peut-être le trouverais-tu moins rude à apprendre. Un prof américain commence à apprendre les principes objet avant le procédural. Résultat : les étudiants ont du mal à comprendre le procédural ensuite.
      Quelqu'un a-t-il commencé à apprendre la programmation par autre chose que du procédural impératif ?
      Guillaume

      • [^] # Re: OCaml, oui mais...

        Posté par  . Évalué à 2.

        Un prof américain commence à apprendre les principes objet avant le procédural. Résultat : les étudiants ont du mal à comprendre le procédural ensuite.
        Quel langage utilise-t-il ?
        Une classe contenant uniquement une méthode est parfaitement équivalente à une fonction/procédure.

      • [^] # Re: OCaml, oui mais...

        Posté par  . Évalué à 2.

        > Quelqu'un a-t-il commencé à apprendre la programmation par autre
        > chose que du procédural impératif ?

        Fac de sciences Bordeaux il y a quelques années : pendant le DEUG le seul langage utilisé était SCHEME (langage fonctionnel). C'est peut-être toujours vrai...

        • [^] # Re: OCaml, oui mais...

          Posté par  . Évalué à 1.

          Oui, enfin ceux qui ont appris par eux même avant ont probablement appris un language impératif avant d'aller en fac..

          En prépas, on utilisait le Pascal et j'ai commencé par le BASIC.

          Maintenant ce serait plutôt le C, C++, Java, Shell ou Perl voire Ruby ou Python pour débuter.. tous des languages impératifs.

      • [^] # Re: OCaml, oui mais...

        Posté par  . Évalué à 1.

        deug mias, paris XI, j'ai fait du caml d'entree, apres du pascal, puis re caml.

        La premiere session caml a ete tres douloureuse, en plus, on nous faisait coder avec notepad... :( Le pascal est bien mieux passe, j'ai meme plutot bien trippe, et la seconde session caml, que du bonheur :)

      • [^] # Re: OCaml, oui mais...

        Posté par  (site web personnel) . Évalué à 4.

        oué enfin faut pas exagéré non plus, procédural et objet ne sont pas si fortement dissociés, les 2 sont complémentaires, c'est d'ailleur aussi un des succès de l'objet : sa transition avec le monde procédural est relativement "aisé" lorsqu'on compare à des méthodes beaucoup plus différentes comme la programmation déclarative.

        Quelqu'un a-t-il commencé à apprendre la programmation par autre chose que du procédural impératif ?
        Ben dans ma FAC ils ont (pas moi j'étais pas là au début) commencé par Scheme, pourtant on dit que l'on reste à nos premiers amours en matière de programmation, ben ils sont tous beaucoup plus productifs et heureux en codant en Java :)
        La notion d'objet est facile à appréhender par le programmeur qui peut "mapper" sa vision sur le monde réel. Bref c'est relativement intuitif (même si cela ne conduit pas toujours au meilleur design). Pour l'impératif, celui-ci a l'avantage de donner un seul ordre à la fois, dans un ordre précis qui est celui dans lequel le programmeur écrit : c'est donc très simple à appréhender (même si ce n'est pas forcement intuitif) et à utiliser.
        Par contre d'autres langages comme OCaml ou pire Prolog sont beaucoup plus difficile à appréhender car il demande une réflexion importante de la part du programmeur pour qu'il "ponde" le bon algo de manière conscise, sans parfois avoir la possibilité de décomposer le problème. C'est aussi ce qui fait la puissance de ces langages : il force le développeur à indiquer l'algorithme au compilateur/interprêteur qui peut alors en déduire plus d'information, conduisant parfois (souvent pour OCaml) à des optimisations qu'un compilateur plus traditionnel ne pourrait se permettre.

        • [^] # Re: OCaml, oui mais...

          Posté par  . Évalué à 3.

          Par contre d'autres langages comme OCaml ou pire Prolog sont beaucoup plus difficile à appréhender car il demande une réflexion importante de la part du programmeur pour qu'il "ponde" le bon algo de manière conscise, sans parfois avoir la possibilité de décomposer le problème.

          C'est une idée fausse hélas très répandue sur OCaml. OCaml est un langage multiparadigme, qui permet de travailler aussi facilement de manière fonctionnelle, impérative ou objets. Une des ses principales qualités est en effet justement de permettre au programmeur d'alterner et mélanger facilement ces trois styles de programmation en fonction des caractéristiques du problème qu'il traite.

          Mais dans l'enseignement, les différents dialectes de ML sont utilisés essentiellement (voire exclusivement, comme dans mon ancienne fac) pour familiariser l'étudiant avec le style de programmation fonctionnelle, d'où cette fausse image du langage.

          • [^] # Re: OCaml, oui mais...

            Posté par  (site web personnel) . Évalué à 2.

            C'est une idée fausse hélas très répandue sur OCaml.
            Non ce n'est pas une idée fausse, c'est mon idée tirée de mon expérience.
            Même si OCaml permet de programmer de plusieurs manière, je ne lui vois pas beaucoup d'intérêt si c'est pour l'utiliser de manière impérative. Je me trompes peut être mais à mon sens toute la puissance de OCaml réside dans le mixage objet/fonctionnel qui permet d'exprimer avec force ce qu'on veut faire, ce qui permet au compilo de faire tout pleins de déductions et d'optimisation. Cela dis je suis peut être complètement à côté de la plaque :)

            • [^] # Re: OCaml, oui mais...

              Posté par  . Évalué à 6.

              Ben même si tu te cantonnes à un style de programmation, tu disposes toujours du polymorphisme "for free", du typage statique, implicite et fort, des fonctions comme citoyens de 1ère classe du langage, du garbage collector, de la possiblité de générer du bytecode portable ou du code natif optimisé rapide, du système très puissant de modules, de l'héritage multiple, des closures, de la méta-programmation (avec MetaOcaml), d'un pré-processeur-pretty-printer très paramétrable, d'un support pour l'évaluation paresseuse, etc... qui sont d'autres caractéristiques (je ne dis pas "qualités") qui peuvent intervenir dans ton choix de langage.
              En ce qui me concerne, ce sont d'ailleurs généralement certaines d'entre elles qui me font opter pour OCaml. Et l'aspect multi-paradigme d'Ocaml me permet de tirer avantage de toutes ces caractéristiques sans être contraint à un style de programmation particulier.

              Pour préciser ce que je voulais dire sur le mélange des styles:
              la dernière fois que j'ai utilisé ce langage, c'était pour un problème pour lequel un algo impérativo-fonctionnel (ie un algo récursif avec des applications partielles, ainsi qu'un environnement qui varie au cours de l'algo) était beaucoup plus simple et rapide qu'une solution purement impérative (qui simule la récursivité avec une pile) ou purement fonctionnelle (où la gestion d'un environnement non modifiable compliquait l'algorithme). OCaml m'a permis d'exprimer cette fonction à style mélangé de manière très naturelle et efficace à l'exécution.

          • [^] # Re: OCaml, oui mais...

            Posté par  . Évalué à 1.

            Note que dans le bouquin en Français que j'ai lu pour essayer d'apprendre l'OCaml (sans y arriver), le style de programmation fonctionnel est largement mis en avant par rapport au style impératif, donc c'est un peu normal qu'OCaml soit perçu comme un language fonctionnel.

      • [^] # Re: OCaml, oui mais...

        Posté par  . Évalué à 1.

        Prépas Epita,
        En Sup, 6 mois de Caml en fonctionnel suivis de 6 mois de Pascal.
        En Spé, 6 mois de C et pour conclure 6 mois de Caml avec mélange de fonctionnel et d'impératif.

        Je pense que c'est une bonne approche de commencer par le fonctionnel, car bien que j'en ai deja fait au tout début, c'etait assez dur de s'y remettre en spé. Mais au bout de quelques temps ca devient un vrai bonheur (surtout comparé au C ). Et pour l'instant caml est mon langage préferé, le code que je ponds est jamais "gruik".

        Un amis a moi a fait une autre école d'informatique et ils ont commencé par du Visual Basic! je trouve cette orientation pedagogique assez moyenne, mais ici je n'ai pas besoin d'expliquer pourquoi je pense ;)

      • [^] # Re: OCaml, oui mais...

        Posté par  . Évalué à 1.

        1ere annee DEUG MIAS a Albi :
        Caml Light
        2eme annee DEUG GMI a Avignon :
        C++
        Scheme
        Assembleur x86

    • [^] # Re: OCaml, oui mais...

      Posté par  (site web personnel) . Évalué à 0.

      Ah, le Caml Light avec filtre (le tabac, c'est tabou ...) du Deug^WLicence1...
      Son typage fort qui fait chier à pas vouloir additionner un réel avec '2'... GRmblblbll

    • [^] # Re: OCaml, oui mais...

      Posté par  . Évalué à 1.

      des entiers codés sur 31 bits au lieu de 32

      Moi c'est ce point qui me gêne avec Ocaml. En calcule numérique intensif, je veux avoir les types du cpu (entier 32bits, entier signé 32bits, float, double). Toutefois, avec l'arrivée des processeurs 64bits, le type entier signé a 63bits. Mais, je crois qu'ils ont oublié cette aspect dans le design. Calculé en double a un coût non négligeable.

      • [^] # Re: OCaml, oui mais...

        Posté par  . Évalué à 1.

        Ce point n'est pas forcément le plus génant pour le calcul scientifique car il existe des lib de calcul en multiprécision, mais pour la programmation systeme c'est presque rédhibitoire. Comment je fais pour manipuler une adresse IP comme un entier? Pour remplir des champs d'un format de fichier binaire? C'est à mon sens le gros désavantage, du moins tant que OCaml ne tourne pas sur une machine 64 bits.
        Je crois que ce défaut est du au garbage collector que se sert du premier bit pour distinguer une valeur d'un pointeur, donc les performances de Caml semblent être liées à ceci (je me trompe peut-être, mais je crois me souvenir que c'est ça).

        • [^] # Re: OCaml, oui mais...

          Posté par  . Évalué à 1.

          Ce point n'est pas forcément le plus gênant pour le calcul scientifique car il existe des lib de calcul en multiprécision,

          Je parlais de calcule intensif. GMP c'est pas sérieux. Faut réfléchir un peu!

          • [^] # Re: OCaml, oui mais...

            Posté par  . Évalué à 1.

            Ba si c'est sérieux, car le calcul scientifique s'accomode TRES mal de la précision "à la louche" des processeurs x86 et autres PowerPC, car la plupart des systèmes physique sont chaotiques, et donc il est vain de vouloir faire des prédictions sur des float ou des double.
            J'ai déjà vu un exemple ou le simple fait de changer les parenthèses (en gros l'ordre des calculs) modifiait de façon considérable le résultat, c'était n cas du problème des N corps).

            • [^] # Re: OCaml, oui mais...

              Posté par  . Évalué à 4.


              car la plupart des systèmes physique sont chaotiques, et donc il est vain de vouloir faire des prédictions sur des float ou des double


              Et il est aussi vain de s'appuyer sur de la précision infinie car tout dépendra tellement des conditions initiales (because système chaotique) qu'on ne connait qu'à peu près de toute façon... et les nombres en précisions infinis devenant vraiment très précis (ie: très long et gros en mémoire et consommateurs de CPU) avec les pas de temps simulés, les pas de temps se simulent... de plus en plus lentement.

              Et utiliser des long_double_160, ne fera que repousser le problème qq pas de temps plus loin...

              Avant de faire du calcul numérique, on s'assure bien au moins que le schéma numérique est stable ? Que le modèle numérique respecte certaines propriétés physique ? Ou je suis à la masse ?

              Tout ça pour dire qu'il me semble que simulation numérique et systèmes chaotiques font assez mauvais ménage.

    • [^] # Re: OCaml, oui mais...

      Posté par  (site web personnel) . Évalué à 3.

      Je voudrai redescendre sur terre en rappellant que sur le marché du travail, au moins la moitié des développeurs ont un niveau BTS (et que le niveau BTS, je sais de quoi je parle, a un niveau très bas, ou tout élément théorique est absolument absent) et que beaucoup de ces pros ne sont même pas capable de programmer, conceptualiser en objet.

      Caml, langage que je vénère, est à des années lumière du monde de ces gens là qui est fait de VB, Vb.net, et autre Windev.
      Je ne suis même pas sûr qu'ils soient tous capables de développer en C#

      Vous faites tous partis d'une élite, vous êtes curieux, mais des développeurs comme vous, il y en a peu.
      Les gens auxquels je pense, ne comprendront jamais rien aux concepts qu'il y a derrière Caml, c''est beaucoup trop théorique pour eux.

      Caml est génial mais restera cantonné dans le milieu de ceux qui peuvent comprendre.

      « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

      • [^] # Re: OCaml, oui mais...

        Posté par  . Évalué à 2.

        Oui enfin, ... Je crois que ces gens là vont très vite être remplacé par des hindous ...Pour le prix d'un troufion, tu en a 20 là bas, et pas plus incompétent.

        • [^] # Re: OCaml, oui mais...

          Posté par  (site web personnel) . Évalué à 0.

          C'est vrai...
          ... Mais on peut difficilement remplacer un développeur chef de projet qui, au contact de l'entreprise cliente, peut analyser complètement et avec compétence les besoins, l'organisation, le métier de l'entreprise.

          Pour moi un Indien fera surtout de l'écriture de composants.

          Qui serviront aux troufions pour écrire leur logiciels.
          Ou alors ils nous feront le codage de la fonction toto...

          Ya donc des chance que ça se complémente à peu près

          « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

  • # Et vb.net ?

    Posté par  . Évalué à 1.

    Tiens c'est marrant, y'a pas visual basic .net dans les tests !

    m'embeterais-je donc avec ce language <put your adjective here> ?

    • [^] # Re: Et vb.net ?

      Posté par  (site web personnel) . Évalué à 1.

      La FAQ donne les conditions pour qu'un langage fasse partie du bench.
      Regarde http://shootout.alioth.debian.org/faq.php?sort=fullcpu#acceptable(...)
      Tu vas comprendre pourquoi :-)

      • [^] # Re: Et vb.net ?

        Posté par  (site web personnel) . Évalué à 1.

        Bah z'ont bien utilisé le compilo C# de mono, je vois pas pourquoi ils ne pouvaient pas faire de même avec le compilo VB.NET de Mono, parcque en lisant la FAQ le langage semble rentrer dans les critères "techniques", j'ai même envi de dire plus que le langage C qui n'a quasiment aucun "should have".

      • [^] # Re: Et vb.net ?

        Posté par  . Évalué à 0.

        "What kind of programming languages will you accept?

        Must have (...) A Debian package (either from Debian itself, or the primary authors of the language.) Or build and install with ./configure && make && make install and a default target of /usr/local."

        (...)

        "Why don't you include language X?

        Is the language … Free? (...) Open source? (...) Used? (...) Interesting? (...)

        We will accept and reject languages in a capricious, unfair, biased fashion.(...)"



        je ne veux pas être méchant, mais j'ai connu plus ouvert et plus exhaustif.

        • [^] # Re: Et vb.net ?

          Posté par  . Évalué à 3.

          Et il n'y a pas l'Objective-C alors qu'il respecte il me semble toutes les conditions demandées.

          Remarque sur du calcul pur l'Objective-C c'est du C donc...

  • # constance des résultats, qualité du benchmark

    Posté par  . Évalué à 5.

    Ce qui plaide pour la qualité de ce benchmark, c'est que le classement change très peu d'un test à l'autre.
    On obtient la plupart du temps un classement à peut près identique. Donc dans l'ensemble, il y a bien quelque chose de relativement constant qui s'en dégage ...

    Par exemple on aura beau dire que l'implem d'un algorithme pur ne ressemble jamais à un programme réel, où les résultats seraient très différents, le fait qu'Ocaml performe très bien sur tout les algos (qui sont très différents les uns des autres) permet quand même de penser qu'Ocaml est un langage très rapide (et l'inverse pour PHP).

    • [^] # Re: constance des résultats, qualité du benchmark

      Posté par  . Évalué à 1.

      Bof ! Il pourrait y avoir des erreurs systématiques.
      1+1=3, 1+2=4, 1+3=5. Conclusion: comme à chaque fois que je rajoute 1, je trouve 1 de plus, c'est que l'addition doit être bonne.

      En physique, c'est le genre d'erreurs qui peuvent être trés difficiles à déceler.

  • # Ada answers

    Posté par  . Évalué à 2.

    ...
    > J'espère que leur présence en tête de classement incitera plus de développeurs à la curiosité.
    ...
    > Je n'en suggère qu'une seule : méfions nous des préjugés !

    La communauté du Logiciel Libre possède depuis l'arrivé du compilateur Ada libre GNAT une merveilleuse corde _de plus_ à son arc.


    let's go for Ada :

    http://www.gnat.com/aa_videos.php(...)

    --
    korek ça !

    • [^] # Re: Ada answers

      Posté par  . Évalué à 2.

      c'etait pas bien gcc-ada ?

    • [^] # Re: Ada answers

      Posté par  . Évalué à 3.

      Ada est vraiement un langage interessant, mais en définitive assez difficile a appréhender. Par exemple, ses paradigmes objets ne sont pas classiques par rapports aux autres langages.

      La compilation est tres facile, et il est tres strict quand a la déclarations des variables et la vérification de leur type. Par contre, ce qui est plus gênant, c'est le manque de bindings (par exemple pour XSLT), et le manque de ressources d'aide sur le web...

      • [^] # Re: Ada answers

        Posté par  (site web personnel) . Évalué à 2.

        Par exemple, ses paradigmes objets ne sont pas classiques par rapports aux autres langages.

        Tout à fait d'accord, c'est le point le plus inhabituel du langage.
        Mais d'un autre coté, il offre tellement de caractéristiques uniques.

        Au hasard, quel plaisir d'avoir un tasking complètement intégré dans le langage : pouvoir définir des types taches pas plus dificilement qu'une classe, déclarer un tableaux de 500 taches, etc.
        Tout ça de façon portable, sans faire appel à la moindre API externe.

      • [^] # Re: Ada answers

        Posté par  (site web personnel) . Évalué à 3.

        Par contre, ce qui est plus gênant, c'est le manque de bindings (par exemple pour XSLT), et le manque de ressources d'aide sur le web...

        Pour les bindings, c'est vrai.

        Pour atténuer celà, on peut rappeler que l'interfaçage en général et l'interfaçage avec C en particulier est facile.
        J'avais un collègue qui n'a pas hésité à faire vite fait un binding à xerces, pour gagner 20 secondes au chargement d'un gros fichier xml par rapport à xmlada, sur un outils sans importance.

        Pour les ressources web, il y a http://www.adapower.com/(...) et http://www.adaworld.com.(...)
        Tu y trouves pas mal de chose comme des exemples de code, ou plusieurs livres sur Ada sous license libre.
        (J'ai un bon souvenir de Ada Distilled)

        Sur http://libre.act-europe.fr/,(...) en dehors des composants, il y a des cours très interessants en français.

        Sinon, pour avoir de l'aide : http://www.ada-france.org/article13.html(...)

    • [^] # Re: Ada answers

      Posté par  . Évalué à 3.

      une caractéristique un peu oubliée par l'article concerne les bases théoriques derrière ces language.

      Pas besoin d'un cours de théorie des types, de théorie des languages ou de la compil' bien sûr, mais juste pour dire que ADA est un très bon language (pour plein de raisons pratiques) mais qu'il est un peu bâti sur du sable au niveau théorique.

      A l'inverse, OCaml a été conçu A PARTIR des résultats de recherche théorique. Par exemple, la structure de typage de Caml a été prouvée (en gros une démonstration logique et mathématique avec beta-réductions à la pelle de 300 pages) et ça a de grosses conséquances sur la génération de code sûr (au sens de la sûreté de fonctionnement) pour des missions critiques comme les codes embarquées par exemple. Les autres méthodes de code sûr pour ce genre de tâches (Lustre et Esterel pour ne pas les citer) ont d'autres avantages mais ne servent jamais qu'à générer du code C à recompiler derrière.
      ... et puis l'inférence de types, le garbage collector TRES bien fait (oui, c'est toujours possible de faire mieux à la main, mais c'est pas facile)... tout un tas de trucs qui font de OCaml un outil très bien fait.

      • [^] # Re: Ada answers

        Posté par  (site web personnel) . Évalué à 2.

        ça a de grosses conséquances sur la génération de code sûr (au sens de la sûreté de fonctionnement) pour des missions critiques comme les codes embarquées par exemple. Les autres méthodes de code sûr pour ce genre de tâches (Lustre et Esterel pour ne pas les citer) ont d'autres avantages mais ne servent jamais qu'à générer du code C à recompiler derrière.

        Oui, Ada n'a pas de définition formelle, mais c'est quand même un des rares langages dont la définition soit à la fois suffisement complète et non ambigu pour que l'on puisse en extraire des sous-ensemble prouvable formellement, sans dépendance au compilateur.

        Pour les autres langage de ce type, les outils doivent compenser les trous de sémantiques de la définition du langage par la connaissance du comportement constaté du compilateur. C'est vrai par exemple, même pour un sous-ensemble de C comme MISRA-C, pourtant spécifiquement dédié à ces applications critiques.

        Si celà t'intéresse, actuellement un produit original nomé SPARK fait une percée remarquée dans le monde de la preuve formelle Ada : http://www.praxis-his.com/sparkada/intro.asp(...)

        Quoi qu'il en soit, le marché des applis embarqués critiques est justement LE marché dominé par Ada.

      • [^] # Re: Ada answers

        Posté par  . Évalué à 2.

        Peut être bien mais Ada reste le langage de référence dans les apps embarquées et critiques, ce qui semble à priori être paradoxal au vu du background théorique dont tu ne parles. Une explication??

        • [^] # Re: Ada answers

          Posté par  . Évalué à 0.

          Ada a été conçu pour l'armée américaine il y a bien longtemps, et avoir toute l'armée US qui l'utilise ça donne pas mal de crédibilité (du point de vue des décideurs pressés au moins). De plus Ada est plus proches des autres langages, comme le Pascal par exemple.
          Au contraire OCaml est un travail d'universitaire, qui a commencé bien plus tard, et qui n'était au début qu'un langage de recherche, avec de faibles performances.
          Le côté orienté objet est relativement récent, et donc ceci explique sa faible pénétration (le poids des années, par exemple le code d'ariane 5 écrit en Ada vient en grande partie de celui d'ariane 4, donc des annés 80).
          Et puis, c'est franco-français!

          • [^] # Re: Ada answers

            Posté par  . Évalué à 1.

            Merci pour vos lumiéres sur le sujet, même si ma question était orientée plus par une méconnaissance de Ocaml que du langage Ada.J'ai pratiqué ce dernier il y'a bien longtemps, vers 85 à mes débuts.
            Par contre comme ton post l'indique c'est en effet une équipe américaine sous la direction de John Barnes il me semble, qui a entrepris, sur les bases du pascal, l'écriture de Ada.Il se devait de remplacer des langages comme le Corla 66 ou RTL/2 ( non pas la radio :p ) pour la programmation de missiles et autres produits industriels.Mais je vais de ce pas voir ce que ça donne le Ocaml, car pour parler franchement,j 'en ai vaguement entendu parler mais je trouve sa conception intriguante pour le moins :))...Mais comme je dis toujours la curiosité est l'antre de la sagesse, n'est ce pas??

            • [^] # Re: Ada answers

              Posté par  (site web personnel) . Évalué à 4.

              (Je réponds aux deux mails précédents)

              Non, Ada n'a pas été conçu par l'armée américaine. L'armée américaine a juste fait le constat de ce qu'elle utilisait (au début des anées 70) 450 langages différents, et que c'était un gouffre financier. Certains corps d'armées c'atait fait vendre un langage temps réel propriétaire, avec un seul compilateur, tournant sur un hardware spécifique. Le rêve de tout fournisseur, un client vérouillé!

              Le DOD américain a donc réunit un collège d'expert, ouvert sur le civil et l'étranger (une grande première alors), pour faire non pas un langage mais un cahier des charges d'un langage.
              Le cahier des charges mettait l'accent sur quelques points, comme une certaine universalité et la prise en compte des problème de génie logiciel apparaissant alors sur l'écriture des premier gros logiciel.

              Ensuite, 5 équipe ont présenté leur travail, et c'est l'équipe verte, dirigé par Jean Ichbiah qui a gagné.

              Ada est né ainsi, de parents civils, en gagnant un concours militaire.

              • [^] # Re: Ada answers

                Posté par  . Évalué à 1.

                Mea culpa , en effet comme tu le dis l'équipe Ada etait bien dirigée par J.D Ichbiah. John Barnes n'en est pas moins un des concepteurs clefs de ce langage et le moteur d'une de ses révisions majeur dés 79.Suite à ses critiques pleines de lucidité sur les tâches.Ce qui fait de Ada le langage qu'on connait aujourd'hui.

          • [^] # Re: Ada answers

            Posté par  . Évalué à 0.

            "franco-français", dans tous les domaines qui me viennent à l'esprit, c'est plus un inconvénient qu'un avantage...

            On s'en rendra vite compte quand le non aura gagné...

        • [^] # Re: Ada answers

          Posté par  . Évalué à 1.

          ADA est le language de références pour les applications embarquées critiques pour 2 raisons :

          - La première est historique et est détaillée dans le postes autour de celui-ci : conçu pour l'armée dans ses tâches critiques (missiles...)

          - L'autre est plus floue : à partir d'une conception / spécification bien faite (hyper exhaustive surtout) on peut écrire facilement tout un tas de contraintes (notament sur les types) et faire une bonne génération de code. Ca rends effectivement le code plus sûr à nos yeux, surtout parce qu'on "voit" une structure solide.
          ...enfine c'est mon avis. j'ai fait que qques mois d'ada, c'est pas vraiement assez (et de loin !) non plus pour se prétendre expert.

  • # Bench complètement pourri. Y a pas Ook!

    Posté par  . Évalué à 3.

    A partir du moment ou il manque 'Ook!' je ne vois pas comment le bench peut-être qualifié de sérieux.

    http://www.dangermouse.net/esoteric/ook.html(...)

    Qu'on ne vienne pas me dire que ce langage manque de bibliothèques ...

  • # SmartEiffel

    Posté par  (site web personnel) . Évalué à 7.

    Les performances de Smart Eiffel sont dus à la suppression de la liaison dynamique.

    Dans tous les langages objets, l'accès à une méthode spécialisé sur plusieurs classes dans l'arbre d'héritage se fait par une liaison dynamique, plus exactement une VFT (Virtual Function Table).

    En gros, on a une structure avec un pointeur sur fonction que l'on peut parfois mettre dans un tableau.

    En assembleur ça donne des trucs du genre "call dword ptr [_adresse_de_la_fonction]", ce qui implique :

    - Que l'inlining est très limité
    - Que le processeur est obligé de vider son cache mais aussi de laisser tomber toutes ses prédictions de branchements.

    Donc une chute des performances.


    A ma connaissance, tous les langages objets sauf (Smart) Eiffel et Lisaac fonctionnent comme ça.


    Avec l'algorithme du produit cartésien de Ole Agesen et Craig Chambers (à peu près innaplicable), l'algorithme de Dominique Colnet est le premier à réussir à supprimer la liaison dynamique.
    Un algorithme de prédiction de type détermine les types possibles pour le receveur et les paramètres, ce qui donne lieu à un switch afin de traiter chaque cas.
    En plus, on peut enfin faire de l'inlining et de la spécialisation de code.

    Le problème de Smart Eiffel, c'est qu'il traite tous les cas de résolution de type, même ceux, qui, dans le code tel qu'on le possède ne pourront jamais survenir.

    Lisaac est le premier compilateur à analyser tout son code et de déterminer les types possibles et de ne traiter qu'eux seuls.
    Ca permet d'éviter plus de 84 % de switch.

    L'inlining est encore facilité, ainsi que la spécialisation de code.
    Résultat, un décodeur Mpeg1/2 algorithmiquement identique à un décodeur C, est plus lent de 1,9 % (pour 30 % de code en moins, langage objet de haut niveau oblige).

    L'avenir est à mon avis aux langages objets dont le compilateur est doté d'un algorithme de suppression de la liaison dynamique.

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: SmartEiffel

      Posté par  . Évalué à 2.

      Hummm...

      Ça m'a l'air tout bonnement très intéressant cette petite gâterie compilatoiresque.

      Doc ?
      Parce que [1] date quand même un petit peu, non ?

      [1] : http://smarteiffel.loria.fr/papers/oopsla97.pdf(...)

    • [^] # Re: SmartEiffel

      Posté par  . Évalué à 4.

      L'avenir est à mon avis aux langages objets dont le compilateur est doté d'un algorithme de suppression de la liaison dynamique.

      L'avenir est aux langages permettant un développement rapide, facile et fiable, pas le gain de quelques % sur la rapidité d'exécution d'un décodeur MPEG...

      • [^] # Re: SmartEiffel

        Posté par  (site web personnel) . Évalué à 1.


        L'avenir est aux langages permettant un développement rapide, facile et fiable


        Eiffel et Lisaac donc

        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

        • [^] # Re: SmartEiffel

          Posté par  (site web personnel) . Évalué à 0.

          ou OCaml (ou plein d'autres qui ont leurs avantages et leur inconvénients)

          • [^] # Re: SmartEiffel

            Posté par  (site web personnel) . Évalué à 1.

            Comme je l'ai dit plus haut, les indéniables avantages de Ocaml sont ce qu'ils sont, mais moins 10 % des développeurs sont capable de le maitriser, alors que des langages comme Lisaac ou Eiffel, tu en as 30 % peut être.

            « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

            • [^] # Re: SmartEiffel

              Posté par  . Évalué à 0.

              Errfff et moi qui comptais m'y mettre, je sens que ça ne va pas être une partie de plaisir :)))) loooooooooool

            • [^] # OCaml (difficulté d'apprentissage)

              Posté par  . Évalué à 3.

              Faut quand même pas exagérer... Ce qui fait que OCaml a cette réputation de "langage difficile" c'est :

              - la plupart du temps il ne ressemble pas aux langages que les programmeurs connaissent. Ils sont habitués à passer d'un langage impératif à l'autre sans trop de difficulté, et là forcément c'est plus éloigné,

              - les élèves apprennent souvent Caml dans un cours de programmation fonctionnelle où le prof leur parle de lambda-calcul. L'accent est mis sur l'aspect fonctionnel, et tout ce que l'on peut faire de tordu (et de génial) avec. Mais Caml est aussi un langage impératif que l'on peut utiliser sans aucun problème comme tel, et c'est aussi un langage objet sans imposer les objets.

              - OCaml est un langage multiparadigme. En java il suffit de maîtriser les objets et on ne se pose pas la question de les utiliser ou pas. Si l'on veut maîtriser "tout" OCaml, il faut connaître la programmation objets, mais aussi fonctionnelle, et il y a aussi des tas de notions auxquelles on n'est pas habituées (inférence de types, préprocesseur, etc)

              Et il ne faut pas oublier que tout ce qu'apporte Caml permet de programmer beaucoup plus sûrement que la plupart des autres langages, ce qui signifie que le travail de débogage sera énormément réduit. Quand on a l'habitude de programmer en Caml, on a du mal à revenir vers le C ou tout autre langage moins évolué...

              • [^] # Re: OCaml (difficulté d'apprentissage)

                Posté par  (site web personnel) . Évalué à 2.

                Je crois que tu vie dans un monde d'universitaires et/ou d'ingénieurs.

                Je suis en train de terminer un BTS (honte à moi, oui), et j'ai eu autour de moi des élèves de niveau BTS pendant deux ans. Je peux te dire qu'ils ne seront jamais capable, à moins d'un miracle, de comprendre Ocaml. Enfin si, ils seraient "cérébralement "capables, mais ils sont incapable de faire l'effort, ça les interessera jamais.

                Ce sont des gens qui ont du mal à maîtriser le concept de fonction, au niveau théorique. Ils ont beaucoup de mal à appréhender la programmation objet.
                Ils ont déjà beaucoup de mal en algorithmique. C'est le seul point que leur expérience professionnelle améliorera.

                La récursivité, c'est beaucoup trop difficile pour eux, ça les décourage.

                Je n'ai pas cotoyé des gens stupide, loin de là, mais ils ne sont absolument pas curieux du tout.
                Donc il feront du VB.net et des trucs de ce genre, ils vont mettre des années à comprendre l'objet.

                Un bon langage pour eux, c'est VB6 et windev, voire Delphi pour l'élite (ya des pointeurs en delphi attention, et puis c'est objet Delphi !!)
                Evidemment, Linux ils ne veulent pas en entendre parler. La ligne de commande leur fait peur et ça les obligerai à comprendre le système.

                Mais déjà leur faire un avaler un truc du genre

                let rec fact = function n -> if n=0 then 1 else n*fact(n-1);;

                désolé, mais j'y crois pas.

                Pour te donner une idée du niveau, ils ont mis deux jours à comprendre comment programmer une pile avec des pointeurs, dans un langage algorithmique style Pascal en français.
                Deux jours plein, deux jours à 7 heures de cours par jour (!!!).
                En deuxième année qui plus est, donc avec 1 ans de programmation derrière eux...

                Des gens comme ça, il y en a plein, je ne suis pas certain que le développement soit leur point fort, ils sont surement plus compétent dans d'autres domaines.

                Mais je répète ma conviction : Ocaml est réservé à un élite.

                Pour le reste, je suis totalement d'accord avec toi : Des gens ouvert et capable d'appréhender l'embryon de théorie absolument nécessaire et motivé pour s'y mettre peuvent très bien le faire.

                Mais quand tu sais qu'il y a plein d'entreprises qui choississent de ne pas utiliser J2EE parce que leur dev ne maîtrisent pas l'objet, tu te demande qui il reste poua apprendre un tel langage.

                « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                • [^] # Re: OCaml (difficulté d'apprentissage)

                  Posté par  . Évalué à 1.


                  Mais déjà leur faire un avaler un truc du genre
                  let rec fact = function n -> if n=0 then 1 else n*fact(n-1);;
                  désolé, mais j'y crois pas.


                  Ah oui alors là c'est grave. Mais tu as sûrement raison je suis un peu décalé d'une certaine réalité.

                  Cependant, je doute qu'il soit vraiment plus facile d'apprendre les pointeurs en C. Et quitte à faire des trucs genre visual basic, alors autant les faire sur de bonnes bases. Un «Visual Caml» tu achèterais ?

                  • [^] # Re: OCaml (difficulté d'apprentissage)

                    Posté par  . Évalué à 1.

                    Mais pourquoi pas Gambas plutôt cela le serait plus proche (sans partir dans du Caml donc) et au moins cela serait libre.

                    • [^] # Re: OCaml (difficulté d'apprentissage)

                      Posté par  . Évalué à 1.

                      Non parce que Gambas est basé sur BASIC qui est un langage complètement archaïque...

                      OCaml intègre beaucoup de choses très modernes qui sortent de la recherche sur les langages de programmation...Le basic ou le C datent d'une époque où l'on ne comprenait pas encore bien ce que l'on faisait. Caml ou Java font les choses beaucoup plus proprement. Ce qui réduit considérablement le nombre de bugs possibles dans les programmes ! (et même si c'est caché par une interface graphique, l'ensemble sera plus stable).

                      Et je ne connais pas d'autre langage que OCaml qui concentre dans un seul langage un si grand nombre de caractéristiques très avancées. (Java est tout objet, Python a de très gros défauts, Haskell n'est pas utilisable à taille réelle, etc.)

                      Et OCaml est libre aussi...

                      • [^] # Re: OCaml (difficulté d'apprentissage)

                        Posté par  . Évalué à 4.

                        > le C datent d'une époque où l'on ne comprenait pas encore bien ce que l'on faisait

                        Arf, faut que j'en parle à Denis Ritchie ... ;)

                      • [^] # Re: OCaml (difficulté d'apprentissage)

                        Posté par  . Évalué à 1.

                        Et je ne connais pas d'autre langage que OCaml qui concentre dans un seul langage un si grand nombre de caractéristiques très avancées. (Java est tout objet, Python a de très gros défauts, Haskell n'est pas utilisable à taille réelle, etc.)


                        Quels sont les 'très gros défauts' de python? Compare a OCaml, il est moins type, mais est-ce un gros defaut? Je considere juste cela comme une difference.

                        Et, juste pour m'informer, qu'est-ce qui rends Haskell inutilisable ?

                  • [^] # Re: OCaml (difficulté d'apprentissage)

                    Posté par  (site web personnel) . Évalué à 2.


                    Cependant, je doute qu'il soit vraiment plus facile d'apprendre les pointeurs en C.


                    C'est marrant tu met exactement le doigt sur un autre problème ;-)

                    Nous avons eu un projet C à rendre, le prof nous a demandé, en 3 semaines, d'écrire un mini interpréteur basic.

                    Sur 15 élèves de la promo (bts en alternance), seul 4 l'ont rendus. Les autres ont protestés, arguant que c'était "trop difficile, on ne comprend rien".

                    Je pense qu'un Caml habillé d'un bon environnement de développement avec la possibilité de le coupler avec pas mal de technos existante serait interessant. Il serait interessant que cet environnement de dev soit multi-langage de sorte à utilser caml sur des choses vraiment interessantes (traitement de données) et de laisser la tuyauterie technique (iUH) pour des langages plus conventionnels.
                    Après c'est une question de goût.

                    Un visual caml, j'acheterais.
                    Mais j'utilise caml quand je peux. En fait j'attend de récupérer le bouquin de Weiss et Leroy dont une nouvelle édition va peut être sortir afin de m'y mettre une seconde et dernière fois pour toute :)

                    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                    • [^] # Re: OCaml (difficulté d'apprentissage)

                      Posté par  . Évalué à 1.

                      Moi aussi j'ai une anecdote : en cours de compil, on devait implémenter un compilo et on avait le choix du langage pour écrire le compilo. 4 groupes ont choisi OCaml, 3 ont choisi C et 1 java. à la fin il y avait seulement 4 compilos qui tournaient. (Je vous laisse deviner lesquels ;-)

                      (Perso je préfère le bouquin de Chailloux Manoury Pagano chez O'Reilly que je trouve plus grand public mais bon.)

                      • [^] # Re: OCaml (difficulté d'apprentissage)

                        Posté par  (site web personnel) . Évalué à 2.

                        Voilà, tu vis avec gens qui savent ce qu'est un compilateur. Mes camarades ne savaient pas ce que c'est (à part quelques uns heureusement).

                        Tout ce qu'il veulent savoir, c'est sur quel bouton cliquer....

                        Je pense que 50 % des devs sont à ce niveau, et sachant que les jeunes de 20 ans qu'on forme maintenant sont des "enfants de win95" ils n'ont jamais été confronté à un pc bien frustre, où il fallait tapper en basic, ou en ligne de commande.

                        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

                      • [^] # Re: OCaml (difficulté d'apprentissage)

                        Posté par  . Évalué à 3.

                        Oui, mais d'un autre coté dans la vrai vie, on a plus souvent a écrire des GUI que des compilos.
                        Et là, l'intéret des language fonctionnels..
                        [ oui, je sais, Ocaml est soi-disant un language multi-paradigme, et la marmote.. ]

                        Et il faut que ce soit dans un language répandus pour être maintenable en équipe..

                        Faut arréter de croire que ce qui est valable à l'école est valable dans la "vraie vie"..
                        Bonne chance pour convaincre ton patron d'utiliser OCaml plutôt que C, C++, Java quand tu es le seul de l'équipe à connaitre!
                        Si tu code un compilo, tu as probablement un bon argument (et encore!), mais à part ça..

                        Je viens de lire la spec de Lissac (évoqué plus haut), et j'étais mort de rire:une syntaxe, euh comment dire, pas terrible..
                        Par exemple un retour au déclaration de variables uniquement au début d'une fonction, pas au milieu; etc..

                        J'imagine un gars programmant en Python ou Ruby auquel on dit de programmer en Lissac, il doit avoir envie de se cogner la tête contre les murs assez rapidement..

                        • [^] # Re: OCaml (difficulté d'apprentissage)

                          Posté par  . Évalué à 2.

                          L'exemple que tu donnes me parait ridicule.

                          À la limite « devoir déclarer des variables... ». Oui, déclarer des variables,
                          c'est chiant et un langage typé permet d'inférer les type.

                          Mais déclarer une variable au milieu du code, c'est le comble de
                          l'illisibilité.

                          • [^] # Re: OCaml (difficulté d'apprentissage)

                            Posté par  . Évalué à 3.

                            Pas d'accord et je ne dois pas être le seul à apprécier de pouvoir déclarer une variable quand je veux: C++ basé sur le C l'a ajouté et cela a été ajouté dans le C aussi en 99!

                            Imagines que tu ai une fonction ou tu n'utilises une variable que dans une partie de la fonction, si c'est à la fin, il va falloir faire des aller-retour dans ta fonction pour voir comment elle est initialisée pour être sûr que cette partie de la fonction est correcte: super pour la lisibilité les aller-retour.

                            Certes les fonctions sont censée être courte, mais bon celui qui n'a jamais codé une fonction qui prend deux écrans de haut me jette la première pierre ;-)

                            • [^] # Re: OCaml (difficulté d'apprentissage)

                              Posté par  . Évalué à 0.

                              Tu peux declarer ta variable au debut de la fonction et l'initialiser ou tu en as besoin. Il n'y a pas de probleme.

                              C'est surtout que ca fait bizarre quand tu as pris l'habitude de l'inverse. Quand je suis passe du C++ au C, je me suis dit que le compilateur etait debile (au debut seulement). Ne pas oublier: le compilateur est ton ami! :) S'il dit que tu as faux, il y a 99.99% de chances que ce soit le cas (si c'est pas plus).

                              • [^] # Re: OCaml (difficulté d'apprentissage)

                                Posté par  . Évalué à 3.

                                > Tu peux declarer ta variable au debut de la fonction et l'initialiser ou tu en as besoin. Il n'y a pas de probleme.

                                Bien sur, mais la variable elle a quelle valeur entre le moment ou tu l'as déclaré et au moment ou tu l'initialise?

                                Si par erreur tu lis cette variable avant de la definir reellement, le resultat est un bug aléatoire: suivant les exécutions ta variable non-initialisée peut avoir des valeurs différentes..

                                Les bugs aléatoire, non reproductible sont particulièrement "interressant" quand on cherche a debugger..

                                C'est plus propre de déclarer et d'initialiser la variable à l'endroit ou tu l'utilise..
                                Ce qui est possible aussi en C99.

                                Certes la liste des variables locales dans une fonction devient plus difficile a obtenir, mais ce n'est pas une grosse perte.

                                • [^] # Re: OCaml (difficulté d'apprentissage)

                                  Posté par  . Évalué à 2.

                                  Bien sur, mais la variable elle a quelle valeur entre le moment ou tu l'as déclaré et au moment ou tu l'initialise?

                                  Si par erreur tu lis cette variable avant de la definir reellement, le resultat est un bug aléatoire: suivant les exécutions ta variable non-initialisée peut avoir des valeurs différentes..

                                  C'est marrant j'ai jamais eu le probleme. Peut-etre parce que je lis les warning du compilo et que quand il me dit qu'il y a ce probleme je le corrige.

                          • [^] # Re: OCaml (difficulté d'apprentissage)

                            Posté par  . Évalué à 2.

                            Mais déclarer une variable au milieu du code, c'est le comble de
                            l'illisibilité.
                            oula!!
                            on va pas etre d'accord.

                            quand je declare une variable intermediaire dans une boucle, je ne veux pas qu'elle soit visible en dehors de ladite boucle.
                            genre un

                            for (Iterator it = list.iterator; it.hasNext();){
                            Integer next = (Integer) it.next();
                            }

                            ou un :

                            Iterator it;
                            Integer next;
                            for(it=blabla){
                            next=(Integer) blabla;
                            }


                            lequel comporte le plus de bruit?

                            la meme chose pour un bloc try/catch.

                            pis ca me parait plus comprehensible de declarer les variables au fur et a mesure de leur apparition que de me farcir un bloc de 15 lignes de variables en debut de fonction dont je n'ai aucune idee quand a leur utilite..

                            on va dire que ca depend de ce qui est code et du besoin d'optimisation

                            • [^] # Re: OCaml (difficulté d'apprentissage)

                              Posté par  . Évalué à 2.

                              Parce que tu penses vraiment qu'il est normal, dans l'exemple que
                              tu donnes que le compilo ne puisse pas se rendre compte tout
                              seul que dans

                              for(it=blabla){
                              next=(Integer) blabla;
                              }

                              next DOIT être un Integer?

                              D'où ma remarque sur l'inférence de type.

                              Et si tu me réponds que des fois, c'est ambigüe
                              genre tu prends

                              fonction toto(x,y)=x+y;

                              Or, dans ton langage, + est surchargé et peut-être le plus
                              sur des entiers, le plus sur des flotant, la concaténation sur
                              des listes...

                              Ben je te réponds que ta fonction doit pouvoir fonctionner avec
                              des entier, des flotants et des listes.

                              • [^] # Re: OCaml (difficulté d'apprentissage)

                                Posté par  . Évalué à 2.

                                oula!!
                                mais cette fois on va etre d'accord :)
                                c'est pas a moi qu'il faut demontrer l'interet de l'inference de types, tu preches un convertit, surtout qu'en tant que developpeur java pas encore passe au 1.5, je suis le premier emmerde par ce genre de joyeusetes (et biiim!! un ClassCastException en pleine face, ca m'apprendra a preciser exactement ce que je met dans mes listes dans les tags javadoc, tiens).

                                je rebondissais sur la remarque comme quoi la declaration de variables au milieu d'une fonction etait illisible.

                                J'aime beaucoup caml, et ya pas mal de ses features que j'aimerais pouvoir utiliser au quotidien : inferences de type, fonctions de fonctions, pattern matching (raaaaah chaque fois que j'ecris un switch case, ca me fait mal au coeur rien que d'y penser) et autres trucs qui ont du se ranger au fond de memoire (de poisson rouge), mais voila quand je parle de caml au taff, une etincelle au fond des yeux et des tremolos plein la voix, on me regarde avec un air genre "l'est mignon l'ingenieur fraichement diplome avec ses belles idees sur la technologie".

                          • [^] # Re: OCaml (difficulté d'apprentissage)

                            Posté par  . Évalué à -1.

                            Pas d'accord et je ne dois pas être le seul à apprécier de pouvoir déclarer une variable quand je veux: C++ basé sur le C l'a ajouté et cela a été ajouté dans le C aussi en 99!

                            Imagines que tu ai une fonction ou tu n'utilises une variable que dans une partie de la fonction, si c'est à la fin, il va falloir faire des aller-retour dans ta fonction pour voir comment elle est initialisée pour être sûr que cette partie de la fonction est correcte: super pour la lisibilité les aller-retour.

                            Certes les fonctions sont censée être courte, mais bon celui qui n'a jamais codé une fonction qui prend deux écrans de haut me jette la première pierre ;-)

                        • [^] # Re: OCaml (difficulté d'apprentissage)

                          Posté par  . Évalué à 3.

                          une syntaxe, euh comment dire, pas terrible..
                          Par exemple un retour au déclaration de variables uniquement au début d'une fonction, pas au milieu;

                          C'est vrai ça. On ne peut pas foutre le bordel comme on veut ! C'est même carrément castrateur comme procédé !

                          • [^] # Re: OCaml (difficulté d'apprentissage)

                            Posté par  (site web personnel) . Évalué à 3.

                            ben à la rigeur je vois un cas ou ça peut être pratique de ne pas être forcé de déclarer ces variables dans une zone spécifique. par exemple, au détour d'un code, devoir faire un :
                            for(int i = 0; i < maval ; i++)

                            Bon, à part ça, je vois pas grand chose (en fait pour les variables n'ayant qu'une utilitée ponctuelle)

                            Mais bon, peut-être que si toutes les vars sont groupées, ça donnera peut-être plus de cohérence et plus de variables commentées, car ça manque dans pas mal de prog...

                            Mais je préfère pour ma part largement un langage qui oblige à déclarer les variables qu'un programme ne comportant pas de déclaration du tout.
                            Car beaucoup de langages non ou faiblement typés permettent quand même la déclaration des variables (perl, php, asp, ...) et lire un prog de ce genre sans aucune déclaration c'est très énervant (et malheureusement j'en ai tous les jours :'( )

                        • [^] # Re: OCaml (difficulté d'apprentissage)

                          Posté par  . Évalué à 3.

                          Oui mais si l'on n'utilisait que les vieux trucs dépassés sous prétexte que tout le monde les utilise, les gens utiliseraient toujours windows.

                          (Ah euh on m'indique dans l'oreillette que les gens utilisent toujours windows et C...)

                          • [^] # Re: OCaml (difficulté d'apprentissage)

                            Posté par  . Évalué à 2.

                            Je ne dis pas rester sur les languages existant, mais quand on crée un language, pour certains élément se baser sur C plutôt que sur Pascal (par exemple) me paraît une bonne idée étant donnée le nombre d'utilisateurs respectif de chaque langage..

                            Par exemple, utiliser CHARACTER comme nom de type à la place de char, je ne suis pas sûr que ce soit une bonne idée..

                            Quand il y a ammélioration, c'est sûr qu'il ne faut pas hésiter, mais la ou cela apporte peu d'intéret autant garder l'existant.

                            Ce sont des petits détails, mais ça compte pour "attenuer" la transition..

                    • [^] # Re: OCaml (difficulté d'apprentissage)

                      Posté par  . Évalué à 1.

                      Sur 15 élèves de la promo (bts en alternance), seul 4 l'ont rendus. Les autres ont protestés, arguant que c'était "trop difficile, on ne comprend rien".


                      en meme temps si ils avaient taffer au lieu de protester c'est sur ca aurait pas été plus dur.

                      • [^] # Re: OCaml (difficulté d'apprentissage)

                        Posté par  (site web personnel) . Évalué à 1.

                        C'est ce que les adultes autour d'eux ont pensés, et pour ceux qui faisaient partis de l'encadrement, leur ont expliqué.

                        Mais que veux-tu, à 20 ans maintenant certains ont un age mentale de 15...

                        Tu as beaucoup de développeurs comme ça. Ils font leur 35 h, ils se satisfassent de VB ou Windev, et ils ne veulent pas aller plus loin.

                        Le pire c'est que par leur nombre, ils sont une force économique de poids, on doit s'adapter à eux. Bien que je pense que fasse à la concurrence cette espèce devra disparaître..

                        « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: SmartEiffel

      Posté par  . Évalué à 4.

      Bah en C++ le programmeur précise si il veut une méthode polymorphe ou pas, et meme dans le cas de méthodes polymorphes on peut préciser le type de l'objet si on en est sur.
      C'est sur qu'un compilo qui fait ca tout seul, c'est pratique, mais c'est plus compliqué... (le compilo)

  • # le meilleur c le superpascal

    Posté par  . Évalué à -2.

    Nardinosboob, le plus fort de tous les plus fort c le super pascal de l'epoque, ca mon vieux, ca dechire sa race nickel t'as pas idée !

  • # Microsoft fortement intéressé par Caml !!!

    Posté par  (site web personnel) . Évalué à 5.

    Oh surprise, je viens de m'apercevoir que Microsoft, lui-même, est membre du consortium Caml ! Voir http://caml.inria.fr/consortium/index.fr.html.(...) Surprise, surprise...




    Par étonnant, car C-oméga http://research.microsoft.com/Comega/(...) permet de définir des N-tuples, des streams comme... OCaml http://download.microsoft.com/download/a/9/c/a9c05370-42bb-4356-b95(...)



    F# http://research.microsoft.com/projects/ilx/fsharp.aspx(...) s'inspire de OCaml, comme publiquement annoncé, mais la comparaison était aux dernières nouvelles en faveur de OCaml http://research.microsoft.com/projects/ilx/fsharp-manual/ml-compat.(...)




    Les slides des journées académiques 2005 de Microsoft http://galilee.microsoft.fr/(jq35ri555b1sv12m5cdrjn45)/a17fdcfb90f1(...) mettent l'accent sur le pi-calculus et le join-calculus pour définir conjointement un nouvel OS et un nouveau langage (facon développement conjoint UNIX+C) pour l'exploitation des CPU multi-core. Et on a aussi ca chez Caml avec JoCaml http://pauillac.inria.fr/jocaml/(...) et Acute http://www.cl.cam.ac.uk/users/pes20/acute/.(...)




    Microsoft pousse vachement dans la direction Caml. Ils s'inspirent des qualités de Caml pour nourrir leurs prochains langages de programmation !




    Du coté Java, on n'a pas (encore ?) grand chose... Heureusement que Groovy http://groovy.codehaus.org/(...) fait bouger le monde Java !



    Dominique

Suivre le flux des commentaires

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