Sortie de TOM 2.3

Posté par  . Modéré par Mouns.
Étiquettes :
0
28
avr.
2006
Communauté
Après un an de travail, la version 2.3 du langage TOM vient de sortir. TOM est un langage de programmation développé par l'INRIA et qui marie le meilleur des mondes des langages fonctionnels et impératifs en ajoutant des capacités de réécriture à Java, C ou OCaml (autres backends à venir).

L'utilisation de TOM est pertinente dès qu'il s'agit de manipuler des données arborescentes (termes, arbres syntaxiques, arbres XML...), ce qui est très courant en programmation.

En plus de proposer un mécanisme de pattern matching puissant (associatif) sur les types Java/C, TOM est fourni avec un langage permettant de définir des types inductifs (comme en Caml) reposant sur une bibliothèque garantissant le partage maximal de la mémoire. Enfin le langage fournit un système de définition de stratégies de parcours des arbres par combinaison de stratégies de base.

Le compilateur est une application stable, bien documentée et réellement utilisable (tâche Ant, plugin Vim...). De nombreux exemples sont fournis. Le premier exemple du tutoriel illustre bien l'intégration de TOM au langage Java :

import main.peano.types.*;

public class Main {
  %gom {
    module Peano
    abstract syntax
    Nat = zero()
      | suc(pred:Nat)
      | plus(x1:Nat, x2:Nat)
  }

  public final static void main(String[] args) {
    Nat z = `zero();
    Nat one = `suc(z);
    System.out.println(z);
    System.out.println(one);
  }
}


Les types inductifs définis dans le bloc %gom peuvent être directement utilisés dans le programme java, et peuvent ensuite être filtrés grâce à l'opérateur %match :


  public static Nat evaluate(Nat n) {
    %match(Nat n) {
      plus(x, zero()) -> { return `x; }
      plus(x, suc(y)) -> { return `suc(plus(x,y)); }
    }
    return n;
  }

Il est également possible de définir des mappings vers des types Java prédéfinis (arbre XML DOM par exemple) pour ensuite profiter du pattern matching et des stratégies de parcours sur ceux-ci.

TOM fournit un mécanisme de pattern matching associatif, i.e. permet de filtrer des listes avec des expressions du type : (X*, a, Y* , b, Z*) plutôt qu'avec des expressions du type tête::queue comme c'est le cas en Caml.

Le langage est actuellement utilisé dans plusieurs projets de recherche mais aussi dans l'industrie.

Aller plus loin

  • # typo

    Posté par  . Évalué à 4.

    il fallait lire "qui marie le meilleur des mondes des langages fonctionnels _et_ impératifs"
  • # Et beh...

    Posté par  . Évalué à -10.

    Génial, après c'est immondice nommée Caml, les chercheurs de l'INRIA ont toujours pas compris la leçon ?
    Enfin si ça les amuse de bouffer les budgets pour des langages à chier utilisés par eux et c'est tout...

    OUI, c'est un troll, OUI c'est méchant, OUI je ne suis qu'un morveux qui connait rien et compagnie, mais OUI je me suis bouffé 1 an de Caml, et j'ai des envies de meurtre....
    • [^] # Re: Et beh...

      Posté par  . Évalué à 3.

      Pourquoi tant de haine? Je comprends que tu en aies bavé mais au point de venir t'immoler comme ça? Pourquoi tant de haine et de rancoeur? ocaml=calmo
      • [^] # Re: Et beh...

        Posté par  . Évalué à 3.

        Je le comprends, une année aussi à en faire, c'était tout simplement N.A.C, plus personne pouvait en bouffer.
        Le top, ça a été les listes, avec des cons(a,cons(b,cons(c ... ))))))) pour faire une liste, les 50 parentheses fermantes à la fin, fallait bien les compter ...
        Quand au magnifique IDE (camlight?), où l'historique insérait dans n'importe quel ordre (on a fini par comprends au bout d'un certain temps que l'IDE insérait les commandes à l'endroit ou était l'ascenseur de l'historique plutôt qu'à la fin de celui ci ... trop logique)
        J'en garde donc un souvenir particulièrement pénible (voire meme écoeurant).

        Pour ce qui est d'ocaml, j'ai entendu quelques personnes dire que c'était bien.
        Cela dit, la seule application réelle que j'en ai vu étant mldonkey (avec des performances dignes d'un escargot de course), je me permet de poser quelques doutes sur la légitimité de son utilisation (quand au programme mldonkey lui même, la derniere fois que je l'ai lancé, il m'a pondu tous les fichiers de config dans le repertoire courant ... ça m'a permis d'etre rapidement fixé sur son sort ;) )
        • [^] # Re: Et beh...

          Posté par  . Évalué à 5.

          bon, ...

          - Caml light n'est plus maintenu depuis 2002 et n'existe quà des fins éducatiives dans les prépas. Je ne connais pas bien cette version de Caml, mais une liste s'écrit [1;2;3...] chez moi. Un ide c'est un ide...utilise le mode tuareg d'emacs :)

          - ocaml a énormément d'applications dans la recherche (en fait là où je bosse les gens qui n'utilisent pas TOM utilisent ça :) ). Il a aussi des applications industrielles mais elles sont moindres. Quand aux performances (http://shootout.alioth.debian.org/sandbox/benchmark.php?test(...) , le compilo est plutôt réputé pour celles-ci.

          - mldonkey est un peu tout pourri mais si on évalue la qualité d'un llangage à ses applications, alors le C, C++ et java sont très très loins derrière :)
        • [^] # l'INRIA ne soutient pas suffisamment OCaml

          Posté par  . Évalué à 2.

          Une liste en OCaml s'écrit [a;b;c;d] et non pas cons(a,cons(b,cons(c ... ))))))). On peut cela dit l'écrire aussi comme tu le fais. Peux-tu m'écrire l'équivalent en Java en C ou autre pour comparer ? C'est autrement plus compliqué...

          Bref le nombre de parenthèses c'est un peu juste pour juger un langage. Il existe des critères un peu plus objectifs... OCaml permet de programmer de manière très concise (donc rapide) des applications qui plantent très peu.

          Et OCaml met à la disposition du programmeur des tonnes de concepts qui ne sont quasiment jamais réunis dans le même langage. C'est le langage le plus riche que je connaisse. (variants, Pattern-matching, Garbage Collector, objets, inférence de types, polymorphisme paramétrique, prog fonctionnelle et impérative, exceptions, préprocesseur, etc) et il a été conçu par des gens qui sont parmi les meilleurs spécialistes du domaine au monde.

          Le revers de tout ça c'est qu'il devient un peu plus difficile à apprendre et maîtriser qu'un langage moins riche en concepts. Et souvent les gens qui critiquent OCaml n'ont juste pas pris le temps de le découvrir à fond.

          L'IDE dont tu parles est sûrement une vieille IDE de camllight pour windows toute pourrie. Cela dit tu as raison, l'INRIA ne met pas les moyens nécessaires pour développer les outils autour du langage. S'ils veulent que leur recherche passe dans le monde des entreprise il faudrait payer des développeurs (ce n'est pas le boulot des chercheurs)... Et OCaml est vraiment une réussite de l'INRIA qui mériterait d'être utilisée à plus grande échelle. Mais on dirait que l'INRIA n'a pas envie...

          C'est pour cette raison qu'OCaml est encore peu utilisé dans l'industrie mais à mon avis il manquerait juste un petit effort de l'INRIA et les entreprises se rendraient compte qu'OCaml leur permet de gagner du temps de programmation et de débogage donc de l'argent.
          • [^] # Re: l'INRIA ne soutient pas suffisamment OCaml

            Posté par  . Évalué à 5.

            > souvent les gens qui critiquent OCaml n'ont juste pas pris le temps de le découvrir à fond.

            Oui enfin on peut le voir aussi dans l'autre sens: pourquoi les gens ne prennent pas le temps de découvrir à fond OCaml?
            Dans mon cas, c'est la syntaxe pas terrible qui m'a découragé (pas la "richesse des concepts"), bon il faut dire que depuis que j'ai découvert Ruby je suis devenu assez exigeant coté syntaxe.

            Et, à l'opposé, ceux qui maîtrisent un langage ont tendance à oublier ses défauts..
            Par exemple (pour ne pas taper que sur Ocaml) qui se souvient des problèmes qu'il a eu pour la déclaration de variable en C?
            Pas grand monde.. et pourtant une syntaxe comme celle de Limbo http://www.vitanuova.com/inferno/limbo.html est plus simple..
            • [^] # Re: l'INRIA ne soutient pas suffisamment OCaml

              Posté par  . Évalué à 4.

              je ne vois pas trop ce qu'on reproche à la syntaxe d'ocaml si ce n'est qu'elle est différente de celle des langages de la famille C (syntaxiquement parlant). Je trouve au contraire que l'inférence de type a tendance à "épurer" le code. Et l'approche fonctionnelle du langage fait que la définition d'une fonction ressemble vraiment à la manière dont on les défnit mathématiquement.

              Je pense que la plupart des gens se disant rebutés par la syntaxe d'ocaml sont en fait déroutés par leur premier contact avec un langage fonctionnel.
              • [^] # Re: l'INRIA ne soutient pas suffisamment OCaml

                Posté par  . Évalué à 6.

                Moi je reproche à la syntaxe d'OCaml d'être bourrée d'exceptions. Il y a trop de choses qui sont facultatives "quand c'est évident", ça complique la lecture pour ceux qui ne font parlent pas l'OCaml courrament. Généralement j'ignore les exception et je rajoute des parenthèses facultatives pour clarifier, mais quand je lis du code qui n'est pas le mien, il m'arrive de souffrir.

                Dans le même style, le fait d'avoir des opérateurs différents pour la même opération sur des types différents, ça rend la lecture et l'apprentissage difficiles. C'est justifié par l'inférence de types, mais c'est pénible de devoir se souvenir quel est l'opérateur à utiliser pour le type que l'on a.
                • [^] # Re: l'INRIA ne soutient pas suffisamment OCaml

                  Posté par  . Évalué à 5.

                  Juste pour préciser que le fait d'avoir des opérateurs différents pour la même opération n'est pas justifié par l'inférence de types en soit. On peut enrichir le système de typage de façon à rendre possible l'utilisation du même opérateur pour plusieurs types.

                  Dans le cas d'Ocaml, je crois que c'est plutôt un choix. D'autres langages avec inférence de type ont fait un choix différent, comme Haskell par exemple.
                • [^] # Re: l'INRIA ne soutient pas suffisamment OCaml

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

                  Moi je reproche à la syntaxe d'OCaml d'être bourrée d'exceptions.

                  exemples ? Je ne vois pas trop de quoi tu veux parler ...

                  le fait d'avoir des opérateurs différents pour la même opération sur des types différents, ça rend la lecture et l'apprentissage difficiles.

                  Ouais enfin il ne s'agit que des opérateurs numériques et il suffit de rajouter un point pour la version flottantes, c'est quand même pas trés dur à comprendre et à retenir.
                  • [^] # Re: l'INRIA ne soutient pas suffisamment OCaml

                    Posté par  . Évalué à 6.

                    il ne s'agit que des opérateurs numériques et il suffit de rajouter un point pour la version flottantes, c'est quand même pas trés dur à comprendre et à retenir.

                    Non, c'est pour tous les opérateurs, sauf ceux de comparaison qui sont polymorphiques. Le langage et la lib de base fournissent peu d'opérateurs, justement parce que l'absence de polymorphisme rendrait pénible d'avoir 27 variantes de "+". Du coup, tu as +, +. et +/ pour additionner les entiers, les flottants et les Nums, et pour les autres types il faut utiliser les fonction du style Type.add.

                    Dans le même style, et même si ce ne sont pas strictement des opérateurs, tu dois mémoriser que pour décrire une liste c'est [ ... ], pour décrire un vecteur c'est [| ... |]. Pour accéder à un élément d'un vecteur, on utilise .(indice), et pour accéder à un élément d'une chaîne, .[indice], etc.

                    Chaque point pris individuellement n'est pas dur à mémoriser, c'est la somme des détails qui est lourde. En Ruby, pour additionner deux objets on utilise "+", et pour accéder à un élément dans un truc qui en possède plusieurs, on utilise [indice]. Je comprend la justification derrière le choix d'OCaml, mais je trouve quand même la version ruby plus agréable.

                    exemples ? Je ne vois pas trop de quoi tu veux parler ...

                    Difficile de faire une liste précise, je ne mémorise pas les exceptions, c'est bien pour ça qu'elles me posent problème :)

                    Il me vient, à froid:
                    - tous les exemples ci-dessus.
                    - le produit cartésien, pour lequel on peut omettre les parenthèses lorsque ce n'est pas ambigu pour le compilateur, mais j'ai rencontré des cas où c'était ambigu pour mon cerveau limité.
                    - il y a d'autres cas où les parenthèses peuvent être omises, et ça n'aide pas toujours la lisibilité. Je l'ai dit, j'aime bien le Lisp :)
                    - Il y a plusieurs manières de déclarer une fonction. Je n'en ai retenu qu'une, mais pour débugguer le code des autres il faut toutes les connaîtres.
                    - Si on veut faire de l'impératif, on peut délimiter les instructions qui renvoient unit par des points virgule, ou bien on peut écrire let () = expression in ... (il y a peut-être une différence entre les deux, mais je ne la connais pas).

                    J'ai la flemme d'en chercher d'autre, je n'ai pas pour but de démolir OCaml. Puisque je m'en sers, c'est que je trouve les obstacles surmontables, mais quand même pénibles ;)
                    • [^] # Re: l'INRIA ne soutient pas suffisamment OCaml

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

                      Je comprend la justification derrière le choix d'OCaml, mais je trouve quand même la version ruby plus agréable.

                      OK mais tout ceci n'est pas à strictement parler un problème de syntaxe. Cela tient plutôt à la manière dont ces deux langages gèrent le polymorphisme, le typage, etc. Ce n'est pas quelque chose qui peut s'améliorer en changeant uniquement la syntaxe (ie. la représentation en chaîne de caractères du programme), ça a aussi à voir avec toute la sémantique du langage.

                      Effectivement, si OCaml avait des type classes comme Haskell, cela permettrait une syntaxe plus légère. Mais il ne faut pas se focaliser sur la syntaxe actuelle comme si les concepteurs l'avait voulue exactement ainsi, qu'ils se fichent des aspects pratiques, etc. Les aspects problèmatiques de la syntaxe sont surtout des conséquences d'autres limitations du langage plutôt que erreurs de conception. (AMHA)

                      - il y a d'autres cas où les parenthèses peuvent être omises, et ça n'aide pas toujours la lisibilité.

                      mais ... c'est comme ça dans tous les langages. C'est comme si tu nous faisait un vélo parce qu'en C, pour parser les expression arithmétiques genre 2 + 4 * 5 parfois il faut des parenthèses et parfois on peut les omettre. Les différentes règles de la grammaire ont des priorités, si ça ne correspond pas à ce que tu veux, il faut rajouter les parenthèses ... c'est tout.

                      Par exemple, l'opérateur produit pour les types * à une priorité plus faible que l'application, du coup string * string list est parsé comme string * (string list) ; si tu veux une liste de paires de string, il faut l'écrire (string * string) list. C'est le même principe que pour les expressions arithmétiques : tu retiens les priorités des opérateurs les plus courants et sinon tu mets des parenthèses. Je vois pas trop ce qu'on peut reprocher à OCaml sur ce point.

                      Autre exemple: l'expression if/then/else. Quand on écrit if e1 then e2 ; e3, l'expression e3 n'est pas dans la branche then, elle est au même niveau que le if ; il faut mettre des parenthèses (ou un begin/end) si on veut obtenir la séquence e2 ; e3 dans le then. Mais c'est à peu près le même comportement qu'en C avec if (cond) i1; i2;: il faut des {} pour regrouper i1 et i2.

                      Je n'ai pas pour but de démolir OCaml.

                      ... et je ne prétends pas que OCaml soit sans défaut. Comme souvent c'est une question de compromis : la syntaxe n'est sans doute pas la meilleure qui soit mais les autres atouts du langage en valent largement la peine.
                      • [^] # Re: l'INRIA ne soutient pas suffisamment OCaml

                        Posté par  . Évalué à 2.

                        mais ... c'est comme ça dans tous les langages.

                        (Pas en Lisp.)

                        Il y a une différence fondamentale entre ton exemple d'additions/multiplications et mon exemple de produit cartésien: tout le monde sait comment 5+3*6 est évalué. La priorité des opérateurs est là pour refléter l'écriture normale des opérations. Dans la vraie vie, un n-uplet s'écrit (a, b, c), rarement a, b, c, donc je ne vois pas pourquoi rendre les parenthèses facultatives. Si on le fait, on autorise à écrire [ 1 , 2 ; 1 , 3 ; 2 , 4 ; 3 , 1 ] au lieu de [ (1, 2) ; (1, 3) ; (2, 4) ; (3, 1) ]. Ce n'est pas ambigu, mais c'est difficile à lire. Si on n'a pas l'habitude du langage, certaines expressions non ambigues peuvent être trompeuses... en tout cas je me suis déjà fait avoir par cette règle.

                        Je prend un autre exemple tiré par les cheveux, en créant un opérateur qui additionne des couples:
                        # let (++) x y = fst x + fst y, snd x + snd y;;
                        # 1,1 ++ 1,2;;
                        This expression has type int but is here used with type int * int
                        # (1,1)++(1,2);;
                        - : int * int = (2, 3)


                        Là aussi, le code n'est pas ambigu. On aurait tort d'essayer 1,1 ++ 1,2 parce que l'opérateur s'appliquerait à deux entiers, pas à deux couples. Mais à mon avis c'est un piège inutile, et si le parenthèsage n'était pas facultatif on n'aurait jamais pu se tromper.

                        les autres atouts du langage en valent largement la peine.

                        Tout à fait, mais malgré tout je déplore les exceptions ou les variantes de sa syntaxe. La syntaxe du Lisp est plus abordable pour les débutants, parce qu'elle ne possède pas d'exceptions. Quand tu connais la règle (fonction arg1 ... argN) et les quelques formes spéciales, tu connais tout. En contrepartie, c'est un peu plus lourd à écrire.

                        Personnellement, je me satisfais assez d'un OCaml très parenthèsé, qui n'utilise qu'une seule manière de déclarer les fonctions, etc. Tant que je ne relis pas le codes des autres, bien sûr :)
              • [^] # Re: l'INRIA ne soutient pas suffisamment OCaml

                Posté par  . Évalué à 3.

                >sont en fait déroutés par leur premier contact avec un langage fonctionnel.

                Ce n'était pas mon premier langage fonctionnel (mais je n'apprécie pas particulièrement les langages fonctionnels à part Scala) et Ocaml est "vendu" comme un langage multi-paradigme pas fonctionnel.
                Cependant dans le livre l'accent est mis sur le coté fonctionnel ce qui est pénible..

                En fait, j'ai ressenti exactement la même chose que Yusei ce qui est amusant..

                Sinon je suis d'accord que l'inférence de type épure le code mais Ocaml n'est pas le seul langage ou l'inférence de type existe: Limbo, Scala, D, bientôt C# v3 etc ont l'inférence de type locale ce qui est suffisant.
          • [^] # Re: l'INRIA ne soutient pas suffisamment OCaml

            Posté par  . Évalué à 4.

            Je lisait sur le blog de Phillip J. Eby (attention c'est plutôt long): http://dirtsimple.org/2006/04/confidence-and-unexpected-orig(...) une reflexion où il explique que finallement ce qui fait la valeur d'un produit c'est à 80% le marketing dans le sens où c'est la partie qui permet d'exprimer au client ce que lui apporte le produit (et le client ne jouit que de ce dont il a conscience).
            Bref il ne manque peut-être pas tant des développeurs à OCaml mais du marketing (et ce n'est certes pas le travail des chercheur). Ce travail devrait être mené (en mon sens) par un tandem commercial-ingénieur (ou une personne qui réunit les deux) qui, profitant de la licence, pourrait faire un consorsium type ObjectWeb (JBOSS).
            Mais c'est beaucoup plus facile à dire qu'à faire ! De plus il faudrait effectivement la coopération des chercheurs qui sans savoir forcément l'exprimer connaissent la valeur du produit. La manière la plus naturelle serait surement un étudiant de master ou de thése qui se sente suffisament hardi et intéressé pour se lancer dans une startup (en lien avec le labo) ! Je connais quelqu'un qui a fait un truc dans le genre avec les lasers (me faire un message perso si tu veux en savoir plus).
        • [^] # Re: Et beh...

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

          faux faux faux et archi faux :

          - j'ai appris à programmer avec caml en prépa, en utilisant caml light, enfin pas vraiment, on utilisait un éditeur tout bête http://www.crimsoneditor.com qui nous permettait d'interpréter et d'avoir la sortie dans un "ide" potable, caml light n'est qu'un petit utilitaire fait à la va-vite pour des tests rapides.

          - ensuite, après 3 ans d'école informatique, et bien je peux dire que je préfère encore caml au reste, parce qu'il n'y a rien de tel que le pattern matching, les inférences de type, et les déclarations fonctionnelles.

          - mldonkey tourne très bien, je l'ai compilé et installé sur un serveur où nous étions plusieurs à l'administrer, il propose une interface web avec toutes les fonctions utiles au téléchargement, il tourne de façon bien plus légère que emule amule et autres, etc
          et si tes fichiers se sont retrouvés n'importe où c que t'as encore pas mal de choses à apprendre petit (genre savoir faire un make install)

          - ocaml permet de faire des appli complètes, pour le réseau, les jeux, etc

          PS : waoh polux, 69 commentaires sur ta dépèche, c chaud TOM !
          d'ailleurs pour revenir au sujet, j'attends tom pour C# et c partiiii !
          • [^] # Re: Et beh...

            Posté par  . Évalué à 1.

            > d'ailleurs pour revenir au sujet, j'attends tom pour C# et c partiiii !

            c'est quelque chose de tout à fait envisageable. Comme Tom ne parse pas la syntaxe du langage hote, il est assez facile de l'etendre à d'autres langages : il suffit de faire un nouveau backend.

            Si C# supporte le if-the-else, l'affectation, la sequence d'instructions et la notion de block, cela de devrait prendre que quelques heures pour avoir un prototype. J'imagine qu'en 1 ou 2 jours on doit pouvoir faire un backend pour C# qui tienne la route.

            Surtout, ne pas hésiter à contribuer, le projet est ouvert.
            • [^] # Re: Et beh...

              Posté par  . Évalué à 3.

              surtout que la syntaxe du c# est très très proche de celle de java
            • [^] # Re: Et beh...

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

              ok, no souci PEM, et comme dit polux, C#, c immensément proche de java en syntaxe, suffit d'adapter sans doute, je me suis pas pencher sur tom plus que ça, je jetterai un coup d'oeil.

              ce qui serait bien, ça serait de faire connaître tom dans les communautés java et C, en entreprise, j'ai pas entendu parler de TOM, alors que des choses genre JML ou JUnit pour java oui.
            • [^] # Re: Et beh...

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

              Pareil pour Gom: une version C# (voire même python) ne semlbe pas hors de portée: tous deux fournissent un garbage collecteur, des weak references et des interfaces donc in est surement possible d'avoir une librairie similire a shared-object pour pas cher.
              Ensuite, un backend Gom pour ca sera probablement assez direct à ecrire
            • [^] # Re: Et beh...

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

              Et pour Lisaac, j'imagine que tu en as déjà parlé avec Benoit (qui me parle de TOM depuis 1 ans), est-ce que ce serait long à implémenter ?

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

      • [^] # Re: Et beh...

        Posté par  . Évalué à 9.

        Je pense qu'OCaml demande un gros temps d'apprentissage (qui sera beaucoup plus réduit si on connait déjà un langage fonctionnel style Lisp), et est essentiellement utile pour faire des choses compliquées. Pour faire un logiciel simple, du genre de ceux qu'on fait en projet de programmation à la fac, le temps d'apprentissage est trop élevé pour valoir la peine. Bien sûr, une fois qu'on a appris, on peut s'en servir pour faire n'importe quoi, mais il y a une barrière assez élevée au début.

        Je ne suis pas franchement convaincu par l'idée d'enseigner aux étudiants à programmer en commençant par OCaml, comme ça a été fait dans certaines facs. Un langage de programmation, c'est un outil pour résoudre les problèmes. Si on n'a pas encore eu de problèmes, on ne peut pas correctement apprendre à les résoudre. Donc je pense qu'il vaut mieux commencer par un langage simplissime et pas trop abstrait, commencer à programmer, et quand on rencontre des obstacles, trouver des langages qui aident à les surmonter.
        Par exemple quand on se met à programmer à plusieurs et que la modularisation avec des .h atteint ses limites, on commence à mieux apprécier la programmation objet. Ou bien quand on se met à manipuler des structures de données abstraites et récursives, on se met à sérieusement apprécier la programmation fonctionnelle... du moins en ce qui me concerne.

        D'un autre côté, il y a des inconvénient à apprendre d'abord un langage comme le C et ensuite un langage comme OCaml. On commence en ayant peu de contraintes, et ensuite on se trouve face à quelque chose de beaucoup plus formel, qui demande un peu de discipline, et il est difficile de se débarrasser de ses mauvaises habitudes.
        Finalement, je ne sais pas ce qui est le mieux, comme ordre d'apprentissage, mais je comprend qu'on pense qu'OCaml est un langage sans applications quand on n'a pas encore souffert en essayant de faire quelque chose de vraiment compliqué dans ces langages préhistoriques que sont le C et ses dérivés (ce qui inclut Java, hein).
        • [^] # Re: Et beh...

          Posté par  . Évalué à 3.

          Je te pertinente des deux mains. Résoudre des problèmes concrets, pour lesquels avoir une solution importe, fait faire des progrès rapides dans n'importe quel langage. En milieu scolaire, le seul travail qui m'ait vraiment intéressé était un programme de dérivation formel en C. J'aime les maths. Le C aussi, mais ce n'est pas ce que je choisirais pour refaire ce genre de choses.
        • [^] # Re: Et beh...

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

          Je suis d'accord avec toi, et j'ai apprécié l'objet pour la raison que tu cites (sauf que moi, c'était Pascal).
          En tant qu'enseignant, j'avais essayé de suivre cette démarche : je pose un problème, les étudiants essaient de le résoudre avec ce qu'ils connaissent, ils construisent alors souvent quelque chose qui ressemble à la nouveauté que je voulais leur enseigner, puis j'amène la nouveauté : joie, soulagement, satisfaction, plaisir, c'est super ! Les étudiants comprennent mieux l'intérêt, apprécient la beauté de la nouveauté, mais :
          - c'est un processus un peu lent
          - ça demande que les étudiants s'investissent dans la recherche sinon on perd du temps; d'après moi, c'est toujours là que réside la difficulté : motiver chaque étudiant, en tenant compte de ses goûts, de sa personalité, de sa forme du moment, des ses propres motivations, ... Difficile à faire avec 35 étudiants différents !
          • [^] # Re: Et beh...

            Posté par  . Évalué à 7.

            Bravo, c'est exactement ce qu'il fau[drai]t faire : expérience (en TP), aide/mise en commun/réflexion/discussion (en TD), conceptualiser (en CM).

            Le problème, c'est que les étudiants sont habitués à l'ordre CM (où on dort à moitié en grattant) - TD (on dort en attendant que le prof. donne la solution) - TP (quand il y en a) et que monter un cours dans cet ordre demande du temps (pour la préparation et pour le cours) et on a déjà pas forcément le temps de tout caser...
        • [^] # Re: Et beh...

          Posté par  . Évalué à 7.

          Mouais, sans doute que le C ou Java sont des langages préhistoriques, mais il y a un point où le Caml est encore plus préhistorique : c'est son framework et tout ce qui tourne autout. J'ai franchement l'impression de faire un bon de 15 ans en arrière. A mon avis ça doit expliquer pour une large part, pourquoi ce langage perce si peu.

          Sérieux, c'est quoi l'intérêt d'un langage surdoué, quand le framework de base est à peine plus évolué que la libc ? Ok, c'est un langage Türing complete, tu peux tout faire avec, mais en combien de temps ? Si des langages comme C# ou Java ont un certains succès, c'est bien parce qu'ils proposent tout un framework utilisable et à peu près bien adapté aux besoins des entreprises d'aujourd'hui, pas d'il y a 15 ans. Parce que bon, on a franchement autre chose à faire que de recoder tout une tétrachié de wrappers pour des libs existantes (avec tous les emmerdes que ça présuppose : doc, tests, mise à jour, intégration plus ou moins bancale dans le langage, etc ...).

          Tant qu'on y est, quid de l'intégration avec le système hôte ? Quid de l'intégration de Caml dans des IDEs un peu mieux foutu que vi ou emacs ? Quid d'un framework graphique qui fait autre chose que dessiner des droites et des rectangles ? Quid de la doc de tout ça (haha, je rigole d'avance à l'ampleur de la tâche) ? Quid des capacités cross-plateformes (dont les différences subtiles ont bien-sûr été documentées et à peu près testées) ? C'est l'exemple typique de sales boulots que personne ne veut faire.

          Si on ajoute à ça que Caml n'est absolument pas en position de force, et que l'Inria n'a de toute façon pas les moyens de concurencer un Java ou un C#, ben faut pas s'étonner que ce langage se cantonne depuis des lustres aux cercles académiques ou à quelques niches ultra-pointues.

          En tous les cas, l'approche utilisé par TOM me semble nettement plus pragmatique et réaliste.
          • [^] # Re: Et beh...

            Posté par  . Évalué à 4.

            Mouais, sans doute que le C ou Java sont des langages préhistoriques, mais il y a un point où le Caml est encore plus préhistorique : c'est son framework


            Mouais, alors si tu compares la lib de base d'OCaml et celle du C, je ne sais pas vraiment qui gagne, mais je penche très fort pour OCaml, puisque la notion de "lib de base" pour le C est quasi inexistante. Pour Java, par contre, d'accord.

            Ceci dit, s'il n'y a pas de parser XML, d'interface ODBC, etc. dans la lib de base, tout ça existe quand même. Il manque peut être un repository, je ne sais pas trop, chez moi c'est bien proprement intégré par Debian. Quand j'ai besoin de quelque chose, ça se limite souvent à une recherche dans la base des paquets.

            Si des langages comme C# ou Java ont un certains succès, c'est bien parce qu'ils proposent tout un framework utilisable et à peu près bien adapté aux besoins des entreprises d'aujourd'hui, pas d'il y a 15 ans.


            Ho ho. Je t'accorde que le seul intérêt de Java, c'est son framework, parce que le langage n'est vraiment pas terrible.

            Mais si on se basait sur l'existence de bibliothèques et d'IDE pour juger les langages, Java n'aurait jamais été créé. Du côté des IDE, j'ai commencé à faire du Java avec le bloc note de Windows, et c'était pas joyeux.

            quid de l'intégration avec le système hôte ?

            open Unix

            Quid de l'intégration de Caml dans des IDEs un peu mieux foutu que vi ou emacs ?

            Là, j'avoue que je n'en connais pas de mieux foutu qu'Emacs.

            Quid d'un framework graphique qui fait autre chose que dessiner des droites et des rectangles ?

            C'est triste ce que tu penses de GTK2.

            Quid de la doc de tout ça (haha, je rigole d'avance à l'ampleur de la tâche)

            Il y a un livre publié par OReilly et diffusé sur le net, qui est très bien foutu, bien qu'un peu dense à mon goût.

            Quid des capacités cross-plateformes

            Je ne sais pas sur quelles plateformes le compilateur d'OCaml tourne, mais tu peux compiler un programme OCaml en bytecode pour JVM, si tu veux.
            • [^] # Re: Et beh...

              Posté par  . Évalué à -1.

              Mouais, ça confirme l'impression que j'ai eue lorsque j'ai testé ce langage : c'est très fortement lié à Unix, aussi bien niveau développement, que des applications qu'il peut produire. Si on veut une appli a peu près bien intégrée sous Windows, voire Mac OS X, ç'est infiniment plus simple de faire ça en Java + SWL, ou en C++/wxWidgets, si on le compare avec C#/.net sous Windows uniquement, ça ne tient même pas la comparaison.
    • [^] # Re: Et beh...

      Posté par  . Évalué à 6.

      Ouais mais ce coup ci ca rajoute des fonctionnalités à l'intérieur d'un autre langage connu. Et ceci justement pour faciliter l'utilisation de ce langage de réécriture par des entreprises.

      Je sais qu'ils ont déjà quelques utilisateurs dans l'industrie principalement pour manipuler du XML avec le back-end Java.
      • [^] # Re: Et beh...

        Posté par  . Évalué à 0.

        En même temps ils auraient pu ajouter ces fonctionnlités de façon plus élégante, avec de nouveaux mots clés par exemple.
        Personnellement j'ai pas envie d'apprendre un language où il faut sans cesse appuyer sur deux touches pour faire un caractère et là ils ont mis des % et | à gogo on dirait.

        Sur les claviers QWERTY ces caractères sont accessibles directement non ? c'est peut être plus pratique pour programmer.
        • [^] # Re: Et beh...

          Posté par  . Évalué à 4.

          Le problème d'ajouter des mots clés est que:
          - Ils ne pouvaient pas modifier le langage d'origine, et ajouter les mots clés directement à Java ou C, parce que ça serait revenu à créer un nouveau langage, avec tous les défauts que ça implique.
          - Du coup ils ont opté pour un préprocesseur. Or, si les mots du langage du préprocesseur sont des mots possibles du langage de destination, ça pose des problèmes. Dans le cas présent, un programme Java dans lequel une variable serait nommée "match" n'aurait pas été une entrée valide pour Tom, s'il avait utilisé le mot clé "march" au lieu de "%match".
        • [^] # Re: Et beh...

          Posté par  . Évalué à 2.

          Si la seule chose qui te gêne est le caractère %, tu peux toujours modifier le lexer du compilo et le recompiler, ça marche.

          Par contre, plus sérieusement, la prochaine version de TOM proposera certainement des "frontends" adaptés à chaque langage, ce qui nous permettra d'éviter de demander de fournir le type d'une variable dans la construction %match(Type var) en java par exemple. Ca nous permettra d'être plus proche de la syntaxe du langage hôte, par exemple:

          def pred(n):
          match Nat n:
          suc(x):
          return x
          zero():
          return zero()

          par exemple en python...remarque que pour le python on a besoin au contraire du java du type algébrique puisque TOM est compilé et que le type de n n'est connu qu'à l'exécution.

          Pour l'instant, le choix de faire un préprocesseur qui ne dépende pas du tout du langage, à part dans la toute dernière étape de génération du code, nous a permis de porter TOM très rapidement vers d'autres langages.
          • [^] # Re: Et beh...

            Posté par  . Évalué à 2.

            l'indentation n'est pas passée mais les pythoneux auront compris :)
    • [^] # Re: Et beh...

      Posté par  . Évalué à 6.

      Pourtant INRIA = Institut National de Recherche en Informatique Amusante.

      Et ce nouveau language m'a l'air tout à fait désopilant.

      Ils ont donc bien rempli leur mission !

      BeOS le faisait il y a 20 ans !

      • [^] # Re: Et beh...

        Posté par  . Évalué à 1.

        +1
        Apparemment il y a beaucoup d'utilisation de ` dans le language, un opérateur difficilement visible, je ne pense pas que ce soit une bonne idée.

        Les langages qui mélangent fonctionnel et objet sur JVM, il y en a beaucoup, par exemple Scala qui est pas mal. Y-a t'il un comparatif entre Scala et TOM par exemple?

        Il y a franchement abondance de langage, c'est difficile de s'interresser à un nouveau langage alors que certains comme Limbo auraient mérités beaucoup mieux..
        • [^] # Re: Et beh...

          Posté par  . Évalué à 2.

          la denière fois qu'on a regardé scala, les choses un peu funky en pattern matching avaient été désactivées ... sinon pour ce qui est du partage maximal de la mémoire ils ont carrément repompé ce qu'on a fait.

          Scala est sympa mais pour l'instant ça part un peu dans tous les sens, ce qu'on propose avec tom est centré sur la réécriture mais on le fait (déjà :)), on le fait bien (résultats certifiés par coq et zenon, donc il y a une vraie sémantique) et on fournit tout un framework qui va avec :
          signatures algébriques, partage maximal de la mémoire, définition de stratégies, possibilité d'ajouter des backends, etc.
          • [^] # Re: Et beh...

            Posté par  . Évalué à 3.

            Je ne sais pas si les gars de Scala ont pompés ce que vous avez faits, mais je vous conseillerais de leur rendre la pareille sur le plan de la syntaxe qui chez eux est très propre.

            La syntaxe d'un language pour un programmeur, c'est comme l'interface graphique d'une application: très important..
            Il n'y a pas que les preuves formelles qui sont importantes..
            • [^] # Re: Et beh...

              Posté par  . Évalué à 2.

              cf le post sur les frontends...
            • [^] # Re: Et beh...

              Posté par  . Évalué à -1.

              Ben moi j'en ai rien a foutre de la syntaxe.

              De toute manière c'est 100% subjectif. Et c'est aux programmeurs a s'adapter aux nouvelles syntaxes, et oui on ne peut pas faire de nouvelles choses avec des vieilles syntaxes ...

              Les preuves formelles, la puissance et l'expressivité du langage sont bien plus importante. Tu fais quoi avec ton langage ? De la poésie ?
              Perso je fait des programmes avec, je les affiche pas dans ma chambre.
              • [^] # Re: Et beh...

                Posté par  . Évalué à 5.

                Non ce n'est pas 100% subjectif: pour maintenir des programmes, la lisibilité d'un langage est très importante.
                Il n'y a qu'a essayer de maintenir un programme écrit par un autre en Perl pour s'en rendre compte..
                • [^] # Re: Et beh...

                  Posté par  . Évalué à 2.

                  Si tu veux je te fais un truc illisible dans n'importe quel langage. De même quand j'écrivais de Perl je fesais attention a bien présenter les choses
                  • [^] # Re: Et beh...

                    Posté par  . Évalué à 4.

                    On peut écrire du code illisible dans n'importe quel langage, c'est une évidence qui n'apporte *rien*.

                    Mais certains langages ont une syntaxe qui facilite l'écriture de code propre et la maintenance..

                    S'il faut faire attention en écrivant en Perl, c'est bien parce que le langage encourage a faire du code peu lisible..
                    Peu de gens préférent la syntaxe de Perl à celle de Ruby (je parle de la syntaxe hein pas du reste, on peut préférer Perl parce qu'on y est plus habitué, à cause de CPAN..). Donc Ruby doit faire quelque-chose de bien..

                    Pour exagérer les différences, tu préfère maintenir un programme en Ruby ou en APL?

                    Les préférences individuelles n'ont que peu d'intérét, le succes d'un langage c'est par définition quelque-chose de collectif: ce sont les préférences d'un grand nombre de programmeurs qui comptent..
                    Et la majorité des programmeurs se fichent des preuves de Coq mais pas de savoir si c'est facile à lire|maintenir/écrire, les deux ne sont bien sûr pas incompatible, mais apparemment c'est dur à retenir..
                  • [^] # Re: Et beh...

                    Posté par  . Évalué à 5.

                    Il y a une théorie[1] selon laquelle le langage que l'on parle détermine la manière dont on pense, et dont on comprend le monde. Je la trouve plutôt convainquante, et je pense que ça s'applique aussi à la programmation. Quand syntaxe d'un langage favorise, par exemple, la déclaration de fonctions anonymes, ou bien la possibilité de currifier[2] une fonction, on a tendance à programmer différemment.

                    Même si je sais que tous les langages Turing-complets permettent la même chose, je ne peux pas penser que la syntaxe n'a pas d'importance. Il n'y a qu'à voir la différence dans les programmes de résolution d'un problème, si l'un a été codé en impératif et l'autre en fonctionnel. De la même manière, on peut souvent voir lorsqu'un type qui code en C est un programmeur qui a fait du fonctionnel avant, ou de l'objet, ou autre. Le paradigme favorise certains choix, et la syntaxe également.

                    [1] http://en.wikipedia.org/wiki/Sapir%E2%80%93Whorf_hypothesis
                    [2] http://en.wikipedia.org/wiki/Currying
                    • [^] # Re: Et beh...

                      Posté par  . Évalué à 5.

                      Je connaissais déjà cette hypothèse et elle a été réfutée, au moins dans ca forme la plus forte.

                      La syntaxe n'a qu'un impact mineur sur la lisibilité des programmes. C'est d'abord les conventions collectives et les effort de chacun qui détermine le résultat. Tout ce que peut faire le langage c'est proposer une bonne expressivitée pour coller naturelement à ce que veux faire le programmeur, c'est donc la sémantique qui est déterminante (a ne pas confondre avec la syntaxe).

                      Et les seuls arguments que j'ai vu ici (à part les ouin-ouin pasque c'est pas comme l'habitude de chacun) c'est :
                      * "`" est difficiliement lisible mais cela tombe bien car c'était justement le but dans ce choix de lexeme.
                      * % nécessite deux touches pour être saisie : oh mon dieu c'est la fin du monde...
                      • [^] # Re: Et beh...

                        Posté par  . Évalué à 4.

                        Tres bonne remarque!

                        Le "`" est bien connu dans la communauté Lisp et symbolise un echappement. Il manque encore la "," qui permet de revenir dans le contexte de départ.
                        Quant au "%", il est aussi difficile à saisir que "{", "(" ou "*". On va dire que Tom n'est pas fait pour les programmeurs qui ont des difficultés à appuyer sur 2 touches en meme temps :-)
                      • [^] # Re: Et beh...

                        Posté par  . Évalué à 3.

                        Je connaissais déjà cette hypothèse et elle a été réfutée, au moins dans ca forme la plus forte.

                        Si tu as une référence, ça m'intéresse. Je ne suis même pas sûr que ce soit réfutable, comme hypothèse.

                        Tiens, amusant, il y a aussi une page sur wikipedia concernant les langages et l'hypothèse Sapir Whorf: http://en.wikipedia.org/wiki/Sapir-Whorf_and_programming_lan(...)

                        La syntaxe n'a qu'un impact mineur sur la lisibilité des programmes.

                        C'est tellement peu conforme à mon intuition et à mon expérience personnelle que je ne sais pas vraiment comment y répondre.

                        On pourrait prendre un cas extrême inspiré du langage Whitespace. Avec un alphabet comportant uniquement deux caractères, l'espace et le retour à la ligne, on peut tout à fait construire un langage qui permet d'exprimer des concepts de haut niveau. Faut être cinglé pour vouloir faire ça, mais on peut.

                        D'un autre côté, comme c'est un exemple extrême, ce n'est pas très satisfaisant. Et comme la plupart des langages ont été conçus pour être utilisables par des humains, on ne trouvera pas dans la nature d'exemples flagrants de syntaxe qui rend le code illisible, car la sélection naturelle des programmeurs l'aurait éliminée.

                        (note, au passage, que je n'ai rien contre la syntaxe de Tom, hein :)
                        • [^] # Re: Et beh...

                          Posté par  . Évalué à 3.

                          Nop j'ai pas de référence, j'avais vu ca en regardant la langue artificielle lojban qui a été inventée pour travailler sur cette hypothèse

                          La forme forte est réfuté car les humains sont capables de se représenter des concepts et de faire des raisonnements quand bien même ils ne possèdent pas de vocabulaire ou de langues adaptées. Ce qui indiquerait que le cerveau n'utilise pas forcement le langage pour manipuler les concepts.

                          La forme faible de l'hypothèse dit que le langage facilite le raisonnement, alors la on peut rentrer dans des polémiques sans fin (comme tu l'a dis c'est pas forcement réfutable). Forcement si on dispose d'une langue qui colle exactement a ce que l'on veux exprimer cela facilite les choses, d'un autre coté les êtres humains sont capable de créer de toutes pièces les représentation qui leurs manque ...

                          C'est tellement peu conforme à mon intuition et à mon expérience personnelle que je ne sais pas vraiment comment y répondre.

                          Je suis très probablement d'accord avec toi mais il faut absolument faire la distinction entre :
                          - le choix des lexèmes
                          - la syntaxe
                          - la sémantique

                          Le witespace n'a pas uniquement un choix lexical particulierement peu lisible mais aussi une sémantique très peu expressive. Si tu remplace les 3 lexemes (et non pas deux) qui sont " ", "\t" et "\n" par A,B et C en prenant bien soin de choisir A,B et C de telle manière que cela soit le plus lisible possible. Et bien cela restera illisible. Parceque la sémantique, c'est à dire le sens, que possède les mots clés ne permet pas de représenter facilement les choses.

                          Inversement si tu prend un langage très expressif et que tu lui colle des lexèmes et une syntaxe la moins claire possible cela restera facile à lire, car le cerveau est suffisament plastique par s'adapter a beaucoup de situation. Regarde par exemple le lambda-calcul, avec juste lambda, des parenthèses et des variables on peut réaliser des programmes très lisibles sont on indente les choses correctement.
                          • [^] # Re: Et beh...

                            Posté par  . Évalué à 2.

                            La forme forte est réfuté car les humains sont capables de se représenter des concepts et de faire des raisonnements quand bien même ils ne possèdent pas de vocabulaire ou de langues adaptées. Ce qui indiquerait que le cerveau n'utilise pas forcement le langage pour manipuler les concepts.

                            Ça ressemble plus à un indice contre l'hypothèse qu'à une réfutation formelle. Il est possible que notre langage influe sur la manière dont on pense et qu'on soit quand même capable de penser des choses difficiles à formuler dans notre langage.

                            Je n'y ai pas réfléchi en détails, mais je prend un exemple de ce qui me reste de mes souvenirs de Lojban. Il y a dans le langage une manière naturelle d'exprimer "à droite de X, qui me fait face", ou bien "à gauche de X, qui fait face à Y". Évidemment, on est capable de concevoir "à gauche de X qui fait face à Y" et de le traduire en position, mais ça demande toujours un temps de réflexion, et de nombreuses personnes ont du mal à imaginer les rotations d'objets ou de point de vue[1]. Il me semble que si ces gens parlaient une langue qui utilise ce genre d'indicateurs de position aussi naturellement que "à ma gauche", leur capacité de faire des rotations mentales serait plus développée. (Ou alors c'est une limite biologique et ils auraient du mal à comprendre les phrases, mais ça me semble moins probable.)

                            [1]: il me semble qu'on se sert d'ailleurs de ça dans certains tests psychologiques ou tests de QI: on montre une image de main et on demande si c'est une main gauche ou une main droite. Ou bien on demande "parmis ces images, laquelle est une rotation de cet objet ?".
                            • [^] # Re: Et beh...

                              Posté par  . Évalué à 3.

                              Perso mon intuition sur le sujet est que le language naît en fait du cerveaux et donc exprime une structure proche du raisonnement (c'est ma lecture ignarde des théories de Noam Chomsky http://fr.wikipedia.org/wiki/Grammaire_générative ).

                              Je pense que le probleme principale d'une syntaxe compliquée est que cette syntaxe te pompe une bonne partie de tes facultées (mémoire immédiate etc...) ce qui peut se dépasser par l'apprentissage (mais c'est bien du temps perdu).

                              Perso si j'aime Python par dessus tout c'est bien pour ça. De plus un langage de bas niveau te prendra plus de ligne qu'un langage de haut nivaue pour exprimer la même choses ce qui est là encore une mobilisation importante de tes facultés sur l'outil plutôt que sur le problème.
                      • [^] # Re: Et beh...

                        Posté par  . Évalué à 2.

                        La syntaxe n'a qu'un impact mineur sur la lisibilité des programmes. C'est d'abord les conventions collectives et les effort de chacun qui détermine le résultat.

                        Justement la syntaxe est la convention collective de base, intangible.
                        C'est pour cela qu'une syntaxe compliquée ou ambigüe entraînera du code moins lisible, même avec tous les efforts du monde.
            • [^] # Re: Et beh...

              Posté par  . Évalué à 4.

              C'est vrai que la syntaxe est tres importante, il suffit de voir les gens qui bossent sur la certification des logiciels de l'airbus par exemple. S'ils avaient eu une mauvaise syntaxe, l'avion ne volerait surement pas.
              Si vous avez une idee de meilleure syntaxe, qui permette de parser les instructions introduites sans avoir a parser le langage hote (C ou Java) et qui soit compatible avec les differents modes de vim ou d'emacs, je suis sur qu'elle sera retenue et qu'elle remplacera rapidement la syntaxe actuelle.
    • [^] # Re: Et beh...

      Posté par  . Évalué à 10.

      > après c'est immondice nommée Caml

      Apparemment, tu t'es bouffé plus de Caml que de grammaire...
      • [^] # Re: Et beh...

        Posté par  . Évalué à 2.

        Honnetement, je ne pense pas que le C demande moins de rigueur que Caml.
        J en bouffe egalement plein cette année, et ca me lourde egalement la syntaxe vraiment merdique (rien qu un if / else est mal foutu a la base vu que tu sais pas vraiment ou il se termine).

        Sans parler bien sur de l interface CamlWin. C est mal foutu.
        Pour dire, je m etais rapidement amusé a reprogrammer une interface en C, et j en ai pas eu pour longtemps pour faire qqchose de mieux foutue. Rien que de colorer la sortie en rouge pour une erreur apporte bcp en clarté.

        Enfin, voila, pour le peu que j ai vu des projets de l INRIA, ca reste assez decevant. A par en prepa / université, je vois pas ou ils sont utilisés tous ces langages.
        Pourtant, je vous assure que je cracherais pas sur un projet francais informatique bien foutu, par ex Lisaac pourrait me sembler sympa comme concept (j ai pas assez de connaissances en info pour reellement en juger), malheureusement, la syntaxe est encore loin de m attirer.
        • [^] # Re: Et beh...

          Posté par  . Évalué à 4.

          Si tu sais pas où se finissent les if/else, c'est que tu ne connais pas le C....

          Je ne sais pas, mais quand je vois:

          if (blabla) {
          foo();
          } else {
          bar();
          }

          Je ne vois pas comment on pourait se tromper...

          Et l'Isaac, c'est marrant, mais on en entend pas beaucoup parler....
          • [^] # Re: Et beh...

            Posté par  . Évalué à 2.

            Je crois qu'il parlait du if/else en OCaml. Un des défauts (à mon goût) d'OCaml, c'est que sa grammaire contient beaucoup d'exceptions qui peuvent le rendre difficile à lire pour un humain. La doc contient beaucoup de "quand c'est évident, on peut omettre [...]". Pour ma part, j'aime bien le Lisp, et j'aime bien rajouter des parenthèses en OCaml pour éviter tout doute. Quand on écrit: (if condition then 42 else 0), on ne peut avoir aucun doute.
        • [^] # Re: Et beh...

          Posté par  . Évalué à 2.


          Enfin, voila, pour le peu que j ai vu des projets de l INRIA, ca reste assez decevant. A par en prepa / université, je vois pas ou ils sont utilisés tous ces langages.


          Je ne pense pas que le but de l'INRIA soit de fournir le nouveau langage utilisé en prépa... et d'ailleurs c'est déjà fait puisqu'ils utilisent caml.

          Les langages qui sortent de l'INRIA sont souvents enseignés au départ dans l'université à laquelle le langage est rattaché, puis dans d'autres au gré de l'utilisation de ses langages par les équipes/thésards qui l'utilisent. SmartEiffel est enseignés dans bon nombre d'universités, et même à l'étranger par exemple.

          Mais je crois que le but d'un labo de recherche dans le domaine des langages informatiques, c'est de mettre le doigt sur un nouveau paradigme de programmation, même si ce n'est pas la première implantation de la chose qui sera retenue. De ce point de vue, TOM sort un peu des chemins battus puisqu'il propose un langage dont on pense qu'il peut vraiment apporter un plus tout de suite à l'industrie. Ca ne l'empêche pas d'introduire des notions intéressantes en recherche comme les ilôts formels, ou la combinsaison de stratégies... d'ailleurs puisqu'on en parle la sortie de TOM peut être certifiée à chaque compilation à l'aide des prouveurs coq et zenon.
        • [^] # Re: Et beh...

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

          Enfin, voila, pour le peu que j ai vu des projets de l INRIA, ca reste assez decevant. A par en prepa / université, je vois pas ou ils sont utilisés tous ces langages.

          Rien qu'en se limitant au monde linuxien mainstream, les logiciels suivants sont programmés en ocaml: advi, bibtex2html, camlgrenouille, coq, drgeocaml, findlib,
          freetennis, gmetadom, hevea, htmlc, ledit, mathplot, mldonkey, monotone-viz, omake, spamoracle, unison, et v6.

          D'autre part, la qualité d'un langage ne se mesure pas uniquement au nombre de ses utilisations (sinon C voire C++ seraient des très bons langages, affirmations avec laquelle de plus en plus de gens de tous horizons se distancient). On pourrait citer le fait que l'ICFP[1] a été gagné par un programme en ocaml (plusieurs fois je crois, mais je ne trouve pas les podiums facilement). On peut citer de nombreuses choses. Mais si on juge l'utilisation, on se retrouve noyé dans les obligations industrielles et on obtient des langages comme Cobol, Fortran, C, C++ ou Java en premier, alors que les programmeurs passionnés préfèrent (et utilisent) souvent des langages plus à la pointe.

          [1] http://www.cs.luc.edu/icfp/
    • [^] # Re: Et beh...

      Posté par  . Évalué à 3.

      Génial, après c'est immondice nommée Caml, les chercheurs de l'INRIA ont toujours pas compris la leçon
      Visiblement tu n'as rien compris à ta leçon!

      je me suis bouffé 1 an de Caml
      Le système éducatif Français est en partie basé sur la sélection ...

      Enseigner Ocaml en prépa ou en première année universitaire est à mon avis une erreur. Critiquer quelque chose qu'on comprend pas aussi!
  • # Inutile

    Posté par  . Évalué à 1.

    Quelle drole idee de faire une extension a ces vieux langages ?! c'est completement inutile, de toute facon tout le monde va passer a Isaac.
    • [^] # Re: Inutile

      Posté par  . Évalué à 1.

      En parlant de lisaac:
      http://linuxfr.org/2006/03/09/20473.html

      J'avais raté le fil a l'époque.
      J'ai une question, parce que ce n'est pas très clair dans ma tête.
      C'est une sorte de méta-langage, qui effectue des optimisations avant de transformer le code en C.
      Donc (je ne connais quasiment rien en compilateurs), on ne pourrait pas considérer qu'il empiète sur le boulot du compilateur?
      En gros, avec un compilateur qui va bien, on doit pouvoir se ramener avec un programme écrit en C au même niveau de performance/taille d'exécutable que ce qu'on arrive à faire avec Lisaac?
      • [^] # Re: Inutile

        Posté par  . Évalué à 4.

        c'est presque vrai sauf qu'il y a des infios que les langages haut niveau comme lissac ou caml, ou eiffel, ou même c++ (pas java par exemple) sont capable de fournir :

        si je veux faire une liste chaînée "générique" en C par exemple j'écris :


        struct linked_list {
        void* value;
        struct linked_list* next;
        };


        c'est le choix notemment de la glib.

        Maintenant en eiffel/c++ j'écrirai une liste chaînée réellement générique:


        template class linked_list ...


        et je l'instancie avec linked_list par exemple. (dans le cas de caml, le type est inféré, caractéristique qui semble avoir été mise de côté dans les débats ci-dessus mais peut-être que les personnes qui ont un peu vite vomi sur le langage n'en ont même pas pris conscience). Et là, même si du code C est généré par le compilo eiffel/c++/caml, il sera plus efficace parce que le compilo aura un vrai type à la place de void* et poura faire des optimisations sachant par exemple que le champ value ne pourra pas pointer sur linked_list.

        Le typage (qui comme par hasard est fort en caml) apporte donc des infos nécessaires à l'optimisation en plus de fournir une abstraction du programme assez proche du langage pour qu'une bonne partie des erreurs de programmation soit détectées à la compil.
        • [^] # Re: Inutile

          Posté par  . Évalué à 1.

          les classes templates ne sont pas passées parce que ça ressemble à une balise html

          il fallait lire

          linked_list< T >


          et


          linked_list< toto >
      • [^] # Re: Inutile

        Posté par  . Évalué à 8.

        Donc pour toi le C est une sorte de meta-langage d'assembleur ?

        Beaucoup de compilo performant sortent du C, c'est le cas de OCaml, et SmartEiffel par exemple.

        La raison à cela est que les optimisations réalisé par le compilateur C et Lisaac sont totalement indépendantes. Du coté C on s'occupe des spécificité des processeurs, utilisation correcte des registres etc Du coté du compilo Lisaac (ou n'importe quel autre langage au niveau comme eiffel ou caml) on fait des optimisations du style traitement du la récursion terminale, gestion du polymorphisme. Ce n'est pas du tout le même travail.

        L'autre chose a comprendre est que les compilateurs C ne peuvent pas faire ce genre de choses haut niveau car le langage n'est pas prévu pour. En C ou en C++ on est sensé gérer à la main les optimisations de haut niveau comme l'inlining en C++ ou décider de ne pas mettre un méthode virtual en C++ ou l'utilisation fine de pointeurs en C. A cause de ca le compilateur n'a pas la lattitude de faire des optimisation il doit suivre exactement les instructions du programmeur sinon le programme ne réalisera pas les choses de la façon exacte qui a été demandé et cela le fera planter.
        • [^] # Re: Inutile

          Posté par  . Évalué à 1.


          Donc pour toi le C est une sorte de meta-langage d'assembleur ?


          Touché ;-)
          Mais je suis tenté de répondre que le C est un langage de haut niveau, on ne peut donc pas placer C->asm sur le même plan que Lisaac->C

          Sinon, merci pour ces explications, je comprends mieux l'idée.
        • [^] # Re: Inutile

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

          Beaucoup de compilo performant sortent du C, c'est le cas de OCaml, et SmartEiffel par exemple.

          si tu veux dire par là que le compilateur OCaml génére du C qui est ensuite compilé par gcc, c'est complètement faux, le compilateur ocaml génère de l'assembleur directement.
          • [^] # Re: Inutile

            Posté par  . Évalué à 2.

            Ah ouais ? je savais pas.

            Ca a toujours été le cas ou au debut ils utilisaient le C ?
      • [^] # Re: Inutile

        Posté par  . Évalué à 6.

        En gros, avec un compilateur qui va bien, on doit pouvoir se ramener avec un programme écrit en C au même niveau de performance/taille d'exécutable que ce qu'on arrive à faire avec Lisaac?


        Probablement pas, parce qu'il est plus facile de descendre que de remonter.

        Pour ceux que cette explication ne satisfait pas, je vais essayer de faire mieux mais c'est pas gagné. Quand on écrit un programme dans un langage de haut niveau, les mots et les constructions du langage ont du sens qu'il n'est pas toujours possible de traduire dans le langage de bas niveau. Par exemple, dire qu'une classe hérite d'une autre a un sens si on se place à un certain niveau, mais le code en assembleur qui résulte de la compilation ne contient pas cette information.

        Pour retrouver l'information à partir du code de bas niveau, il faut être capable de l'analyser pour "remonter" dans les niveaux. Pour certaines choses, c'est possible, par exemple on peut assez facilement à partir de l'assembleur retrouver des structures de boucle. Mais est-ce toujours possible ?

        - Le programme compilé ne contient pas forcément toute l'information. Par exemple la hiérarchie d'héritage des classes ne sera probablement pas représentée en entier ou correctement.

        - L'analyse de programme est difficile. Tellement difficile que certaines choses sont impossibles. On ne peut pas, par exemple, faire un programme qui peut analyser n'importe quel programme et dire s'il s'arrête ou s'il boucle indéfiniment. D'un autre côté, je doute qu'il soit possible de faire un langage de haut niveau qui permet d'exprimer qu'un programme boucle sans que le code résultant ne puisse être analysé pour le déduire.

        - L'analyse de programme est difficile (bis). Un programme, c'est un graphe assez énorme, et pour "remonter", il faut être capable de découvrir des structures de haut niveau dans ce graphe, ce qui n'est pas évident. Pour prendre un exemple simplifié, prend une feuille de papier, et interroge des gens dans la rue. Pour chaque personne, inscris un rond avec leur nom, et puis si deux personnes se connaissent, relie leurs ronds par un trait. Une fois que c'est fini, essaye de retrouver les familles. Une famille, c'est une structure de haut niveau dans ton graphe des "connaissances", mais c'est incroyablement difficile à retrouver si on n'a pas l'information.
    • [^] # Re: Inutile

      Posté par  . Évalué à 1.

      de toute facon tout le monde va passer a Isaac


      Moins tous ceux qui seront passés à Sather...
      • [^] # Re: Inutile

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

        Bah écoutes, si tu veux mettre des concepts à la Sather dans Lisaac, les spécifications des versions 0.3 mais surtout 0.4 et 0.5 (l'implémentation de la 0.2 est en train d'être finalisée) ne sont pas encore figée, tu es invité (ainsi que vous tous linuxfriens !) à t'exprimer sur le sujet.

        On vient de monter un embryon de wiki.

        Tout est là, j'ai mis un section par numéro de version de la spec.

        Bref, Lisaac n'est pas un langage figée, masi un langage évolutif à conditions que les idées soient bonnes et restent cohérentes avec le reste.

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

        • [^] # Re: Inutile

          Posté par  . Évalué à 3.

          Ouais en plus pour le moment il n'y a pas de variance du tout. Donc il y a encore plein de place pour le troll/débat contra-variance vs co-variance ... ^_^
          • [^] # Re: Inutile

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

            Exactement, donc ayant oublié, je précise l'adresse :

            http://wiki.loria.fr/wiki/ProjetIsaac

            Je crois qu'il va falloir que je fasse un petit journal...

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

          • [^] # Re: Inutile

            Posté par  . Évalué à 2.

            Bah, pour éviter le troll; il suffit de mettre les deux comme dans Scala..

            Je sais je suis lourd avec Scala, je -->[]
        • [^] # Re: Inutile

          Posté par  . Évalué à 2.

          Bah écoutes, si tu veux mettre des concepts à la Sather dans Lisaac


          Ben pas du tout. C'était juste pour dire une blague, je connais à peine Sather. Et quitte à apprendre un nouveau langage, je me mettrais plutôt à Lisaac qui me semble avoir plus d'avenir.
    • [^] # Re: Inutile

      Posté par  . Évalué à 6.

      Arrêtez d'ecorcher sans arrêt le nom ce pov langage qui vous a rien fait.

      Son nom à lui c'est
      Lisaac et ce n'est pas un concurrent de Jacob
      • [^] # Re: Inutile

        Posté par  . Évalué à 1.

        Arg. Je m'autoflagele avec double ration, parce qu'en plus j'avais un doute, je suis alle voir sur le site, et... je me suis trompe en ecrivant.
  • # Hem

    Posté par  . Évalué à 5.

    J'ai toujours pas compris à quoi ça servait, même en lisant le tuto.

    Ca risque pas d'avoir un grand succès si personne ne sait à quoi ça sert et comment ça marche.
    • [^] # Re: Hem

      Posté par  . Évalué à 3.

      ça sert à rajouter des capacités de réécriture à des langages qui n'en proposent pas. (http://fr.wikipedia.org/wiki/R%C3%A9%C3%A9criture)

      Pour faire le lien avec une technologie connue, c'est comme du XSLT sauf qu'au lieu de réécrire des arbres XML on réécrit n'importe quelle structure de donnée, y compris les structures du langage hôte (par exemple, on peut réaliser un mapping de java XML dom vers tom et réécrire des arbres DOM).

      Un exemple d'utilisation réaliste est la section 3 du tutoriel ou on réécrit toutes les occurences de "if not a then b else c" en "if a then c else b" partout dans l'arbre abstrait d'un programme : on voit donc les applications pour les compilateurs.
    • [^] # Re: Hem

      Posté par  . Évalué à 4.

      Ça rajoute à des langages (Java, C...) des structures de contrôle permettant le pattern matching. Si tu connais le "match" d'Ocaml, tu es déjà un fan, sinon tu peux essayer de t'imaginer ça comme une version surpuissante du "switch" de C qui, au lieu de prendre des valeurs après "case" prendrait des motifs.

Suivre le flux des commentaires

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