8 raisons d’aimer Ruby
Ruby est un langage qui évolue vite, qui monte fortement et qui est utilisé pour faire de vraies choses (même en prod !). Cet article contient 8 points qui font de Ruby un très bon langage et une plateforme de choix pour réaliser ses futurs projets.
Plus productif
Martin Fowler a fait une synthèse de l’utilisation de Ruby chez ThoughtWorks.
La conclusion est une impression très forte d’une meilleure productivité. La majorité des projets ont ressenti un doublement de leur productivité (une impression car la productivité n’est pas mesurable).
Je vous encourage à lire l’article sur le site de Martin Fowler : “Ruby at ThoughtWorks”
Meta-Programming
Le meta-programming c’est la génération de code par le code. Cela permet par exemple d’écrire des DSL et de simplifier son code. C’est aussi une arme puissante à utiliser modérément.
L’équivalent de la génération d’une méthode au Runtime en Java donnerait :
void genereUneMethode() {
/* cette méthode sera ajouté à la classe appelante */
void nouvelleMethode() {
// Les commentaires de Chuck Norris sont compilés
}
}
Duck Typing
Le static typing s’oppose au duck typing. En Ruby, il n’y a pas de notion de type vérifié à la compilation.
Cela veut dire, qu’il est possible d’appeler une méthode avec un Array à la place d’une String. Tant que l’autre objet répond aux méthodes de l’objet attendu, le code est valide.
Le Duck Typing permet d’avoir du code beaucoup plus souple. La forte orientation vers les tests de Ruby en est la conséquence.
Il y a eu beaucoup de débats sur au sujet de « Static typing » contre « Duck typing ». Les auteurs de « Programming Ruby 1.9 » expliquent que le typage statique ne rend pas forcément un code plus fiable et peut diminuer la productivité. (Non, pas de Troll)
Plus d’info sur le duck typing sur Wikipedia.
Closures
Les Closures ont fortement animé les débats autour de leur inclusion (ou pas) dans Java.
Elles font partie de la syntaxe de base de Ruby.
Les Closures sont des méthodes dont l’exécution peut être retardée tout en retenant le contexte quand elles ont été créées. Elles ont plein d’usages mais ne sont pas pourtant pas évidentes à appréhender.
JRuby
JRuby est une implémentation de Ruby pour la JVM. Avantages : un super garbage collector (merci Java), des threads efficaces, multi-plateformes… Il fait tourner des projets Rails sans problème.
L’avantage est également de pouvoir faire du Ruby sur nos serveurs d’app Java, comme Glassfish 3 qui supporte JRuby.
Frameworks novateurs
Rails, Capistrano ou encore Cucumber sont les fers de lance de Ruby et montrent ce que le langage permet de construire.
- Rails : c’est le Framework Web qui a donné de la visibilité à Ruby. Rails permet de produire des sites Web très rapidement et de manière simple
- Capistrano simplifie fortement le déploiement de projets Ruby et permet par exemple de se brancher sur un SVN pour faire de la mise en production en continue
- Cucumber est un framework de BDD simple à prendre en main. Le Meta-Programming apporte beaucoup aux frameworks de tests en permettant l’écriture de DSL de tests
GEM : le packaging facile
Les GEM sont des archives de projet Ruby. Un peu comme nos JAR/WAR/EAR mais en mieux. Une Gem permet de packager son code, ses tests et ses scripts selon un format normé.
On installe une Gem en ligne de commande, idem pour la mettre à jour ou en rechercher d’autres.
Il est également très simple de pousser une Gem sur les repos (voir par exemple l’impressionnant de simplicité Gemcutter)
Une communauté riche (et aussi en France)
Ruby bouge beaucoup et sa communauté est importante. Comme avec Java, il y a des sites de news, des podcasts, des screencasts…
- Des news : RubyInside, About Ruby
- Des podcasts : RailsEnvy
- Des screencasts : Learnivore
- Des challenges de programmation : RubyLearning
Les Apéros Ruby ressemblent à nos JUGs. Le prochain a lieu ce jeudi 12. Ils sont moins cadrés que les JUGs mais tout aussi intéressants : Coding Dojo, Lightning talk…
Conclusion
Ruby dispose de nombreux atouts pour plaire, même face à ses concurrents dynamiques ou statiques (Scala par exemple).
Une des principales qualités de Ruby est sa communauté vivante et innovante. Découvrir une plateforme comme Ruby donne un nouvel élan et permet de faire fonctionner ses neurones sur d’autres paradigmes.
J’ai choisi Ruby pour toutes ces bonnes raisons et il y en a encore bien d’autres à découvrir.
November 11th, 2009 at 22:51
Salut Thomas,
Toi qui viens du monde Java, pourquoi t’est tu orienté vers Ruby plutôt que des langages plus proches comme Groovy? Tous les arguments que tu cites dans ton articles son valable pour Groovy également.
J’ai eu en gros les même envies de changement que toi mais j’ai préféré partir sur un langage plus proche syntaxiquement (plutôt par flemme au début).
November 12th, 2009 at 14:28
Salut Nathaniel,
J’ai envisagé Groovy, Scala et Ruby avant de me décider.
Comme conclusion, le critère “Hors de la JVM” a été un aspect important.
Mon raisonnement est que se concentrer uniquement sur l’écosystème Java rétrécit notre vision des choses.
Par exemple, j’ai l’impression que un framework comme Rails n’aurait pas pu sortir en premier sur Groovy.
Je me suis rendu compte de certaines divergences de pensées lors du TDW camp (travailleurs du Web) où j’ai côtoyé pas mal de monde qui faisait du Php et qui n’ont pas du tout les mêmes problèmes de complexité à résoudre pour répondre à un même besoin en java.
Pour revenir à Ruby, j’ai pris mon courage à deux mains pour m’y mettre. Mais c’est très consommateur de réapprendre tout un environnement (quels sont les frameworks, les API, les projets, les gens…).
Pour résumer mon propos : j’ai choisi Ruby presque pour ses conditions externes que pour le langage lui-même. Le sentiment de liberté est fort dans le monde Ruby. Un peu comme le “Fork Me!” de GitHub.
Tom
November 12th, 2009 at 14:50
Salut, pour info j’ai suivi le même parcours que Tom il y a déjà 2 ans. En fait dès que j’ai eu besoin de faire du code pour moi et pas pour un employeur/client qui m’aurait imposé tel ou tel archaisme pour plonger avec lui plus tard.
Comme Tom, j’ai jamais considéré Groovy comme crédible face à Ruby, en terme de language, même s’il ma intéressé aussi avant que JRuby existe. En plus, je en compte pas comme vous, je considère qu’aprendre des choses comme un langage ouvre l’esprit et rend in fine plus productif. J’ai aussi super appris le Python par la suite (pour OpenERP) et pas de regret non plus même si je condière Jruby supérieur.
JRuby a été un facteur très important vu que j’aimais quand même relativement Java (surtout après le C/C++). J’ai donc commencé à utiliser JRuby dès la fin 2006, aujourd’hui c’est la meilleure implémentation de Ruby…
J’ajoute que la tronche qui a donné ses lettres de noblesses à JRuby, Nutter, est en ce moment en train de perfectionner 2 dérivés de JRuby qui à mon sens font perdre toute valeur à Scala. Il s’agit de Duby et Surinx. Duby est un genre de Scala mais qui utilise les type Java uniquement avec 90% la syntaxe de propre de Ruby, Duby a de l’inférence de type et tourne à la même vitesse que Java. Surinx est comme Duby mais il va exploiter le invokeDynamic de Java7 pour permettre des appeles dynamiques comme sur Ruby (mais tj avec les types java et des apples à 90% statiques et du coup une perf mi chemin entre celle de Duby et de JRuby. ces 3 langages utilisent des bases de codes communes crédibles et vont s’intégrer à la perfection. Il y a les slides qui se balades, mais je sais plus ou, sinon regarder:
http://thestrangeloop.com/blog/09/08/18/speaker-focus-charles-oliver-nutter-ruby-mutants
A bon entendeur…