Sortie de Ruby 1.9.2

Posté par  (site web personnel) . Modéré par tuiu pol.
Étiquettes :
22
19
août
2010
Ruby
Yuki Sonoda (Yugui) a annoncé la sortie officielle de Ruby 1.9.2. Bien que le numéro de version n'en montre rien, cette version est très importante et pourrait marquer le passage de Ruby 1.8 à Ruby 1.9.

Rappelons que Ruby est un langage de programmation orienté objets, à typage dynamique et qui s'est inspiré de Lisp, Perl, Smalltalk, Eiffel, etc. Sa principale caractéristique est de mettre en avant les besoins humains avant ceux informatiques, et notamment le fun et la productivité.

Jusqu'à Ruby 1.8, l'interpréteur était écrit par Yukihiro Matsumoto (Matz), le concepteur du langage. Koichi Sasada (ko1n) a commencé une réécriture complète pour apporter les dernières avancées techniques à Ruby. Le projet a commencé sous le nom de code YARV, puis Matz en fait la version officielle de Ruby à partir de Ruby 1.9.

Le premier avantage de Ruby 1.9 est ses performances. Ruby était réputé pour n'être pas très rapide, mais les avancées de Ruby 1.9, et notamment le ramasse-miettes, lui permette d'être de 3 à 5 fois plus rapide que Ruby 1.8. Parmi les autres avancées importantes de Ruby 1.9, nous pouvons citer la gestion des encodages, de nouvelles fonctionnalités comme les fibres ou encore des améliorations de la syntaxe (en particulier, celles des Hashs).

Les versions 1.9.0 et 1.9.1 manquaient de stabilité. La communauté Ruby les a considérées comme des versions de développement et rares sont les développeurs à les avoir utilisées en production. La version 1.9.2 devrait changer la donne : cette version est bien plus solide et on devrait assister à une migration massive vers Ruby 1.9. Si jamais ce n'était pas le cas, les implémentations alternatives comme Rubinius ou JRuby pourraient fort bien attirer les foules et devenir prédominantes.

Pour installer Ruby 1.9.2, vous pouvez télécharger les sources sur http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p0.tar.bz2 ou, pour les utilisateurs de RVM :
rvm update --head && rvm reload && rvm install 1.9.2 && rvm 1.9.2

Aller plus loin

  • # Petite correction grammaticale

    Posté par  . Évalué à 2.

    La communauté Ruby les a considérées comme des versions de développement et peu sont les développeurs à les avoir utilisés

    utilisées
    • [^] # Re: Petite correction grammaticale

      Posté par  . Évalué à 5.

      celle_ des Hashs (la syntaxe)

      rares sont les développeurs à les avoir utilisées.
      Ou "peu nombreux sont...", mais c'est plus lourd, et ça sent un peu la traduction du "few" anglais.

      Puisqu'on est dans les détails, c'est étonnant de constater la quasi disparition du mot "progrès", au profit du néologisme "avancée" : « apporter les dernières avancées techniques à Ruby ».
      Ce sens de "avancée" ne figure même pas dans mon Petit Robert de 1996, bien qu'il soit apparu dans le vocabulaire journalistique depuis quelques décennies.
      • [^] # Re: Petite correction grammaticale

        Posté par  . Évalué à 5.

        [Mode comptoir]
        Évaluons une liste de possibilités concernant le remplacement de "progrès" par "avancée":

        - Évolution technique bénéfique du point de vue du concepteur/fabriquant mais invisible aux yeux de l'utilisateur. Il faut donc du marketing "poudre aux yeux" pour faire passer la pilule à la fin ("C'est une grande avancée technique qui ne te sert à rien mais avec ça on a bien augmenté nos marges et tu peux te la péter à mort". Exemple: la mode du pseudo-nMOS dans les chaines Hi-Fi il y a un bail)

        - Le mot "progrès" est devenu un peu obsolète car sur-utilisé depuis quelques décennies. Il ne fait plus rêver. On va donc établir une hiérarchie entre les évolutions: une avancée, c'est un truc plus mieux qu'un progrès.

        - En lien avec les deux précédents: le monde moderne est marqué par "les progrès techniques", mais la vie de tous les jours n'est pas ressentie comme meilleure (mondialisation, chômage, etc.). Une association négative s'est finalement établie dans la tête du peuple et on évite ce mot.

        - Le mot "progrès" est aussi très utilisé dans l'évaluation des performances personnelles: à l'école, en entreprise, etc. "Il fait beaucoup de progrès". Il va être associé à des pensées sur la pression et le paternalisme. Il génère donc des ondes négatives dans le subconscient.
        [/Mode comptoir]

        Bon, j'arrête la bibine et je reprends une activité normale (hips!)
  • # Quels progrès de stabilité ?

    Posté par  . Évalué à 4.

    Pour en revenir au fond, j'ai cherché à savoir dans quelle mesure la stabilité de Ruby 1.9 avait progressé. Le fichier "NEWS" n'en parle pas (ou alors j'ai raté le passage à ce sujet). Le changelog ne fait pas référence à un bugtracker ou à des tests unitaires, donc rien d'évaluable de ce côté là. Sans vouloir dénigrer le message initial, je suis un peu dubitatif (j'ai toujours du mal à croire sur parole).

    Pour la performance, on peut regarder les benchmarks de Debian (avec toutes les restrictions d'usage sur le sens de ces mesures) :
    http://shootout.alioth.debian.org/u32/benchmark.php?test=all(...) (à ce jour, Ruby 1.9.2 / Ruby 1.8.7)

    A titre perso, le langage Ruby me plaît globalement. En dehors de quelques détails, mes principales critiques allaient à la documentation officielle (peu d'exemples, description parfois incomplète, pas de références SeeAlso, "ri" n'est pas terrible, etc.) et à l'API standard (fileutils et Cie déclenchent des tonnes d'avertissements en mode debug, REXML est pénible, l'abstraction d'accès SQL est instable et mal documentée, etc.). Mais, comparés à la recherche de performance, ce ne sont pas des sujets très motivants pour les développeurs de Ruby (j'aime pas non plus écrire de la doc).
    • [^] # Re: Quels progrès de stabilité ?

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

      De gros progrès ont été faits entre Ruby 1.9.1 et Ruby 1.9.2 en termes de stabilité, mais ce n'est pas évident de chiffrer ça.

      Pour les tests unitaires, Ruby 1.9 s'appuie notamment sur la suite de tests RubySpec. 99% de ces specs passent. Le dernier pourcent ne vient pas forcément de problème de stabilité, mais plus de cas particuliers qui sont sujets à discussions.
  • # Rubinius, JRuby et les autres alternatives

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

    Concernant Rubinius, il est vrai que Matz s'intéresse de prêt à cette VM développée autour de LLVM. Malgré tout, il reste un problème de taille : alors qu'il y a pléthore de plateformes supportant la version 1.9.2 (Linux, Windows, MacOS X, FreeBSD, Solaris 10, Symbian OS, ...), Rubinius reste utilisable uniquement sur 2 plateformes (Linux et MacOS X). Je pense qu'il s'agit là du frein principal à ce projet très intéressant.

    Pour JRuby, j'aurais tendance à dire que c'est l'inverse : là où la JVM fonctionne (c'est-à-dire presque partout) JRuby est censé fonctionner. Le gros hic reste sa consommation excessive de mémoire ([http://programmingzen.com/2010/07/19/the-great-ruby-shootout(...)] - 2ème graphique).

    Mais n'oublions pas qu'il y a d'autres VM alternatives : IronRuby, MagLev et Cardinal (REE restant à part). Les deux premières ne sont pas intéressantes car elles dépendent de la plateforme .Net de Microsoft ou sont sous licence prioritaire.
    Cardinal utilise la VM Parrot mais son parseur est tellement lent qu'il n'est pas raisonnablement utilisable. Dommage, car l'idée était intéressante, mais peut être cela va-t-il changer ?

    Bref, comme on peut le voir il y a beaucoup d'alternative mais peu semblent pouvoir détrôner la VM originale.
    D'où ma question : étant donné les gains importants en terme de performance, pourquoi les Rubyists ne migrent-ils pas (ou si peu) en version 1.9 ?
    • [^] # Re: Rubinius, JRuby et les autres alternatives

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

      Oups !
      Ma question est mal posée, je la repose donc :
      D'où ma question : étant donné les gains importants en terme de performance, pourquoi les Rubyists ne migraient-ils pas en version 1.9 ?
      • [^] # Re: Rubinius, JRuby et les autres alternatives

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

        Les développeurs restaient avec Ruby 1.8 principalement parce que c'était compliqué de migrer vers Ruby 1.9. Ruby 1.9.1 avait tendance à segfaulter un peu trop régulièrement, beaucoup de bibliothèques n'étaient pas compatibles avec Ruby 1.9, faire tourner Ruby on Rails avec Ruby 1.9 était un défi de tous les jours. En plus, il n'était pas forcément facile de faire cohabiter Ruby 1.8 et Ruby 1.9 (il faut éviter de mélanger les gems par exemple).

        Mais c'est en train de changer. La version 1.9.2 est nettement plus stable que la 1.9.1. Rails, et tout particulièrement Rails3 qui devrait sortir bientôt, supporte de mieux en mieux Ruby 1.9.

        L'arrivée de Ruby Version Manager fait également beaucoup de bien. Il est maintenant très facile d'avoir plusieurs implémentations de Ruby sur une même machine et de passer de l'une à l'autre selon les projets. RVM permet de lancer facilement les tests unitaires d'une bibliothèque avec plusieurs versions de Ruby. C'est, je pense, ce qui a permis à beaucoup de développeurs d'avoir des bibliothèques Ruby qui fonctionnent avec les différentes versions.
        • [^] # Re: Rubinius, JRuby et les autres alternatives

          Posté par  . Évalué à 1.

          En gros tu dis que depuis la sortie de RVM, ça va mieux. Perso, je pense que c'est l'inverse : les gens ont décidés que ça devait aller mieux, alors ils ont sorti RVM.

          C'est la force de la communauté Ruby à mon sens : la vision agile du développement qui fait qu'on fait tout pour avancer (GTD).
    • [^] # Re: Rubinius, JRuby et les autres alternatives

      Posté par  . Évalué à 4.

      A noter que si Microsoft a décider de passer IronRuby et IronPython sous licence Apache http://www.zdnet.com/blog/microsoft/microsoft-puts-ironpytho(...) , la nouvelle ressemble à un abandon du projet puisqu'il ne reste plus qu'un seul développeur après le départ de Jimmy Schementi de Microsoft http://blog.jimmy.schementi.com/2010/08/start-spreading-news(...)
  • # Syntaxe du language

    Posté par  . Évalué à 7.

    Ruby c'est cool, y'a des concepts puissants et tout.

    Mais au final ça fait un peu penser à du Perl, y'a souvent plusieurs manières de faire la même chose.

    Déjà les appels de méthodes qui peuvent être avec ou sans parenthèses je trouve ça très pénible.
    Et aussi, à chaque fois que je me cherche la signification des accolades en ruby j'ai un peu peur, surtout l'histoire des block avec les paramètre entre pipes et tout, je trouve pas ça très intuitif.
    Ajoutons à ça le fait de pouvoir mettre les "if" et "unless" à la fin de chaque ligne...


    Par exemple, dans la doc ruby:
    http://ruby-doc.org/docs/ProgrammingRuby/html/tut_containers(...)
    Perso juste avant d'arriver à la partie "Implementing Iterators", ça commence à être pas très clair, et la fin est juste horrible.
    (et pourtant c'est juste le 3ème chapitre du tutorial, mais j'avoue que y'a pratiquement au minimum une chose qui me gène dans chaque chapitre ^^).

    Par contre y'a des choses que je trouve bien quand même, les regex c'est pratique à avoir dans le language, j'aime bien les setters, ainsi que la possibilité de mettre des "?" à la fin des noms de méthode pour montrer que c'est un test.

    (je reste un peu mitigé sur les string avec "#{...}", y'a pas d'équivalent en python3, mais ça oblige peut-être les gens à bien utiliser le ".format" du coup)
    • [^] # Re: Syntaxe du language

      Posté par  . Évalué à 3.

      c'est vrai que les quelques ressemblances à perl m'ont parfois fait peur, et j'éspère qu'ils ne vont pas trop pousser dans ce sens par la suite (pas spécialement le fait d'avoir plusieurs manières de faire une même chose, ce que je n'aime pas c'est tout ce qui est trop implicite)

      Par contre je ne comprends pas trop ta critique sur les itérateurs, perso je trouve ça plutôt élégant, assez proche du smalltalk, et bien plus propre que ce qu'on trouve en C++ ou java.
      La chose à savoir c'est que yield exécute le bloc de code donné en paramètre, la seule chose un peu mal foutue dans ce tutorial (qui doit dater un peu), c'est que le bloc n'est pas explicitement indiqué dans la déclaration des méthodes
    • [^] # Re: Syntaxe du language

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

      Ceci :

      «C'est cool (...) mais au final ça fait un peu penser à du Perl, y'a souvent plusieurs manières de faire la même chose.»

      et cela :

      «y'a pas d'équivalent en python3, mais ça oblige peut-être les gens à»

      Le résumé parfait de ce distingue Perl de Python.

      Perl dit : nous vous offrons une grammaire large et vivante (qui peut grandir) afin que vous vous exprimiez comme bon vous semble.

      Python dit : il y a une manière de parler, et c'est celle de GvR.

      Perl c'est cette joyeuse cacophonie que l'on rencontre dans le monde des hommes : on y croise des Aristophane, des Pascal, des Thomas d'Aquin, des Ibn Khaldun, des Paul Claudel, des Rabelais etc.

      Python c'est... je ne sais pas, un monde humain qui ne connaîtrait que l'esperanto ? La tour de Babel en somme, la construction humaine faite par ce peuple ne parlant qu'une seule langue qui croyait pouvoir dépasser Dieu.

      Heureusement, Dieu a multiplié les langues ;)

      Et heureusement, Python n'est pas seul, il existe avec C, Perl, Java, BASIC etc. ;)
      • [^] # Re: Syntaxe du language

        Posté par  . Évalué à 3.

        Heureusement, Dieu a multiplié les langues ;)

        En même temps, dans la vraie vie, Dieu est mort et Perl ne se sent pas très bien non plus...
      • [^] # Re: Syntaxe du language

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

        Je ne comprends pas pourquoi vous invoquez la religion et adoptez ce ton pompeux, si ce n'est pour éluder l'argument qui ne vous plait pas (ou alors pour faire de l'humour auquel cas je n'ai pas compris).

        On a l'impression que vous travestissez une vilaine réalité comme dans une publicité télévisée pour un gros lobby nucléaire, et que vous éludez l'argument.

        Perso, passé l'enthousiasme initial ça m'a toujours dérangé que Ruby soit l'oeuvre d'une personne mégalo, qui gère la chose en dictateur intraitable, Y. Matsumoto.

        A comparer avec Python dont la syntaxe est, depuis bien longtemps, un projet collectif issu d'un travail collaboratif, avec un processus d'évolution inspiré des RFCs, les PEPs.

        De plus ce qui m'a toujours rebuté avec PERL et Ruby c'est qu'il y a souvent plusieurs façons de faire la même chose.

        Est-ce que cela favorise la compréhension par tous ? Est-ce que cela est à même de fédérer le plus grand nombre autour de grands projets ?

        La diversité ne devrait peut-être pas se trouver au sein du langage mais plutôt dans ce qui en est fait : librairies, applications, projets, ... , non ?
        • [^] # Re: Syntaxe du language

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

          > Perso, passé l'enthousiasme initial ça m'a toujours dérangé que Ruby soit l'oeuvre d'une personne mégalo, qui gère la chose en dictateur intraitable, Y. Matsumoto.

          *Cough*, Matz, une perso mégalo ?!??

          Pour l'avoir rencontré lors de Solutions Linux en 2009, je peux t'assurer que Matz est tout sauf mégalo. C'est quelqu'un d'extrêmement poli (c'en est même devenu un motto sur des mailing-lists Ruby : Matz is nice, so we are nice), qui met les autres en avant et qui n'hésite pas à dire qu'il a fait des choix regrettables pour Ruby (reprendre toutes les variables $ + un signe de ponctuation de Perl, par exemple). Bref, on peut reprocher des choses à Matz, mais sûrement pas d'être mégalo (pour ça, vaut mieux aller voir du coté de DHH).

          > De plus ce qui m'a toujours rebuté avec PERL et Ruby c'est qu'il y a souvent plusieurs façons de faire la même chose.

          C'est aussi le cas en Python, mais si les pythonistes diront le contraire. Par exemple, les list comprehensions peuvent très bien s'écrire avec filter() et map().

          > Est-ce que cela favorise la compréhension par tous ?

          Oui, probablement pour Ruby. Cela permet d'écrire du code de manière courte en choisissant la forme la plus compréhensible.

          > Est-ce que cela est à même de fédérer le plus grand nombre autour de grands projets ?

          En tout cas, ça n'a pas l'air d'être un point gênant. J'en veux pour preuve les 1600 contributeurs de Rails (source : http://contributors.rubyonrails.org/ ) ou les 150 contributeurs de Rubinius (source : http://github.com/evanphx/rubinius/contributors ).

          Je serais curieux de connaître le nombre de personnes qui ont contribué à Django ou à PyPy (les équivalents de Rails et Rubinius dans le monde Python).
        • [^] # Re: Syntaxe du language

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

          «Je ne comprends pas pourquoi vous invoquez la religion et adoptez ce ton pompeux, si ce n'est pour éluder l'argument qui ne vous plait pas (ou alors pour faire de l'humour auquel cas je n'ai pas compris).»

          il ne s'agissait que d'un simple amusement, de l'humour si vous préférez. Mon message n'avait rien d'aussi sérieux, il ne s'agit que de programmation après tout.

          Si vous ne l'avez pas compris j'en suis l'unique responsable, mes propos n'étais pas assez clairs.

          Bien à vous.
        • [^] # Re: Syntaxe du language

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

          «Est-ce que cela favorise la compréhension par tous ? Est-ce que cela est à même de fédérer le plus grand nombre autour de grands projets ?»

          le cpan est la preuve du contraire.

          «La diversité ne devrait peut-être pas se trouver au sein du langage mais plutôt dans ce qui en est fait : librairies, applications, projets, ... , non ?»

          elle se trouve dans les deux car il s'agit d'œuvres humaines. Diversité des langages, diversité des projets, diversité des manières de faire, diversité des syntaxes, grammaires baroques ou réduites à l'essentiel etc.

Suivre le flux des commentaires

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