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
- Le site officiel de Ruby (26 clics)
- Annonce de la version 1.9.2 (2 clics)
- Ruby 1.9 - the future of Ruby? (4 clics)
- RVM - Ruby Version Manager (5 clics)
- RubySpec (1 clic)
- Is it Ruby 1.9? (1 clic)
# Petite correction grammaticale
Posté par Davy Defaud . Évalué à 2.
utilisées
[^] # Re: Petite correction grammaticale
Posté par rogo . Évalué à 5.
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 Maclag . Évalué à 5.
É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!)
[^] # Re: Petite correction grammaticale
Posté par BAud (site web personnel) . Évalué à 5.
l'apéro ? parce que bon là, ça va être l'heure, il se fait presque midi ;-)
[^] # Re: Petite correction grammaticale
Posté par gUI (Mastodon) . Évalué à 3.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Petite correction grammaticale
Posté par Bob . Évalué à 0.
et pas des pieds !
# Quels progrès de stabilité ?
Posté par rogo . Évalué à 4.
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 Bruno Michel (site web personnel) . Évalué à 2.
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 Thomas J. (site web personnel) . Évalué à 4.
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 Thomas J. (site web personnel) . Évalué à 2.
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 Bruno Michel (site web personnel) . Évalué à 5.
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 Bob . Évalué à 1.
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 governator . Évalué à 4.
# Syntaxe du language
Posté par Damien Thébault . Évalué à 7.
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 Alex . Évalué à 3.
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 jbbourgoin (site web personnel) . Évalué à 6.
«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 Antoine . Évalué à 3.
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 jbbourgoin (site web personnel) . Évalué à 1.
Des preuves ?
Aucune.
Au suivant !
[^] # Re: Syntaxe du language
Posté par Frank-N-Furter . Évalué à 1.
Depending on the time of day, the French go either way.
[^] # Re: Syntaxe du language
Posté par fred (site web personnel) . Évalué à 1.
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 Bruno Michel (site web personnel) . Évalué à 3.
*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 Bruno Michel (site web personnel) . Évalué à 2.
En fait, les réponses étaient à portée de main :
- presque 100 contributeurs pour PyPy (source : http://codespeak.net/pypy/dist/pypy/doc/contributor.html )
- environ 500 contributeurs pour Django (source : http://code.djangoproject.com/browser/django/trunk/AUTHORS )
Cela confirme que Ruby n'a pas de problème particulier vis à vis de Python pour fédérer le plus grand nombre autour de grands projets.
[^] # Re: Syntaxe du language
Posté par jbbourgoin (site web personnel) . Évalué à 4.
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 jbbourgoin (site web personnel) . Évalué à 1.
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.