Le langage ooc auto-hébergé - les nouveautés de rock 0.9.0

Posté par (page perso) . Modéré par Sylvain Rampacek.
Tags :
21
25
avr.
2010
Technologie
Après plus d'un an de développement, l'équipe d'ooc est heureuse de vous annoncer que le langage de programmation est maintenant auto-hébergé (c'est-à-dire que le compilateur est capable de se compiler lui-même) !

Ce progrès important est marqué par la sortie de la version 0.9.0 de rock, son compilateur, lui-même écrit en ooc. Cette version apporte son lot de nouveautés, telles que les interfaces (à la Java), les fonctions anonymes (closures, typiques des langages fonctionnels), ou encore les types énumérés (enums).

ooc est un langage de programmation orienté objet, compilé nativement, multi plates-formes (y compris la bibliothèque standard), mais surtout libre ! Compromis entre le Java/Ruby et le C, il permet de profiter d'un langage de haut-niveau sans faire l'impasse sur les performances.

Traduit en C par un compilateur source-à-source, puis compilé par un compilateur C (gcc, tcc, clang...), ooc est facile à étudier et permet d'utiliser des outils familiers tels que GDB, Valgrind etc. pour le déboguage. Parmi les nouveautés
  • Les interfaces proposent une solution à l'absence d'héritage multiple, permettant à une classe d'implémenter une série de 'protocoles' qu'elle garantit savoir gérer. Par exemple, une interface 'Enregistrable' permettra de sauvegarder un objet sur le disque dur sans s'occuper de son type sous-jacent.
  • Les fonctions anonymes, ou plus exactement 'closures', facilitent grandement l'implémentation d'applications orientées évènements, comme la plupart des applications graphiques, utilisant GTK+ par exemple. Elles permettent d'utiliser des variables définies en-dehors de la fonction, dans le contexte courant.
  • Les types énumérés servent à déclarer des variables qui peuvent prendre un ensemble fini de valeurs. On peut déclarer une énumération des couleurs, des jours de la semaine, des différentes options d'un programme, par exemple.
Plus de détails sur le langage et ses nouveautés sont disponibles sur le site officiel et sa liste de diffusion.

Rappelons au passage que le projet cherche des volontaires pour maintenir des paquets pour Ubuntu/Debian, Fedora, Arch, Gentoo, et autres distributions Linux.
  • # Bizarre

    Posté par . Évalué à 1.

    Je suis allé sur le site officiel et il est assez bizarre je trouve ce langage.

    Une boucle foreach sans iterateur (moi qui trouve jolie le fait d'avoir un iterateur) :
    for(i in list) printf("%d\n", list[i]) // operator overloading ftw

    L'opérateur "as" j'ai pas bien compris son fonctionnement.

    J'ai l'impression qu'il n'y a pas de fonction membres.

    J'ai pas bien senti la différence entre ":=" et "=" (mais ça je le met sur le compte de mon anglais).

    Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

    • [^] # Re: Bizarre

      Posté par (page perso) . Évalué à 3.

      Le for c'est un peu comme en javascript finalement.
      (Mais d'après le site y'a d'autres moyens de faire un for comme en Perl aussi, donc c'est un mix)

      la différence entre := et = c'est que := permet d'affecter et de définir par inférence la variable alors que = c'est juste une affectation.
      Par exemple :
      x: Int
      x = 5

      Est équivalent à :
      x := 5
      Et enfin je crois que le "as" est utilisé pour caster les variables.
    • [^] # Re: Bizarre

      Posté par (page perso) . Évalué à 2.

      J'ai pas bien senti la différence entre ":=" et "="

      D'après l'exemple en première page, a := b est un raccourci pour a : Type; a = b, où Type est inféré par le compilateur de façon intelligente.

      Une boucle foreach sans iterateur (moi qui trouve jolie le fait d'avoir un iterateur)

      Tu trouves les itérateurs jolis ? Au bon d'un moment, tu n'as pas marre d'aller chercher l'itérateur, le faire défiler à la main, vérifier s'il reste quelque chose ? Pour moi, faire défiler un intérateur est le genre de choses barbantes que mon compilateur pourrait bien faire à ma place...
      • [^] # Re: Bizarre

        Posté par . Évalué à 2.

        Eu je me suis mal exprimé, je voulais dire que je pense qu'une boucle comme :
        for(String file : listFiles) { System.out.println(file) }

        Utilise un itérateur (que tu n'a pas à gérer à la mimine).

        Les logiciels sous licence GPL forcent leurs utilisateurs à respecter la GPL (et oui, l'eau, ça mouille).

        • [^] # Re: Bizarre

          Posté par (page perso) . Évalué à 4.

          ben oui =) ça marche pareil en ooc

          for(file in listFiles) {
          file read() println()
          }


          'listFiles' peut-être n'importe quelle classe qui implémente Iterable, bien sûr.
    • [^] # Re: Bizarre

      Posté par (page perso) . Évalué à 6.

      Hello there,

      >> Une boucle foreach sans iterateur (moi qui trouve jolie le fait d'avoir un iterateur) :

      Fais-toi plaise, car

      for(i in list) printf("%d\n", i)


      Est exactement équivalent à:

      i: Int
      iter := list iterator()
      while(iter hasNext()) {
      i = iter next()
      printf("%d\n", i)
      }


      >> L'opérateur as

      ..sert à caster entre différent types. Donc en ooc,

      a := 3.14 as Int


      Est équivalent à

      int a = (int) 3.14f;

      en C/C++/Java

      >> J'ai l'impression qu'il n'y a pas de fonction membres.

      Les fonctions membres sont appelées comme ceci:

      monchien faitlebeau()


      , pas comme

      monchien.faitlebeau()

      Inspiré de Smalltalk/Io, c'est plus aéré - après on aime ou on aime pas =)
  • # Joli

    Posté par (page perso) . Évalué à 10.

    Très joli langage, je pense qu'il y a vraiment un besoin sur ce créneau. Quelques questions:

    - Est-il facile d'utiliser une bibliothèque écrite en C? En C++?
    - Est-il facile d'utiliser une bibliothèque ooc depuis le C? Depuis les langages dynamiques tels que python ou ruby?
    - Quelle est la librairie standard d'ooc? Avez-vous l'ambition de fournir à terme une bibliothèque "batteries included" comme python? (c'est à mon avis un facteur déterminant pour le succès du langage, en dehors des qualités du langage, bien sûr!)
    - Comment vous comparez-vous aux autres langages situés sur le même créneau: vala, lissaac, haskell, common lisp?
    • [^] # Re: Joli

      Posté par (page perso) . Évalué à 10.

      Est-il facile d'utiliser une bibliothèque écrite en C? En C++?

      En C, oui. Il suffit de déclarer les fonctions C comme 'extern', comme ici par exemple: [http://github.com/nddrylliog/rock/blob/master/custom-sdk/lan(...)]

      Pour le C++, c'est un peu plus délicat - en fait, c'est aussi facile qu'en C. C'est à dire facile si la librairie C++ en question a prévu une interface C... sinon, on cherche encore des solutions pour accéder plus facilement aux librairies C++, peut-être du côté de SWIG: [http://www.swig.org/]

      Est-il facile d'utiliser une bibliothèque ooc depuis le C

      Oui, même si ça fait des noms de fonctions un peu long =) du genre mon_package__MaClasse_maFonction() C'est pour ça que j'aimerais faire un générateur de headers C avec des #define qui permettraient de réduire ça à MaClasse_maFonction(), etc.

      Depuis les langages dynamiques tels que python ou ruby?

      Python: [http://github.com/fredreichbier/pyooc]
      Ruby: à faire =)

      Quelle est la librairie standard d'ooc? Avez-vous l'ambition de fournir à terme une bibliothèque "batteries included" comme python

      C'est en effet un facteur déterminant. Nous avons pas mal travaillé sur notre sdk [http://github.com/nddrylliog/rock/tree/master/custom-sdk] qui contient des classes pour les entrées/sorties, le réseau (sockets, etc.), le temps, différentes collections (ArrayList, LinkedList, Stack, HashMap, etc.), les threads, etc..

      Il reste des manques à combler, mais il y a pas mal de librairies sur GitHub par exemple des bindings pour CouchDB, sqlite, mais aussi curl, yajl (pour lire du JSON), curses, OpenGL, SDL, etc.

      Comment vous comparez-vous aux autres langages situés sur le même créneau: vala, lissaac, haskell, common lisp?

      Celui qui se compare le mieux ici est le Vala, dont la différence fondamentale est que son runtime est largement basé sur la GLib. ooc est donc une solution plus légère (les GObjects sont relativement lourd, tant niveau performance que taille de la dépendance)

      Je ne connaissais pas vraiment Lissaac mais il semble que ce soit un langage orienté prototype, c'est à dire qu'au lieu d'avoir une hiérarchie de classes, on peut cloner un objet et lui ajouter des méthodes. Cela semble plus dynamique que de l'ooc - donc forcément, avec un coût à l'exécution =) Mais intéressant tout de même.

      Quant à Haskell et CL, ils ont bien plus d'aspects fonctionnels qu'ooc à l'heure actuelle. Nous nous en rapprochons toutefois dernièrement (avec les closures). Les list comprehensions sont également prévues pour bientôt, afin de permettre l'évaluation paresseuse (lazy evaluation).
      • [^] # Re: Joli

        Posté par (page perso) . Évalué à 3.

        Merci beaucoup pour cette réponse détaillée, et bon vent pour la suite!
        • [^] # Re: Joli

          Posté par (page perso) . Évalué à 2.

          Merci! On vous tiendra au courant à la prochaine version majeure =) (Autant dire qu'il y a du pain sur la planche)
      • [^] # Re: Joli

        Posté par . Évalué à 8.

        Dans le même ordre d'idée, j'ai moi aussi quelques questions à vous poser :

        - Prévoyez-vous une soumission au Shootout[1] ? Vala, dont vous parlez plus haut n'a pas, il me semble, été accepté mais les résultats paraissaient plutôt bons[2] et proches du C. Où pensez-vous que se situe OOC en termes de performances ? Peut-on d'ores et déjà l'estimer au dessus de ce qu'obtiennent Java ou C# Mono ?

        - En dehors de Vala, OOC me fait également penser à Go. Certes Go n'est pas un langage objet et de nombreuses choses différencient les deux langages. Néanmoins, il semblerait que Go essaie à moyen terme de trouver un bon compromis entre performances brutes, concurrence, simplicité de développement (dont le temps de compilation) et batteries incluses. Comment OOC se positionne-t-il au niveau de la concurrence ? Par rapport au développement, si je comprends bien, cela se passe comme Vala : une première compilation ou traduction vers du C puis une seconde phase par un compilateur C. Est-ce que cela ne risque pas de rendre le développement de programmes complexes assez long ? (bien des aspects m'échappent certainement, étant donnée mon inculture des langages compilés et de leurs écosystèmes, d'où la question !)

        - Il existe un micro-framework[3] orienté développement Web pour OOC; imaginez-vous qu'OOC puisse être employé dans ce cadre ou n'est-ce pas vraiment le but ?

        - Ruby a RoR, Vala a l'environnement Gnome, Go a Google et une équipe renommée - je sursimplifie, veuillez m'en excuser - pensez-vous à orienter consciemment OOC vers un certain type de développement (bases de données, jeux vidéo... ) ?

        En tout cas bravo.

        1 : [http://shootout.alioth.debian.org/]
        2 : [http://code.google.com/p/vala-benchmarks/wiki/BenchResults]
        3 : [http://github.com/joshthecoder/ooc-web]
        • [^] # Re: Joli

          Posté par (page perso) . Évalué à 8.

          Mais c'est une véritable interview! J'aurais dû prendre ma cravate ;)

          - Shootout: quelqu'un vient de suggérer la même chose sur IRC =) C'est à considérer. Cependant, il y a des énormes possibilités d'optimisations qui ne sont pas encore implémentées (je pense notamment à la spécialisation de types génériques au temps de l'exécution, pour les initiés), et donc je ne sais pas trop comment ooc se comparerait si on utilise beaucoup les collections. A suivre, je dirais.

          - Rendre le développement des programmes long? Au niveau des temps de compilation? Pour cela il y a la recompilation partielle, qui permet de recompiler uniquement les modules qui ont changé. C'est un gain de temps très apréciable. D'autre part, nous envisageons de développer une REPL, ce qui permettait de modifier un programme pendant son exécution et ainsi avoir quasi le même confort qu'un langage interprété. Au niveau de la concurrence (e.g. le parallélisme, pas la rivalité ^^), c'est un sujet qui soulève bien des discussions dans la communauté. Nous ne sommes pas fixés sur une solution définitive, nous préférons nous donner du temps pour expérimenter et tester les différentes variantes afin de choisir celle qui nous semble la meilleure.

          - Absolument, l'utilisation d'ooc côté serveur est tout à fait intéressante, et il semble y avoir une vague d'intérêt dans ce sens-là (nouveaux contributeurs à ooc-web/ooc-couchdb, etc.)

          - Pour rebondir sur la question précédente, ooc a plutôt vocation de rester un langage généraliste. Personellement j'essaie (entre autres) d'explorer son utilisation dans le développement de jeux vidéos (en conciliant une grande flexibilité avec la performance), mais le langage reste un bon substitut à Java/C# dans la plupart des cas, si l'on souhaite un runtime plus léger et une compilation native. ooc présente aussi une alternative intéressante au C sur les plateformes embarquées, même s'il reste des progrès à faire de ce côté là, des collaborations sont en cours pour mieux adapter ooc pour l'embarqué, notamment un sdk allégé.

          Merci pour les encouragements, quoi qu'il se passe, nous continuerons à vous tenir au courant!
          • [^] # Re: Joli

            Posté par (page perso) . Évalué à 4.

            Qu'y a-t-il comme bindings pour faire du jeu video avec OOC ? SDL ? OpenGL ?
      • [^] # Re: Joli

        Posté par . Évalué à 6.

        Les list comprehensions sont également prévues pour bientôt, afin de permettre l'évaluation paresseuse (lazy evaluation).

        Quel est le lien entre les 'list comprehensions' et l'évaluation paresseuse ?
      • [^] # Re: Joli

        Posté par . Évalué à 1.

        "Je ne connaissais pas vraiment Lissaac mais il semble que ce soit un langage orienté prototype, c'est à dire qu'au lieu d'avoir une hiérarchie de classes, on peut cloner un objet et lui ajouter des méthodes. Cela semble plus dynamique que de l'ooc - donc forcément, avec un coût à l'exécution =) Mais intéressant tout de même."

        Il n'y a heureusement aucun surcout à l'exécution. La preuve est que Lisaac a été premier pendant un moment dans le langage shoutout, avant que les implémentation C et C++ soit modifié.

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

        • [^] # Re: Joli

          Posté par . Évalué à 4.

          Il n'y a heureusement aucun surcout à l'exécution.

          Par contre, il y a un algorithme de compilation en temps exponentiel et pas de compilation séparée, non ?
          • [^] # Re: Joli

            Posté par . Évalué à 3.

            oui.

            Sachant que compiler 50 000 lignes de code prend quelques dizaines de secondes, la "constante" est faible.

            C'est un des axes d'améliorations du langages : passer à l'échelle du millions de ligne de code, et prévoir un système pour compiler à part le module en court de développement pour diminuer le temps de recompilation (le temps le plus long est pris par gcc).

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

      • [^] # Re: Joli

        Posté par (page perso) . Évalué à 8.

        Je ne connaissais pas vraiment Lissaac mais il semble que ce soit un langage orienté prototype, c'est à dire qu'au lieu d'avoir une hiérarchie de classes, on peut cloner un objet et lui ajouter des méthodes. Cela semble plus dynamique que de l'ooc - donc forcément, avec un coût à l'exécution =) Mais intéressant tout de même.

        Effectivement, il est à prototype et héritage multiple, donc le parent s'affecte comme un slot normal que tu peux changer ou tu veux dans le code. Le parent a une existence physique propre (ou pas, car il y a 4 formes d'héritages différents en Lisaac).

        Concernant le coût du dynamisme, il n'y en a pas, d'une part parce que le compilateur n'utilise pas de VFT contrairement au votre *
        Lisaac** utilise des branchements dichotomiques, et transforme 99,6% (mesuré sur le compilateur, 400 000 appels, de l'héritage statique et dynamique dans tous les sens) des appels polymorphique en appel statique.
        Conclusion : tu n'as aucun cout pour le dynamisme. Et heureusement parce que dans ce langage, le if est un point de liaison dynamique, ne pas le faire serait catastrophique.

        Les VFT c'est lent, et ça a un cout énorme à l'exécution car :

        - Tu ne peux inliner
        - Le processeur ne peut pas optimiser car tu fais un jump indirect sur du code
        --> Tu dois garder tout tes objets en mémoire
        --> Certains objets ne peuvent décemment pas l'être pour des raisons de perfs. Par exemple, dans IsaacOS, et dans la GUI de la lib lisaac, par exemple, PIXEL est un objet, qui a des enfants PIXEL_16, PIXEL_8, PIXEL_32, etc.... Avec un modèle à VFT comme dans ooc, ça ruine les performances, parce que ça t'oblige à utiliser des VFT pour chaque appel de fonction sur tes pixels...

        Conseil : regarde ce qu'a fait Dominique Colnet dans son smarteiffel : c'est implémentable en ce qui vous concerne, parce que l'algorithme d'analyse de flot de Lisaac, c'est une autre paire de manche (surtout que votre langage est gros, ce qui simplifie pas la tâche).

        Et bon courage, parce que je sais de quoi je parle, et ça rend solidaire ;-)


        *
        Ce code :
        Animal: abstract class {
        shout: abstract func
        }

        Dog: class extends Animal {
        shout: func { "Woof, woof!" println() }
        }

        Cat: class extends Animal {
        shout: func { "Meoooww!" println() }
        }

        poke: func (animal: Animal) {
        animal shout()
        }

        poke(Dog new())
        poke(Cat new())

        Donne lieu à une VFT dans le C produit :

        void test__Animal_shout(test__Animal* this) {
        ((test__AnimalClass *)((lang_types__Object *)this)->class)->shout((test__Animal*)this);
        }


        **C'est expliqué ici http://www.dailymotion.com/video/xba8ij_1-8-presentation-du-(...) ou dans les suivantes.
        Tu as la vidéo des JM2L aussi, plus courte et synthétique.

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

    • [^] # Re: Joli

      Posté par (page perso) . Évalué à 7.

      Très joli langage, je pense qu'il y a vraiment un besoin sur ce créneau.

      C'est quoi le créneau de ce langage ?
      • [^] # Re: Joli

        Posté par . Évalué à 4.

        C'est quoi le créneau de ce langage ?

        Le créneau des langages libres proche du C, orientés objets, avec types statiques?

        Dans ce domaine, e développeur libre a le choix entre un Java bloated et un Mono piégé.

        Vala et ooc sont donc les bienvenus!
        • [^] # Re: Joli

          Posté par . Évalué à 4.

          Le créneau des langages libres proche du C, orientés objets, avec types statiques?

          Dans ce domaine, e développeur libre a le choix entre un Java bloated et un Mono piégé.


          Hum, tu trouves que Java et C# sont « proches de C » ? J'aurais plutôt cité C++, D, Go...
  • # Canal IRC en français o/

    Posté par (page perso) . Évalué à 4.

    Juste pour signaler que pour l'occase, un canal IRC en français a été créé sur Freenode, n'hésitez pas y passer si vous avez des questions en particulier: #ooc-lang.fr
  • # Un petit avis

    Posté par . Évalué à 1.

    _Les { } et pas de ";" ? c'est pas cohérent à mon sens
    _Une syntaxe qui force le style à la python me semble le choix le plus judicieux.(j'en voit que des avantages)(enlever les "{",passage de ligne obligé,...)
    _L'absence de "." pour appeler les membres (alors que c'est une habitude dans la majorité des langages) rend celui ci largement moins lisible.
    _J'aurai bien aimé un seul opérateur d'affectation (":=") l'a il va y avoir confusion et on perd l'intérêt d'enlever "="(confusion avec "=="). (oui,totalement supprimer "=")
    _Le GC: ne peut pas être desactivé apparament
    _Librairie standard dépendante du C?

    En tout cas de trés bonnes idées sur les autres choses et une trés bonne initiative pour essayer de remplacer le viellisant C
    • [^] # Re: Un petit avis

      Posté par . Évalué à 3.

      un truc, ce sont les 'use toto' qui injectent tout le contenu du paquet/module dans le namespace courant. du coup, il n'y a pas vraiment de moyen de savoir que sqrt provient de 'math' dans le code suivant:
      use math
      
      x := sqrt(100)
      
      ce qui est tres genant quand on (re)lit du code... bon, ou sinon, c'est un langage qui a l'air d'etre sympa, meme si la concurence est rude (vala/genie, go-lang)
      • [^] # Re: Un petit avis

        Posté par (page perso) . Évalué à 1.

        • [^] # Re: Un petit avis

          Posté par . Évalué à 4.

          oui, j'avais remarque la possibilite de faire un import selectif. donc en ooc on peut ecrire:
          use math
          x := sqrt(100)
          
          import math/[sqrt]
          y := sqrt(100)
          
          si je fais le parallele avec python:
          import math
          x = math.sqrt(100)
          
          from math import sqrt
          y = sqrt(100)
          
          donc, si je comprends bien, dans ooc on peut faire les deux mais dans le premier cas, le nom que l'on importe n'est pas completement qualifie...
          • [^] # Re: Un petit avis

            Posté par (page perso) . Évalué à 4.

            Non ce n'est pas encore vraiment ça =)

            'use math' permet.. d'utiliser la librairie math, donc d'avoir les bonnes options pour le compilateur C, telles -lm (définies dans le fichier math.use)

            'import math' importe tous les types, fonctions, variables dans le contexte courant.

            'import math into math' importe tout dans un namespace ce qui permet de faire ce que tu voulais faire en python.

            Le code correct est donc:
            use math
            import math

            x := sqrt(100)


            et
            use math
            import math into math

            x := math sqrt(100)


            Note que tu peux donner n'importe quel nom au namespace après le "into", tu peux donc l'appeler "sysmath" par exemple pour ne pas confondre si tu as ton propre module math.
    • [^] # Re: Un petit avis

      Posté par (page perso) . Évalué à 2.

      _{} et ";"

      C'est vrai, ça choque. De là à dire que c'est "incohérent" je ne sais pas.. peu familier j'admet =)

      _Une syntaxe plus à la python

      A ce point, il est un peu tard pour changer aussi lourdement la syntaxe. Toutefois, jette un oeil à http://cobra-language.com/ ça pourrait t'intéresser ma foi =)

      _L'absence de "." pour appeler les membres

      Il y a des précédents, notamment Smalltalk et Io. Après, c'est une question de goût et aussi d'habitude. Ça choque au début, mais au final beaucoup préfèrent.

      _Un seul opérateur d'affectation

      Débat millénaire, comme d'hab! L'opérateur ":=" sert a déclarer *et* assigner une variable, ce qui est tout à fait logique, si on part de:
      i : Int = 42
      et qu'on enlève le type, on obtient
      i := 42
      Voilà d'où vient cet opérateur.
      Pourquoi ne pas avoir permis

      _Le GC

      .. peut être désactivé, un petit -gc=off, et c'est réglé =) (Bon bien sûr la librairie standard n'est pas prévue pour donc ça c'est si tu veux faire ton propre SDK. Ce qui se fait tout à fait, voir le projet oos de tsion sur GitHub)

      _Librairie standard dépendante du C?

      L'implémentation courante oui mais rien n'empêche une implémentation alternative, ça s'utiliserait de la même manière.
  • # Ook?

    Posté par . Évalué à 5.

    C'est très différent du langage Ook ? :)
    http://fr.wikipedia.org/wiki/Brainfuck#Ook.21
  • # Cross compilation?

    Posté par . Évalué à 3.

    Est-ce qu'il est prévu de gérer la cross compilation simple?

    En effet, fournir des binaires pour différents OS est une tâche pénible avec tous les langages compilés que je connais, car il faut soit disposer de tous les OS avec un environnement de développement, soit être un pro du makefile.

    Ce serait bien de pouvoir tout générer avec un simple :


    ooc --platforms=linux,macosx,windows ...
    • [^] # Re: Cross compilation?

      Posté par (page perso) . Évalué à 3.

      En effet, la cross-compilation est souvent un vrai défi =)

      Bien que je n'aie que peu d'expérience dans le domaine (pour rock 0.9.0, nous avons compilé les binaires sur chaque OS), voici ce que je peux dire:

      1) rock dispose de l'option '-driver=make', ce qui permet d'exporter le programme compilé sous forme de sources C dans un dossier build/, avec un Makefile multi-plateforme. Ce qui réduit "l'environnement de développement" nécessaire à.. gcc + les librairies C utilisées.

      2) le code C produit par rock est le même quel que soit l'OS sur lequel on le compile. Ce sont des #defines à l'intérieur du code C qui utilise l'une ou l'autre partie du code.

      3) Pour ce qui est de la compilation cross-platform, il faut dans tous les cas un cross-compilateur C installé, non? Il me semble que des distros comme Gentoo rendent cela partiulièrement facile, je ne sais pas pour les autres.

      A noter qu'on peut spécifier à rock de choisir la version de gcc qu'on veut, par exemple -gcc=i686-pc-linux-gnu-gcc
  • # Un langage amateur sympa, mais qui se prend trop au sérieux

    Posté par . Évalué à 10.

    Je m'intéresse beaucoup aux langages de programmation, et je vois toujours d'un bon oeil le fait que les gens expérimentent dans le domaine, en travaillant sur une petite implémentation, des idées qu'ils ont pour corriger les problèmes des langages existants, etc.
    Je pense donc qu'ooc est une bonne idée (écrire un langage, c'est amusant, donc c'est toujours une bonne idée), et je trouve l'aspect communautaire sympa.

    Par contre, je trouve l'approche pas très rigoureuse. Le langage n'est décrit nulle part. J'aimerais bien savoir, par exemple, comment fonctionne l'algorithme d'inférence des types. Je suspecte que c'est un algorithme très ad-hoc (les sources par d'un "funny score system", hmm...); je trouve un peu dommage de parler d'inférence (on pense tout de suite aux langages avec une vraie inférence de type) pour un truc au final plutôt limité, et surtout imprévisible parce que non spécifié : on est un peu déçu.
    De même, je trouve dommage de présenter comme "pattern matching" un sucre syntaxique qui ajoute implicitement des tests d'égalité à une variable de 'switch'. Le vrai pattern matching ( http://fr.wikipedia.org/wiki/Filtrage_par_motif ) est beaucoup plus puissant que ça, donc quand on se rend compte de ce que c'est en ooc, on est déçu.

    Dans ce contexte (l'inférence n'est pas une vraie inférence, le pattern matching n'est pas un vrai pattern matching, j'espère que vos closures sont de vraies closures !), je pense qu'on peut difficilement décrire ooc comme un langage "functional-ish" : vous avez des fonctions imbriquées et anonymes, c'est bien, c'est mieux que le C, mais le langage ne me semble pas fonctionnel pour autant.


    Je pense que la documentation manque un peu de rigueur. J'aimerais bien une description précise et globale du langage quelque part : une description de la syntaxe et de la sémantique du langage. Je pense qu'il serait aussi important de détailler quelque part les raisons qui vous ont poussé à lancer ce projet, une comparaison avec les concurrents (Vala ?), et surtout quelques défauts (temporaires et conceptuels) du langage : c'est bien de présenter ce que vous faites bien, mais il faudrait aussi essayer de dire ce qui est moins bien.
    • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

      Posté par (page perso) . Évalué à 4.

      Ma foi, je n'ai pas le temps de répondre à tout, mais voici quelque points:

      Voici une grammaire formelle: http://github.com/nddrylliog/nagaqueen/blob/master/grammar/n(...)

      Effectivement l'inférence est limitée, puisqu'on interagit avec le C et que, d'autre part, on aime bien profiter d'une certaine sûreté (type checking). Pour du tout-inféré, voir ML ou quelque-chose du genre.

      Quant au manque de documentation, je suis le premier à le dénoncer. C'est réellement une question de gestion du temps. Tant que le langage était l'affaire de quelques-uns dans la communauté nous pouvions nous permettre de se limiter à la culture orale/IRC. C'est maintenant qu'apparaît la nécessité d'écrire une *vraie* documentation, et croyez-moi, il y a des efforts dans ce sens-là =)

      Pour ce qui est du pattern matching, c'est également prévu. Mais de nouveau, il faut bien commencer quelque-part, n'est-ce pas? Nous préférons exposer ce qui est déjà fait tout en restant dynamiques et en publiant régulièrement des versions, plutôt que d'en faire un projet de recherche, de lâcher une version "finie" sur un FTP et de ne plus jamais y toucher (non, je ne vise personne).

      En bref - tes critiques sont valides, je les reconnais, nous sommes au courant, et on y travaille =) Merci quand même de ton attention.
      • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

        Posté par (page perso) . Évalué à 0.

        >> Voici une grammaire formelle: http://github.com/nddrylliog/nagaqueen/blob/master/grammar/n(...)

        Non, voici un fichier utilisé par le parser.
        C'est pas ce que j'appelle une grammaire formelle (et ça participe donc aussi au manque de documentation.)


        Et sinon, vous faites quoi dans la vie ? Je veux dire (sérieusement) : « ce langage est-il développé par des gens qui (f)ont un doctorat en sémantique ? » ou juste par une bande d'amateurs qui se fait plaisir ?
        • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

          Posté par (page perso) . Évalué à 6.

          Courage, la molette est toujours utile de nos jours:

          http://github.com/nddrylliog/nagaqueen/blob/master/grammar/n(...)

          EBNF c'est tellement années 1970, il faut se moderniser un peu, vraiment, on a inventé ça depuis: http://en.wikipedia.org/wiki/Parsing_expression_grammar

          (Et sinon, le doctorat c'est peut-être pour dans quelques années, mais pour ma part en Informatique à l'EPFL - sauf que je vois absolument pas l'intérêt de la question..)
        • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

          Posté par (page perso) . Évalué à 4.

          D'autres réflexions:

          Vous connaissez beaucoup de langages amateurs qui sont self-hosting? Si on s'y était vraiment pris au petit bonheur la chance, on en serait jamais arrivé là. "Oh vous savez, on a empilé 13500 lignes de code jusqu'à ce que ça se compile"..

          Même si le manque de documentation est réel (mais là encore, si vous n'avez aucunement l'intention d'en faire usage - en quoi cela vous dérange-t-il?), cela me semble être une excuse pour ne pas creuser plus profond. En restant en surface, c'est facile de critiquer - le site est daté, les développeurs ont le sens de l'humour (donc ne se prennent pas trop au sérieux justement) - en passant à côté des qualités du langage et de l'implémentation, ce dont il serait tellement simple de s'en rendre compte en prenant la peine de l'essayer..
          • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

            Posté par . Évalué à 8.

            Et c'est dommage de se braquer et de ne pas écouter la critique, même si elle n'est pas plaisante à entendre.

            Un langage massivement utilisé comme php souffre encore énormément de l'amateurisme complet qui a donné lieu à sa naissance. Un langage pourtant très professionnel comme C++ s'est gardé pendant des années une restriction débile sur le double-chevron des génériques, parce que les gens ont loupé l'implication grammaticale que cela imposait.

            Bref, formaliser plus les choses, ça me semble une étape importante au vu de l'avancement de votre projet.
            • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

              Posté par (page perso) . Évalué à 3.

              J'ai effectivement tendance à prendre trop à coeur ce genre de critiques - mais je jure sur la tête de Bjarn que j'écoute et je prend en compte.

              Toujours dans la série des nouvelles que je ne devrais pas annoncer si tôt, il y a un projet de livre exhaustif sur ooc, et de redesign complet du site web.

              Un vrai spec final naîtra avec la sortie de rock 1.0, pour éviter d'avoir trop à réécrire d'ici là (mais rien ne nous empêche de faire un brouillon d'ici là - tant que les gens sont conscients que des choses peuvent encore changer)
              • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                Posté par (page perso) . Évalué à -1.

                >> J'ai effectivement tendance à prendre trop à coeur ce genre de critiques

                Tu t'adresses pas à moi en parlant de critique là, j'espère ?
                Un fichier de code n'est pas ce que j'appelle une grammaire formelle, surtout s'il faut chercher la grammaire au milieu du bruit du fichier. Le code, c'est pas formel pour deux sous. C'est pas une critique du langage ou quoi que ce soit, c'est un fait : le formalisme repose aussi dans la présentation ; dans un fichier à part, par exemple comme sur [http://people.csail.mit.edu/jaffer/r5rs_9.html]

                Ensuite, je demandais honnêtement quel était votre compétence/connaissance. En fonction de votre expérience je sais que je ne trouverais pas les mêmes procédés d'implantation du langage (typiquement au niveau de la représentation interne des objets ou le choix du système de type). Je n'ai *rien* dit sur le langage lui même, vu que je n'ai pas assez lu la doc ni les exemples.
          • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

            Posté par . Évalué à 7.

            L'intérêt de la documentation, d'une spécification un peu formelle (mais pas forcément complètement) du langage, c'est de pouvoir savoir rapidement ce qu'est votre langage : une énumération exhaustive de ses constructions, et une description précise, par exemple, de son comportement à l'exécution, de ses règles de typage, les algorithmes d'inférence de type et de garbage collection (si ça intéresse des gens : c'est un Boehm GC).

            Le parser est un bon départ : tu pourrais le prendre à l'identique, enlever toutes les productions (garder que la partie "grammaire"), et mettre ça sur le site, ça serait déjà un bon progrès.

            Ce que j'ai cherché sur votre site, c'est l'analogue de ce document pour Go : The Go Programming Language Specification.
            Dans un deuxième temps, je serais intéressé par un condensé d'informations sur les nouveautés du langage et les choix que vous avez fait. Pour Go, c'est ce document : Language Design FAQ.


            J'ai effectivement remarqué le sens de l'humour (entre nous, je me demande si le "THREE FUCKING TIMES" ne risque pas de rebuter certains anglophones, c'est quand même un peu vulgaire), ça a son charme, mais je trouve le texte en page d'accueil trop long et trop verbeux : quand on regarde 5 minutes un nouveau langage, on a besoin de quelque chose de plus dense et informatif. Le "Poignant guide to Ooc", c'est pour dans un second temps.
            Par contre, il faut retenir les exemples de code source, c'est une très bonne idée.

            Bref, je pense qu'une documentation concise mais précise et complète serait le meilleur moyen, justement, d'éviter les remarques superficielles, en permettant aux gens d'avoir un aperçu en profondeur du langage en un temps raisonnable.
            Parce que "prendre la peine de l'essayer", c'est une bonne idée, mais pour pouvoir tout essayer il faut commencer par se renseigner sur tout ce qu'il y a, justement, à essayer; et si on essaie mais passe à côté d'une partie des fonctionnalités, c'est dommage.


            Pour revenir au "se prend trop au sérieux" (opposé à l'humeur et la détente dans les docs) : ce que je voulais dire, c'est que quand on va sur le site web, on lit en gros (j'exagère volontairement le trait) « ooc est un roksor langage qui se base sur des techniques ultra-modernes, s'inspire de C, Smalltalk, Java, Ruby et Haskell, qui va résoudre tous vos problèmes en conservant des performances de brute »
            On peut considérer ça comme de l'humour, mais moi qui suis bonne poire, je me suis sérieusement attendu à voir tout ce que vous évoquiez dans ce descriptif, et donc forcément j'ai été un peu déçu.

            Je pense qu'il vaut mieux se contenter des quelques points clés de votre langage, sans faire de la surenchère.
            Par exemple, ooc est compilé vers du C, ça a l'avantage de vous garantir une bonne compatibilité, et c'est bien d'en parler. Par contre, c'est moins bon pour les performances et/ou l'extensibilité du langage : vous ne pouvez plus utiliser un GC exact, difficile d'optimiser la tail-recursion, etc. Il faut en parler aussi.


            PS : moi non plus je ne comprends pas la question sur les "doctorants en sémantique"; il n'y a pas besoin d'être un spécialiste de la théorie pour monter son petit langage.

            Ce que sous-entendais peut-être la question, c'est qu'il y a eu beaucoup de recherche sur les langages de programmation depuis l'avènement du C, qui est malheureusement assez soigneusement ignorée par la plupart des langages "modernes" de cette catégorie (D, Go, etc.). C'est vrai que c'est dommage, et ooc ne déroge pas à la règle.
            Après, moi je trouve que, dans le cas de ooc, c'est compréhensible et même tout à fait normal. C'est ce que j'appelle le point de vue "langage amateur" : il s'agit de se faire plaisir, de s'intéresser à l'implémentation d'un vrai langage, de réfléchir sur certains points (la syntaxe par exemple), etc. Pas de révolutionner le domaine.
            • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

              Posté par . Évalué à 2.

              Excusez-moi, mes liens ne sont pas passés.

              Go Language Specification : http://golang.org/doc/go_spec.html
              Go Language Design FAQ : http://golang.org/doc/go_lang_faq.html
            • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

              Posté par (page perso) . Évalué à 4.

              >> PS : moi non plus je ne comprends pas la question sur les "doctorants en sémantique"; il n'y a pas besoin d'être un spécialiste de la théorie pour monter son petit langage.

              Il n y a pas besoin, non. Mais si tel est le cas, autant le dire. En effet, les raisons qui poussent a creer un nouveau langage (ou a reimplanter un langage existant) ne sont surement pas les memes.
              • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                Posté par . Évalué à 8.

                Bien sûr, mais j'ai envie de dire que "quand c'est le cas, ça se voit" : ce n'est pas "un langage de programmation moderne qui propose fermetures et des interfaces" mais plutôt "un langage de programmation fonctionnel réactif par contraintes, basé sur un système d'effets et proposant une gestion fine de la stratégie d'évaluation par coercions explicites".

                Je trouve que ça manque un peu de tact quand tu évalues le travail de quelqu'un de lui demander d'abord s'il est spécialiste dans le domaine. Soit il l'est, et normalement on s'en rend compte, soit il ne l'est pas et il pourrait se vexer. On peut aussi bien se comporter en fonction du travail seulement, et pas de la personne, et ça évite ce genre d'embarras.
                • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                  Posté par (page perso) . Évalué à 2.

                  Mais je n'ai pas evalue' justement !
                  Le thread parle de langage amateur, je demande si c'est le cas ou non : "etes vous des amateurs ou pas ?"

                  Ca se voit pas forcement, loin de la. Quand un gars comme Joe Marshall se fait traiter de noob [http://funcall.blogspot.com/2010/04/education-of-jrm.html] je me dis que c est pas toujours evident, non...
                  T as des langages simples fatis par des pros, et l inverse aussi. Et encore une fois, en fonction de l historique de chacun, on peut se faire une idee de la maniere utilisee pour developper le langage. S il n est pas un pro, il y a peu de chances qu il aie des fermetures avec partage de code (comme dans (\x. if x then 2 else (\y. x+y))) ou` une seule fermeture (avec double pointeur de code) peut suffire. Pour les gens qui regardent juste la syntaxe, ca change rien. Pour moi, ca change tout, car c'est cette partie qui m interesse. Le langage en soit, je m'en tape. Je ne suis ni pour, ni contre, et je n emet aucune critique, aucun jugement a son egard : je n'ai qu a peine survole' la page d'accueil !
                  • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                    Posté par (page perso) . Évalué à 4.

                    @bluestorm: Merci pour l'explication, je comprend mieux ton point de vue. J'ai censuré le tutoriel (il y a le bon et le mauvais contributeur..). La page d'accueil est trop longue, on va la refaire en se basant plutôt sur un modèle à la http://rubini.us/
                    Concrètement qu'est-ce qui t'as déçu par rapport à la description de la page d'accueil?

                    @utf8powa:
                    « Release early, release often » -- Eric Steven Raymond, The Cathedral And the Bazaar
                    « Premature optimization is the root of all evil. » -- Donald Knuth, Computer Programming as an Art
                    « Version 1 sucks, but ship it anyway » -- Jeff Atwood, Coding Horror
                    « One must learn by doing the thing; for though you think you know it, you have no certainty, until you try » -- Sophocles

                    Et si au lieu de voir les petits détails faciles à régler pour une version ultérieure tu voyais le côté positif pour changer?

                    L'implémentation des fermetures à double pointeur, c'est trivial. Nous avons implémenté le plus difficile - les femetures avec partage de code (peu importe le nom qu'on leur donne), ce qui permet de les passer comme pointeurs vers des fonctions à des fonctions C.

                    On pourrait penser que le numéro de version (0.9) donnerait une indication quand à la nature *pas terminée* du langage, mais manifestement, non, on aurait pu mettre les décimales de pi (cf TeX) ça aurait été pareil ^^.

                    À part ça - le monde est plein à craquer de langages universitaires, par des universitaires, pour des universitaires. Qui sont dans leur tour d'ivoire, confortablement installés sur leur modèle théorique qui est d'une élégance qu'ils sont les seuls à pouvoir apprécier.

                    Et puis il y a ceux qui essaient de faire des choses utiles. Non pas que le formalisme soit inutile, ou qu'il n'influence pas l'évolution des langages de programmation (quoique comme le rappelle Bluestorm la plupart des 'nouveaux' langages ne sont que des anciens concepts réchauffés). C'est juste que pour réaliser quelque-chose de concrèt et d'utile, il faut maintenir un équilibre entre l'amateurisme et le formalisme.

                    En effet, vouloir révolutionner le domaine de la programmation - c'est bien, mais honnêtement je n'y crois plus trop. Même les langages les plus acclamés dernièrement au niveau conceptuel (Scala, Clojure..) me semblent en grande partie reprendre des concepts qui existent depuis une dizaine d'années.

                    Je fais partie de ces gens qui, sans cracher sur les diplômes, ont commencé à programmer par passion, et continuent à la faire pour la même raison. Je pourrais avoir le plus beau formalisme du monde, cela ne me rendrait pas aussi heureux que de voir des projets fleurir comme des frameworks web, des jeux vidéos, des bots irc, des IDEs, etc., etc. parce que j'ai fait des compromis pour être plus facile à interagir avec le C.

                    Pour qu'un langage ait du succès, il ne suffit pas d'avoir un doctorat en sémantique. Il faut avoir la patience de coordonner l'effort dans le bon sens jour après jour. Il faut prêter l'oreille aux rapports de bogue de la communauté entière, pas juste de ceux qui nous arrangent. Il faut savoir tirer le meilleur de chacun des contributeurs, et il faut savoir dire "bon, allez, on sort une version" de temps en temps.

                    J'espère que vous comprendrez mon point de vue. Si tel n'est pas le votre, bonne nouvelle, il existe des tas de langages fait précisément pour vous =) Le monde est vaste, je suis pour la diversité. Le plus important pour moi est d'en profiter. Le jour où je n'aurai plus aucun plaisir à travailler sur ooc, je mettrais la clé sous la porte.
                    • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                      Posté par . Évalué à 10.

                      Jusqu'à présent, tu disais plein de trucs intéressants, qui faisaient que je pertinentais à tout va, et puis là, boum, catastrophe :

                      « À part ça - le monde est plein à craquer de langages universitaires, par des universitaires, pour des universitaires. Qui sont dans leur tour d'ivoire, confortablement installés sur leur modèle théorique qui est d'une élégance qu'ils sont les seuls à pouvoir apprécier.

                      Et puis il y a ceux qui essaient de faire des choses utiles. »

                      Certes, juste derrière tu dis que « ah mais non, le formalisme c'est bien aussi hein » (oui bon, je simplifie), mais cette phrase, là, elle n'a pas lieu d'être. Parce que tu vois, LISP, OCaml, tous ces langages plus ou moins multi-paradigmes, plus ou moins fonctionnels, le lambda-calcul, toutes ces conneries inutiles inventées par des universitaires, tout le monde en bouffe plus ou moins tout le temps sans le voir. Genre Java, c'est rempli de machins pour la sûreté des types [1]) ; C# intègre de plus en plus de constructions directement empruntées aux langages fonctionnels; C++ veut intégrer les lambda-fonctions, etc.

                      Et tout le monde, à un moment donné (dans l'industrie, celle qui « fait des vrais choses » bien sûr) a qualifié ces langages de « pas utilisables par le commun des mortels », etc.

                      Parce que des langages faits « par et pour des universitaires », crois-moi, j'en ai connus quelques uns, mais -- oh surprise ! -- lesdits universitaires le savent. Dingue non ? En fait, très souvent, un universitaire crée un langage non pas parce que ça le fait kiffer à mort (il est spécialiste en langages, du coup fabriquer une grammaire et utiliser lex/yacc ou LISP ou OCaml pour fabriquer une nouvelle syntaxe, il sait faire sans trop se forcer).

                      Non, il fait ça pour donner une preuve de concept [2].

                      « C'est juste que pour réaliser quelque-chose de concret et d'utile, il faut maintenir un équilibre entre l'amateurisme et le formalisme. »

                      Le truc, c'est qu'à partir d'un certain moment, si le langage devait vraiment être intéressant, plaisant à utiliser, etc., bref, si une communauté un peu plus grosse devait s'intéresser à ton bébé, tu vas devoir finir par réellement formaliser ton langage. Des gens potentiellement intéressés pour aider à développer le langage, je suis persuadé que tu vas en trouver plein. Des gens intéressés et qui vont proposer des modifications pertinentes, tu vas peut-être en avoir qui se compte sur les doigts des deux mains. Mais il y a de fortes chances pour que ces derniers arrivent jusqu'à toi, ils aient besoin d'avoir des repères qui leurs parlent. Genre euh ... un langage commun qu'on appellerait ça. Oui, mais lequel utiliser ? Ah ben, si on utilisait la BNF ? Par exemple, hein. ;-) [3]

                      « Je fais partie de ces gens qui, sans cracher sur les diplômes, ont commencé à programmer par passion, et continuent à la faire pour la même raison. Je pourrais avoir le plus beau formalisme du monde, cela ne me rendrait pas aussi heureux que de voir des projets fleurir comme des frameworks web, des jeux vidéos, des bots irc, des IDEs, etc., etc. parce que j'ai fait des compromis pour être plus facile à interagir avec le C. »

                      Tu sais, quand tu finis par arriver au niveau de la thèse, t'as intérêt à un minimum aimer ce que tu fais (j'en connais pour qui ce n'est pas le cas, mais c'est quand même super rare). Et je mets la barre très haut pour le « minimum ». Donc t'inquiète, la passion est là. [4].

                      En temps normal je serais d'accord avec toi, « les diplôme on s'en fout » [4]. Quand il s'agit du design d'un nouveau langage, je vois deux cas de figures : l'amateur éclairé (dont tu fais partie), et le « pro » (souvent un de ces sales universitaires, ou un ingé de recherche avec très souvent un doctorat, hou la honte, encore un mec qui sert à rien [5]). L'amateur éclairé se décline là encore en deux catégories : celui qui a pas mal de bouteille concernant la prog, les concepts en informatique, etc., bref qui a lu des articles/des bouquins concernant l'info, qui se passionne, etc. Techniquement, je lui fais confiance pour comprendre les concepts, et savoir comment les appliquer dans un langage. Et y'a aussi l'inventeur de MultiDeskOS, le meilleur programme de tous les temps, qui fait le café, enfin promis, dès que le soft dépassera le stade pré-pré-alpha. Celui-là est très certainement aussi passionné, mais n'a pas forcément la culture informatique pour réellement arriver à quoi que ce soit. [6]

                      « Pour qu'un langage ait du succès, il ne suffit pas d'avoir un doctorat en sémantique. Il faut avoir la patience de coordonner l'effort dans le bon sens jour après jour. »
                      Non, pour qu'un langage ait du succès, il faut juste y mettre les moyens logistiques et financiers qui vont bien. Le langage D est très intéressant par exemple, mais on entend bien plus parler de C# ou Java (qui a mis le temps pour s'imposer, certes). Dans notre microcosme « libriste » (quel affreux mot), on est plus curieux quant aux nouveaux langages, mais 'achement moins nombreux que la masse laborieuse des informaticiens. Du coup, il faut réellement que le langage ait une valeur très ajoutée pour qu'il ait du succès hors de son petit monde du Libre. [7] Les exemples les plus flagrants sont certainement Perl (dans les années 90), PHP, Python, et dans une moindre mesure Ruby.

                      [1] Cf. le bouquin de Pierce: Types and Programming Languages par exemple.
                      [2] Hou que c'est moche la traduction mot-à-mot, personne n'aurait une proposition plus idiomatique ?
                      [3] Ou n'importe quel autre type de formalisme, mais un machin que les gens « du métier » comprennent. Et par métier, je veux simplement dire des gens qui trifouillent le domaine, de façon pro ou amateur.
                      [4] Soyons bien d'accord : je me fous des diplôme d'un programmeur 99% du temps. J'ai assez eu de boulets en binôme pendant mes études pour des projets info pour savoir que le diplôme n'indique absolument rien en ce qui concerne les compétences techniques d'une personne. Au contraire, je connais des gens qui ont pas loin de 10 ans de moins que moi, et qui sans aucun diplôme sont sans doute bien meilleurs développeurs que moi.
                      [5] Je suis en plein décalage horaire, et sur une autre planète, il est encore certainement vendredi.
                      [6] Concernant les universitaires, il y a aussi deux sortes : celui qui va savoir tout théoriser mais n'approchera jamais un clavier, sauf pour rédiger un article en latex -- et encore -- et celui qui sait aussi coder. Généralement, on se retrouve avec un directeur de recherches qui a su coder, mais délègue désormais cette tâche aux grouillots^Wthésards.
                      [7] Je ne porte aucun jugement sur ton langage, je ne le connais pas.
                      • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                        Posté par (page perso) . Évalué à 3.

                        « Jusqu'à présent, tu disais plein de trucs intéressants, qui faisaient que je pertinentais à tout va, et puis là, boum, catastrophe »

                        J'avoue, je fatigue - la politique c'est pas ma passion. Sincèrement désolé.

                        « toutes ces conneries inutiles inventées par des universitaires, tout le monde en bouffe »

                        20 ans après, oui. En quoi est-on en désaccord? Je me tiens au courant de la recherche autant que possible, les idées sont bonnes à prendre, mais effectivement je prie pour que les 'universitaires' qui savent coder pour de vrai (pas juste des LaTeX-eux) copulent, se multiplient - que dis-je, envahissent la terre.

                        « Ah ben, si on utilisait la BNF ? »

                        Pourquoi pas, mais ça représente un effort (donc un temps) non-négligeable, surtout en ayant déjà une grammaire PEG - tout aussi formelle, mais un peu plus moderne.

                        Le fait est que pour l'instant je considère qu'ooc est encore dans une phase ou je fais (tiens donc) de la recherche. Je cherche comment implémenter efficacement de l'analyse de fuite[1] afin de pouvoir optimiser les programmes sans que le programmeur doive choisir où allouer ses classes et tout gérer à la main (cf. C++), je cherche une solution permettant d'avoir des classes et des fonctions génériques sans avoir un surpoids significatif des binaires (cf. C++) sans pour autant sacrifier la performance (en permettant la spécialisation de types/fonctions génériques à l'exécution). Je cherche, comme tous les langages contemporains, une solution simple et puissante au problème de la concurrence.

                        Seulement, je préfère partager le peu qu'on a déjà réalisé. Ce qui nous permet d'avoir, par exemple, des réactions très intéressantes et très instructives (ce fil de discussion, par exemple), d'avoir des idées, de liens, des recommandations de voir comment tel ou tel autre langage le fait, de se référer au travail de Machin pour en savoir plus, etc. (C'est finalement à ça que ça sert, "Release early, release often")

                        Au-delà de faire les premières pages des sites de news, sortir une version ne me fait pas plaisir. C'est toujours une grande paire de claque, qui permet justement - après avoir encaissé le coup - de se remettre en piste avec une longue liste de bons tuyaux et de commentaires constructifs (dans la plupart des cas). Cela permet de rencontrer des gens, parler de là où ils travaillent, de leurs besoins et d'en quoi le langage les intéresse potentiellement et ce qui lui manque encore pour leur être vraiment utile.

                        Je n'ai ni les moyens, ni l'envie de promouvoir à grand coup de fric et de logistique un langage qui n'en vaut pas la peine. Je suis de tout coeur d'accord avec toi - « il faut réellement que le langage ait une valeur très ajoutée pour qu'il ait du succès hors de son petit monde du Libre. » C'est justement parce que l'exigence est si grande qu'il est si bénéfique de travailler dans ses conditions-là. De mériter sa place, ou d'être déchu. Au final, ce seront les mérites techniques du langage qui l'emporteront, ou pas. Telles sont les règles du jeu.

                        Toutefois, s'il n'y a pas de versions qui sortent, s'il n'y a pas d'annonces, s'il n'y a pas une certaine exposition au public du langage, je dirais même une certaine démocratisation, alors le langage n'a aucune chance d'un jour attirer un acteur ayant les moyens de financer son succès. C'est un mal nécessaire.

                        On nous reproche de tenter d'attirer les débutants sur notre page d'accueil (cf. commentaires sur reddit - « Don't explain to me that this is a for loop, etc. »), mais c'est justement eux qui pourront le plus souvent juger de la simplicité du langage. Un pro comme tu dis, n'aura aucune difficulté à se faire au système le plus complexe. Mais si même le plus naïf, le plus innocent des programmeurs débutants arrive à faire sens d'un programme sans connaître le langage auparavant alors nous aurons déjà atteint une partie de notre objectif concernant la syntaxe.

                        [1] Amen, mon frère - la traduction mot-à-mot c'est atroce. [http://en.wikipedia.org/wiki/Escape_analysis]
                        • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                          Posté par . Évalué à 5.

                          D'un autre côté le programmeur expérimenté, ou le pro des langages si tu prends la peine de sortir du troll pour le sortir éventuellement de son domaine de recherche spécifique, ce seront de très bon interlocuteurs sur les choix de design ou d'implémentation ...

                          Ils verront des trucs que le débutant ne verra pas : typiquement les débutants ont toujours tendance à être rebutés par les sytèmes de typage qui peuvent être très strict, quand un pro pourra te parler des algos d'inférences de types qui marchent bien pour vérifier les types sans que le programmeur ait à trop se fatiguer à déclarer la moindre variable triviale.

                          Pour les problèmes de concurrences aussi, j'imagine qu'il y a un état de l'art assez conséquent en recherche, et dans des langages industriels aussi, dans lesquels il y a des idées intéressantes pour que le programmeur débutant soit heureux, et qu'il te dise "waaah c'est trop cool ton truc" sans avoir conscience du travail et des écueils à éviter pour arriver au résultat ...
                          • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                            Posté par (page perso) . Évalué à 2.

                            Tout à fait. C'est pour ça que j'ai des discussions avec d'autres concepteurs de langage (le concepteur de Vala, d'Io, etc.) - Je me réjouis de discuter avec Martin Odersky (Scala) l'année prochaine, etc.

                            J'ai été invité au Emerging Language Camp [http://emerginglangs.com/] pour présenter mon travail sur ooc. Seul petit problème, c'est à Portland et je n'ai pas vraiment les moyens d'y aller. Je recommande à tous ceux qui sont intéressés par les nouveaux langages et qui ont les moyens d'y aller - c'est rempli de conférenciers passionnants =)

                            Il est utile d'avoir des débutants pour jauger de la simplicité du langage, mais ce n'est effectivement en aucun cas un feedback suffisant pour trouver la bonne voie.
                        • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                          Posté par . Évalué à 4.

                          Dans Lisaac, il y a eu des solutions pour les problèmes que tu évoques.

                          "Je cherche comment implémenter efficacement de l'analyse de fuite[1] afin de pouvoir optimiser les programmes sans que le programmeur doive choisir où allouer ses classes et tout gérer à la main (cf. C++)"

                          C'est n'est pas encore fini mais l'idée est de garder un GC en library et d'utiliser de la réflexivité.

                          , je cherche une solution permettant d'avoir des classes et des fonctions génériques sans avoir un surpoids significatif des binaires (cf. C++) sans pour autant sacrifier la performance (en permettant la spécialisation de types/fonctions génériques à l'exécution).

                          Si tu spécifies à l'exécution tu tombes dans le cas des compilateurs just in time. Cela peut être très puissant pour des codes répétitifs qui sont simplifiables, un peu comme si on finissait une constante propagation, une partie des constantes étant la configuration du logiciel. Par contre, un JIT est loin d'être léger.

                          Je cherche, comme tous les langages contemporains, une solution simple et puissante au problème de la concurrence.

                          Lisaac propose COP mais cela n'est pas encore complètement mature.

                          Est-ce que tu pourrait nous dire pourquoi tu as essayé de créer ton propre langage au lieu de te créer le tien ?

                          Contrairement aux autres commentaires, je trouve qu'il est très complexe d'attirer quelques personnes de plus qui connaissent bien les compilateurs pour faire avancer un projet qui n'est pas le leur.

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

                          • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                            Posté par . Évalué à 4.

                            « Contrairement aux autres commentaires, je trouve qu'il est très complexe d'attirer quelques personnes de plus qui connaissent bien les compilateurs pour faire avancer un projet qui n'est pas le leur. »

                            Je suis tout à fait d'accord. Le domaine de la compilation est l'un des domaines les plus complexes de l'informatique, entre autres parce qu'il mélange aspects très théoriques (théorie des langage, sûreté des types, transformations de programme, etc.) et très pratiques (génération de code).
                            • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                              Posté par . Évalué à 2.

                              J'aimerais ajouter que c'est très dommage. La structure même de l'Inria ne pousse pas les chercheurs à bosser ensemble. Si j'ai bien compris, c'est une histoire d'équipe et de budget. Si 2 équipes bossent ensemble, cela serait vu comme une seul et ils perdent du budget.

                              Je trouvais dingue de parler de Cduce à une autre équipe Inria, que les équipes qui font des compilos ne se connaissent pas forcément.

                              Y'a personne à l'inria, pour faire une messe annuelle "compilation", au sens large uniquement pour que les équipes présentes leur travaux ?

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

                              • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                                Posté par . Évalué à 5.

                                Ben en fait, en ce qui me concerne, la grand messe de la compil a lieu tous les ans au workshop LCPC. Cette année y'avait un tutoriel sur l'allocation de registres en utilisant SSA.

                                Maintenant, je veux bien qu'un mec de l'INRIA réponde s'il connaît la réponse (j'en fais pas partie, donc je sais pas...).

                                Pour ce qui est de CDuce, autant j'aime beaucoup les concepts qui se trouvent derrière (sous-typage sémantique, tout ça), autant la syntaxe est franchement imbitable à mon sens. Je pense que c'est à ce genre de langages que pensent les gens qui parlent de « langages faits par et pour des universitaires ».

                                (Marwan, si tu me lis, me tape pas)
                                • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                                  Posté par . Évalué à 2.

                                  J'ai aussi du mal à voir l'intérêt d'un langage pour manipuler du xml. Par contre, le système de sous-typage qui correspond (vaguement) au ensemble mathématique, j'aime beaucoup.

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

                                  • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                                    Posté par . Évalué à 3.

                                    Pourquoi « vaguement » ? C'est quand même tout l'intérêt de l'article initial (« Semantic Subtyping ») : prouver qu'en théorie des types, l'intuition qui veut qu'un sous-type fait partie du plus grand ensemble de type dont il dérive est vrai. La démo n'utilise que des opérateurs logiques, fait très très mal à la tête, mais est parfaitement juste.

                                    Pour XML, je pense qu'il faut considérer deux choses.
                                    1/ L'équipe qui a réalisé CDuce, c'est celle des bases de données à Orsay. Ça fait un moment que les chercheurs en BDD s'amusent plus avec les bases orientées XML que les classiques BDD relationnelles.
                                    2/ Justement, XML, ce n'est finalement qu'un ensemble d'arbres (ou parfois de graphes) orientés et ordonnés dont chaque noeud représente un type. Ça permet (proof of concept, tout ça) de générer tout un tas de « types intermédiaires » depuis CDuce, chose qu'il n'est pas possible de faire directement avec OCaml (car il faudrait établir le produit cartésien de tous les types pour pouvoir les faire interagir entre eux).
                                    • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                                      Posté par . Évalué à 2.

                                      J'ai mis vaguement car je ne suis pas matheux et je m'attendais un "non pas du tout, c'est différent" d'une personne pointilleuse. C'était uniquement le sentiment qui j'avais en lisant les docs de vulgarisation sur cduce.

                                      Ce qui me gène c'est que l'équipe ne semble pas collaborer avec une autre pour intégrer ce système de typage ailleurs.

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

                                  • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

                                    Posté par (page perso) . Évalué à 3.

                                    >> J'ai aussi du mal à voir l'intérêt d'un langage pour manipuler du xml.

                                    Peut-être parce que ce qui se fait déjà est soit nul, soit largement améliorable ?
                                    Tu sais que ta phrase implique aussi que tu ne vois pas l'intérêt d'XPath, XSLT, XQuery, et bien des choses somme toute très utilisées ?

                                    (Enfin, pour ma part, j'ai du mal à voir l'intérêt d'XML…)
      • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

        Posté par . Évalué à 6.

        Effectivement l'inférence est limitée, puisqu'on interagit avec le C et que, d'autre part, on aime bien profiter d'une certaine sûreté (type checking).

        Peux-tu expliquer la deuxième partie de cette phrase ? Je ne comprends pas le lien entre inférence de type et une éventuelle absence de sûreté liée à la vérification des types.
    • [^] # Re: Un langage amateur sympa, mais qui se prend trop au sérieux

      Posté par (page perso) . Évalué à 2.

      Ah, et au passage: oui, nos closures sont des vraies closures. Qui capturent le contexte. Pas juste des fonctions anonymes.
  • # Langage auto-hébergé

    Posté par (page perso) . Évalué à 1.

    Ca m'épate toujours ce principe des langage auto-hébergés. J'aimerai bien comprendre comment ca se décline en pratique.

    J'imagine que tu compile le compilateur ou un sous-ensemble du compilateur avec gcc. Ca veut donc dire que tu maintiens un sous-ensemble du compilateur compilable en C. Ensuite, tu as ton compilateur, et hop, tu recompile la dernière version du compilateur ?

    En tout cas, ça veut bien dire que le compilateur principal soit ne peut pas tirer partie des dernières fonctionnalités du langage, soit possède deux modes, un mode ou est il compilable avec une version précédente ou une version de bootstrap, et un mode ou il se compile lui-même ?

    C'est pas contraignant de maintenir ce double-mode ?
    • [^] # Re: Langage auto-hébergé

      Posté par (page perso) . Évalué à 2.

      Non en général, tu écris ton compilateur avec les limites de la version précédente (celle avec laquelle tu compiles). Ensuite, tu dois compiler ton compilateur (1), recompiler ton compilateur avec(2), et pour être complet, recompiler ton compilateur avec le (2).
      Parce le (2) est compilé avec un compilateur compilé d'un version précédente, donc tu n'es pas indépendant :-)

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

      • [^] # Re: Langage auto-hébergé

        Posté par (page perso) . Évalué à 3.

        Si on veut. A cela prêt que pour les langages source-à-source (ooc, Vala, etc.) on peut conserver la version source du compilateur (2) et donc être vraiment indépendant du (1) à partir d'un certain moment.

        En l'occurence, rock est distribué au format source C que lui-même a produit. Quand un utilisateur l'installe, il fait appel au Makefile qui compile les sources C avec gcc, ce qui produit un premier binaire rock, qui est utilisé pour recompiler à partir des sources ooc (assez similaire à ce que tu décris, mais avec une petite nuance quand même).
  • # While.... mais pas de Do.... While

    Posté par . Évalué à 1.

    je ne vois pas de structure :

    Do .... While....

    Comment fait-on pour contourner ce problème ?

Suivre le flux des commentaires

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