Ruby est un langage de programmation interprété orienté objet originellement développé au Japon. Il est souvent comparé à Python et à Perl bien qu'il utilise des concepts d'autres langages comme Smalltalk. L'application phare est actuellement le framework web Ruby on Rails.
Cette version est principalement une correction de bugs. En effet, le développement se concentre actuellement dans YARV (Yet Another Ruby VM) qui deviendra Ruby 2.0 à sa sortie, mais pas avant encore plusieurs mois. YARV est une réécriture de l'interpréteur (implémentation d'une machine virtuelle Just In Time et Ahead Of Time) qui tente d'apporter une solution au problème majeur de Ruby actuellement : ses performances.
Aller plus loin
- Ruby (3 clics)
- Documentation (2 clics)
- L'annonce de la sortie (2 clics)
- Récapitulation des changements (2 clics)
- Changements dans la version de développement (1.9) (1 clic)
- YARV (Futur Ruby 2.0) (1 clic)
# ...
Posté par Nicolas Blanco (site web personnel) . Évalué à 10.
J'apprécie ce langage objet clair à lire, cela fait bizarre, mais c'est marrant de pouvoir mettre dans son code Rails des 15.minutes.ago pour afficher l'heure d'il y a 15 minutes ou des 15.times plutot que des for(truc = 1; i<=15; i++) et j'en passe.
Ruby et Ruby on Rails m'ont définitivement incités à me relancer dans le développement Web après quelques années de PHP qui ont finies par légèrement me saouler...
[^] # Re: ...
Posté par EppO (site web personnel) . Évalué à 5.
Ruby est vraiment un langage séduisant de part sa facilité de prise en main et son efficacité tranchante dans le cadre d'un framework comme RoR.
Je m'étais penché à recoder un site communautaire en PHP5 et avait fait le proof of concept. Après avoir découvert RoR, quelques tutos et coder quelques exemples, quand j'ai revu mon code PHP5 ensuite, ca m'a piqué les yeux :)
La rapidité de developpement, la maintenance du code, et plein de ptits détails (migration, console irb, ...) couplé à un IDE comme TextMate, le développement web redevient un réel plaisir ! (ca ferait un bon spot de pub geekesque)
[^] # Re: ...
Posté par Frederick Ros . Évalué à 2.
Tu peux tj faire un (1..15).each {|i| ... } si vraiment tu en as envie ;)
# Problème majeur?
Posté par Undefined8000 . Évalué à 3.
Sur le langage en lui-même y'a rien à dire, il est génial.
[^] # Re: Problème majeur?
Posté par Stephane Wirtel (site web personnel) . Évalué à 2.
Peut-être employais-tu des parties spécifique, mais d'habitude, la doc voir même le code du module est facile à comprendre pour se débrouiller.
[^] # Re: Problème majeur?
Posté par BAud (site web personnel) . Évalué à 3.
La version brouillon de la traduction en français du Why’s (Poignant) Guide
[^] # Re: Problème majeur?
Posté par Frédéric COIFFIER . Évalué à 3.
http://rubyforge.org/
[^] # Re: Problème majeur?
Posté par Frederick Ros . Évalué à 2.
[^] # Re: Problème majeur?
Posté par fredix . Évalué à 4.
[^] # Re: Problème majeur?
Posté par Yusei (Mastodon) . Évalué à 6.
Ça devait être il y a longtemps, car le livre "Programming Ruby" a été écrit par des gens qui se sont heurtés eux aussi au fait que la doc était en japonais, et il est paru en 2000. Je ne sais pas quand il a été libéré, mais ça fait quelques années déjà. C'est un très bon moyen de débuter Ruby.
Pour les bibliothèques, celle par défaut est pas mal fournie, et j'ai rarement eu de problèmes à trouver ce que je voulais dans Debian, ou sur le net en dernier recours ;) Je pense que ça s'est considérablement développé depuis que Ruby commence à être largement connu.
[^] # Re: Problème majeur?
Posté par Julien . Évalué à 4.
Concernant le langage en lui même, c'est mieux que du Perl, mais ça ne reste pas aussi lisible que du Python, et je trouve aussi dommage qu'ils aient repris certains trucs "sales" de Perl (notamment les variables "spéciales" $...) ...
[^] # Re: Problème majeur?
Posté par espace . Évalué à 2.
/../ === "é" -----> true
/../u === "é" -----> false
Par contre les $... sont plutôt un gros avantage : même principe que les pronoms, très utilisés dans toutes les langues, très utiles en Ruby par exemple avec les regexpr pour rappeler le texte trouvé.
[^] # Re: Problème majeur?
Posté par gc (site web personnel) . Évalué à 10.
Ça c'est hyper dépendant de ton habitude et de tes préférences. Par exemple de mon point de vue, Ruby est plus lisible que Python.
[^] # Langage OO ?
Posté par Arthur Accroc . Évalué à -2.
Il y a enfin des destructeurs ???
Non ? Alors tant pis, je préfère en rester à des langages qui implémentent complètement le paradigme objet...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Langage OO ?
Posté par gc (site web personnel) . Évalué à 6.
Reste quand même qu'avec Ruby le finalizer est garanti de passer avant la fin du programme, ce qui n'est pas le cas dans la JVM.
http://zarb.org/~gc/t/prog/destructor/nodestructor.rb
[^] # Re: Langage OO ?
Posté par Arthur Accroc . Évalué à -1.
Je sais. La conclusion qui s'imposait était donc qu'un garbage collector (dans le cas de Perl et Python, comme tu le dis, ce ne sont pas de "vrais" GC) est totalement inadapté pour un langage orienté objet.
Question de style plus que de pratique poussée : moi, ça m'a manqué dès mon programme d'essai (un petit programme pour mouliner du XML simpliste et en sortir des pages HTML). J'en ai donc tiré la conclusion qui s'imposait et arrêté le Ruby avec résignation dans la foulée où je l'avais commencé avec enthousiasme.
Merci. Je ne me suis jamais mis au Java parce qu'il ne m'attire pas (il est loin d'avoir comme Ruby une certaine élégance conceptuelle qui suscite l'intérêt), que le peu que j'en ai vu m'a surtout donné l'impression qu'il impose pas mal de complications inutiles, et qu'il ne supporte pas vraiment l'héritage multiple.
Tu viens de me donner une bonne raison supplémentaire de ne jamais m'y mettre (jusqu'ici, celle-ci m'avait échappée).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Langage OO ?
Posté par Boa Treize (site web personnel) . Évalué à 3.
Par ailleurs, comme dans pas mal d'autres langages, rien ne garantit que ton "destructeur" va être appelé avant la fin du programme.
[^] # Re: Langage OO ?
Posté par gc (site web personnel) . Évalué à 3.
[^] # Re: Langage OO ?
Posté par Boa Treize (site web personnel) . Évalué à 2.
[^] # Re: Langage OO ?
Posté par lolop (site web personnel) . Évalué à 4.
Il n'y a pas de vrai ou de faux ramasse-miettes, il y a juste des façons de faire - le but étant de libérer la mémoire sans que le programmeur n'ait à s'en soucier.
Par ailleurs, dans Python il y a - en plus du comptage de références - un ramasse-miettes chargé de détecter les cycles et de détruire les objets devenus inutiles... mais encore référencés dans des structures cycliques.
Python 3 - Apprendre à programmer dans l'écosystème Python → https://www.dunod.com/EAN/9782100809141
[^] # Re: Langage OO ?
Posté par Maz (site web personnel) . Évalué à 2.
Je ne le sais vraiment pas, n'ayant jamais codé en objet avec des destructeurs.
[^] # Destructeurs
Posté par Arthur Accroc . Évalué à 5.
Rien n'est indispensable, on peut tout programmer en assembleur ou avec une machine de Turing. Après, il y a juste des trucs plus pratiques...
Concernant les desturcteurs en particulier, l'intérêt de base est de faire le nettoyage (notamment des ressources éventuellement allouées) ou la sauvegarde de l'état final à la fin de la vie de l'objet de manière automatique et transparente pour l'utilisateur de l'objet (qui n'est pas forcément la personne qui a programmé la classe).
SI tu programmes en style objet un peu extrême, le corps de ton appli consiste principalement en une suite de déclaration d'objets interdépendants, qui gèrent après leurs interactions entre eux, donc par conséquent, une bonne partie du code est localisé au niveau des constructeurs... et des destructeurs, encore faut-il qu'il y en ait.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Destructeurs
Posté par Hank Lords . Évalué à 7.
L'exemple classique est le fichier que tu veux ouvrir et que tu dois fermer à la fin (dans le destructeur par exemple) :
File.open {|f|
# Faire des trucs avec f ...
}
à la fin de l'execution du block, le fichier est fermé.
Donc peut-être que tu as une approche qui n'est pas compatible avec la 'manière de faire' Ruby. Un peu comme si je me plaignais du manque des blocks en C++.
Par ailleurs, tu as un destructeur rudimentaire dans le module ObjectSpace (http://www.ruby-doc.org/core/classes/ObjectSpace.html )
Cependant, il est appelé 'après' la destruction de l'objet.
J'espere avoir ravivé ton interêt pour le Ruby :)
[^] # Re: Destructeurs
Posté par Zenitram (site web personnel) . Évalué à 1.
En C++ et wxWidgets (C++ n'étant que le language, lui faut une bibliotheque, c'est aussi un avantage que je trouve au C++ : tu choisis ta bibliotheque!) :
{wxFile F(f);
// Faire des trucs avec f ...
}
à la fin de l'execution du block, le fichier est fermé.
Meme style de programmation, meme nombre de lignes, OK, ca me conforte, je n'ai toujours rien trouvé de mieux coté Ruby à part peut-etre une bibliotheque standart pas mal, mais bon, ré-inventer un n-ieme language pour une bibliotheque (comme Java d'ailleurs, qui n'est que du C++ castré pour pouvoir faire tourner un JVM, comme C# / J# / VB / etc...), ca devient gonflant... C'est plus un moyen de captation du marché, de verrouillage avec une bibliotheque précise, qu'autre chose...
Il y a des trucs plus propres qu'en C++ dans ces languages, mais de la à créer le buzz que c'est...
Il y a 3 ans, le buzz était au Python, il y a 2 ans le buzz etait sur .net (avec Mono), maintenant c'est Ruby, ces buzz ont des histoires courtes... On en parlera encore dans 5, 10 ans? quelle est la pérénité du code écrit?
Je vais jouer vieux con, je reste au C++, je peux encore utiliser avec lui du code écrit il y a 15 ans (et c'est souvent utile, il y a 15 ans des pregrammeurs n'étaient pas idiots...)
[^] # Re: Destructeurs
Posté par fredix . Évalué à 6.
Tu peux également utiliser les fonctions de fichier proposés par la glib ou Qt via les binding Ruby.
Quant aux "histoires courtes" sur python, mono, ruby, ca tient du troll, sinon faut sortir de ta caverne.
[^] # Re: Destructeurs
Posté par Éric (site web personnel) . Évalué à 8.
Bah, tu prend l'exemple de python ? la pérénité est assurée. Certaines distrib utilisent ça pour leurs outils, j'ai cru comprendre que pour websphere maintenant la console d'administration est en jython, on ne peut pas dire que ceux qui ont pris le train avec le buzz d'il y a 4 ans aient à le regretter.
Même chose pour .net, qui a des parts de marché énormes.
C'est sur que tu pourras tout faire en C++ (et même en basic à la limite), la question est juste de le faire plus simplement ou de manière plus agréable.
[^] # Re: Destructeurs
Posté par oops (site web personnel) . Évalué à 2.
Mouarf, dans les rêves de microsoft peut être....
.NET reste un gros bide pour l'instant.
[^] # Re: Destructeurs
Posté par Boa Treize (site web personnel) . Évalué à 3.
Faudra que j'en parle aux personnes que je connais et qui bossent sur de gros projets .Net...
[^] # Re: Destructeurs
Posté par Frederick Ros . Évalué à 10.
Mouais .. qu'on ne me parle pas de la lisibilité du code C++ écrit il y a 15 ans ... ni des pseudo-codeurs C++, qui font soit du C compilé avec g++, soit une demonstration de tous les design patterns (généralement 2) qu'ils connaissent ...
Pour ce qui est de la pérénité, de mémoire, la première version de Ruby date de 1995 ...
... ensuite tout est une histoire de gout ...
[^] # Re: Destructeurs
Posté par Arthur Accroc . Évalué à 0.
Pour moi, les destructeurs font partie du paradigme objet.
Je sais, mais à ce stade-là, soit il faut systématiquement mettre l'utilisation de tous tes objets dans des blocs passés au constructeurs, ce que je trouve très moche (cela dit, c'est une question de goût), soit le jour où tu changes ton implémentation et où tu t'aperçois que tu as besoin de faire une finalisation, eh bien il faut modifier toutes les utilisations de ta classe.
C'est exactement ça. Donc j'en reste à un langage qui ne m'impose pas sa manière de faire.
Comme les finaliseurs, sur lesquels il se base certainement. Cela limite fortement l'intérêt : quand tu as quelque chose à faire en fin de vie d'un objet, c'est généralement dépendant des attributs de cet objet...
Eh non, désolé.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Destructeurs
Posté par Antoine . Évalué à 6.
A ce niveau de non-justification c'est du troll. Il y a beaucoup de formalisations du "paradigme objet" différentes et elles se focalisent sur d'autres aspects plus fondamentaux (notion de méthodes ou bien de passage de message, héritage, etc.).
Mais bon, tu as le droit de dire que pour toi, les appuie-tête à motif léopard font partie du paradigme voiture.
Note que ta justification pour les destructeurs vient du fait que le langage implémente un système d'exceptions qui peuvent perturber le cours du programme à tout moment. Si le langage n'avait pas d'exceptions ou si leur implémentation était très différente, alors le besoin de finalisation automatique disparaîtrait. (mais peut-être que pour toi les exceptions aussi font partie du paradigme objet ;-)).
Je sais, mais à ce stade-là, soit il faut systématiquement mettre l'utilisation de tous tes objets dans des blocs passés au constructeurs
Là, ça tient de l'ignorance, puisque le système de blocs de ruby (de même que les fermetures en Python ou beaucoup d'autres langages) n'est pas limité à l'utilisation dans le cadre d'un constructeur. Dans l'exemple donné on devine bien que File.open est une banale méthode, pas un constructeur.
Du coup cela évite l'inconvénient du C++ où on doit créer de petits objets auxiliaires (des gardes, il me semble que c'est comme ça qu'on les appelle) gérant la finalisation d'une tâche menacée par des exceptions, parce qu'en C++ le seul moyen simple de faire de la finalisation est par le truchement d'un destructeur donc d'une désallocation d'un objet.
Plus fondamentalement cette utilisation de destructeurs pour la finalisation d'objet est assez criticable dans beaucoup de cas, car on ne voudra pas finaliser de la même façon selon qu'il y a eu une exception et que tout s'est bien passé. Par exemple, si je suis un serveur Web qui exécute un traitement CGI, je ne renverrai pas le même code de retour HTTP selon que le CGI termine bien ou qu'il me pète à la tronche. Donc les blocks try/except/finally sont souvent indispensables.
[^] # Re: Destructeurs
Posté par Arthur Accroc . Évalué à 1.
Évidemment, mais si je programme déclaratif à fond, je n'ai pratiquement que des constructeurs dans les blocs de haut niveau, donc ça revient à ça.
Quoiqu'il en soit, ce n'est pas transparent à l'utilisation.
En même temps, vu qu'un destructeur est typiquement le truc qui ne rend rien, là il faudra bien utiliser explicitement autre chose pour avoir un code de retour (quitte pour moi à me résoudre à ne pas faire du 100% déclaratif ;-) ; de toute façon, à un certain niveau, il faut bien que je mette des instructions pour que mon programme fasse quelque chose)...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Destructeurs
Posté par Thomas Douillard . Évalué à 8.
De mon point de vue, ce qu'il y a dans les constructeurs c'est des initialisations, des appels à d'autres constructeurs pour les compositions, mais les interractions elles se font essentiellement APRÈS la constrution de l'objet. Pour les destructeurs, je suis assez perplexe aussi.
[^] # Re: Destructeurs
Posté par Thomas Hervé . Évalué à 6.
Le parallèle entre les constructeurs et les destructeurs est complétement mal venu. Le constructeur d'un objet est appelé à l'initiative de l'application, alors qu'en général on ne peut pas prévoir quand l'appel à un destructeur sera fait. Avoir une logique applicative dans un destructeur c'est un très mauvais design objet, il faut mieux avoir une méthode de finalisation appelée explicitement.
Tu parles en particulier de Python, alors qu'en Python l'utilisation des destructeurs est très découragée. D'abord parce que cela casse une partie du GC (en gros il a beaucoup de mal a détecter les cycles lorsque les objets définissent une méthode __del__). Ensuite parce qu'il y a (très) souvent moyen de faire mieux et plus propre. Un destructeur doit être utilisé dans des cas très particuliers.
[^] # Re: Destructeurs
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 6.
Ce point est TRES intéressant. J'ai justement eu un mini débat sur le sujet avec mes collègues : quel rôle donner aux constructeurs/destructeurs. En gros, jusqu'où va la construction de l'objet : simplement une affectation des membres à des valeurs par défaut pour rendre l'objet prèt à fonctionner ou du code réellement "fonctionnel".
Si vous avez des liens vers des "ouvrages" (au sens large, ce peut être un bouquin comme un wiki) sur le sujet, je suis vraiment intéressé.
Pour le coup, y'a vraiment un troll la-dedans, donc merci de resister à l'envie et poster uniquement des références.
[^] # Re: Destructeurs
Posté par Gniarf . Évalué à 1.
[^] # Re: Destructeurs
Posté par Gabriel . Évalué à 3.
http://today.java.net/pub/a/today/2006/08/24/five-habits-of-(...)
Toute une série de conseil, dont le premier est une réponse à ta question: "Constructor Performs Minimal Work"
Pour le détail de l'argumentation: "its constructor will only load data into its instance variables using the constructor's parameters."
"A constructor is used to create an instance of an object. A constructor's name is always the same as the object's name. Since a constructor's name is unchangeable, its name is unable to communicate the work it is performing. "
"the readability of the software is high because the constructor simply creates an instance of the object, letting the behavior and state-changing methods do the rest."
Voilou..
[^] # Re: Destructeurs
Posté par Arthur Accroc . Évalué à 1.
C'est moins vrai dans le cas de langages qui autorisent plusieurs constructeurs de noms différents (pas le genre de truc qui me sert tous les jours, mais c'est vrai que quelquefois, c'est sympa)...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Destructeurs
Posté par golum . Évalué à 4.
Dans ce cas la remarque reste valable.
[^] # Re: Destructeurs
Posté par Arthur Accroc . Évalué à 1.
Là, tu penses probablement au C++.
Moi, je pense en particulier à Perl, où le constructeur est juste une méthode de classe qui a la particularité de retourner un nouvel objet de la classe. La convention suggère de l'appeler new, mais on peut aussi bien l'appeler zorglub ou en faire plusieurs.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Destructeurs
Posté par Bonnefille Guilhem (site web personnel) . Évalué à 2.
Moi, je ne connais pas Perl, mais ce commentaire me fait penser à Objective-C. En effet, en Objc, il n'y a pas de constructeur à la C++/Java. La phase de construction est décomposée en deux :
- l'allocation : par appel d'une méthode de nom "alloc" sur la classe ;
- l'initialisation : par la méthode de nom recommandé "init" (mais on peut aussi l'appeler "zorglub") ou en créer plusieurs : initWithString, initWithDouble, initWithZorglub...
[^] # Re: Langage OO ?
Posté par Éric (site web personnel) . Évalué à 3.
Sinon, sur le principe, les destructeurs existent, ils sont juste une galère à utiliser.
# Apprentissage de Ruby
Posté par Stephane Wirtel (site web personnel) . Évalué à 7.
Par après, j'ai appris à employer Ruby dans les bons moments, là où c'est vraiment utile, génération automatique de code, création aisée de fichier XML etc.... enfin des choses qui prennent bcp plus de temps à réaliser en C++.
Depuis lors, j'ai regardé RoR et honnêtement, j'ai été sur le Q de voir tout ce qu'il était possible de faire en très peu de temps. Bien que j'ai déjà eu des connaissances en PHP (3 & 4), l'utilisation de l'ActiveRecord et des autres composants de Rails donne des avantages indégniable par rapport à d'autres outils.
Honnêtement, j'attends avec impatience la fameuse version 2.0 de ruby qui devrait permettre l'utilisation d'une autre VM, car l'actuelle est effectivement très lente.
Pour rappel, il existe de très bons ouvrages sur Ruby et RoR, ainsi que RadRails et RDT qui s'utilisent avec Eclipse.
[^] # Re: Apprentissage de Ruby
Posté par Maz (site web personnel) . Évalué à 4.
Surtout, il n'y en a pas, actuellement :).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.