Matz, fidèle à son habitude, a délivré le 25 décembre 2004 une version stable de Ruby (en l’occurrence la 1.8.2)
Longtemps attendue, mais retardée pour cause de manque de temps, la nouvelle version de Ruby corrige quelques bugs, et voit sa collection de classes « standards » augmenter (notamment l’ajout de RSS::Parser, SOAP4R, Net::HTTPS, l’extension de Ruby/Tk, le support des vhosts par WEBRick, ainsi que l’amélioration de Ri et RDoc).
À noter au passage, le fantastique livre de Dave Thomas sur Ruby. Ce livre en est à sa seconde édition, la première étant diffusée librement.
Aller plus loin
- Site officiel de Ruby (13 clics)
- Ruby-Wiki (via WebArchive) (8 clics)
- Red Handed (via WebArchive) (7 clics)
- Principaux changements (via WebArchive) (6 clics)
- L'API core (5 clics)
- L'API de la bibliothèque standard (8 clics)
# A quand le diamant?
Posté par MiniMoi . Évalué à 3.
# livre libre
Posté par TazForEver . Évalué à 2.
[^] # Re: livre libre
Posté par Frederick Ros . Évalué à 1.
[^] # Re: livre libre
Posté par TazForEver . Évalué à 2.
[^] # Re: livre libre
Posté par Frederick Ros . Évalué à 2.
Pour la qualite du bouquin, ben quand on voit la qualite des autres livres de D. Thomas, on comprend ;)
[^] # Re: livre libre
Posté par Pascal Terjan (site web personnel) . Évalué à 5.
[^] # Re: livre libre
Posté par Alex . Évalué à 1.
[^] # Re: livre libre
Posté par Frederick Ros . Évalué à 1.
Tu peux aussi essayer : le Why (Poignant) Guide : http://poignantguide.net/ruby/(...) , pas encore complet mais ca avance ...
[^] # Re: livre libre
Posté par Laurent Sansonetti . Évalué à 1.
Le chapitre sur les gems est dispo:
http://www.pragmaticprogrammer.com/titles/ruby/gems.pdf(...)
Mais sinon le livre vaut vraiment l'achat. Bonne typographie, facile a naviguer, et il documente toute la stdlib. Un must-read!
[^] # Re: livre libre
Posté par Frederick Ros . Évalué à 1.
# Qu'est-ce que Ruby ?
Posté par Mes Zigues . Évalué à 6.
Ruby is the interpreted scripting language for quick and easy object-oriented programming. It has many features to process text files and to do system management tasks (as in Perl). It is simple, straight-forward, extensible, and portable.
Oh, I need to mention, it's totally free, which means not only free of charge, but also freedom to use, copy, modify, and distribute it.
En gros c'est un langage de programmation orienté objet interprété portable et libre (licences GPL et Ruby). Donc Ruby désigne le langage et l'interpréteur. Il est développé au Japon.
Il y a un article sur Ruby dans Wikipédia : http://fr.wikipedia.org/wiki/Ruby(...)
Chez Framasoft : http://www.framasoft.net/article2923.html(...)
Le guide utilisateur en français : http://perso.wanadoo.fr/alain.feler/(...)
Cela n'a rien à voir avec l'annotation Ruby de XHTML 1.1 du W3C : http://www.yoyodesign.org/doc/w3c/ruby/(...)
---
Touchez pas au clavier j'ai une gastro.
[^] # projets en Ruby ?
Posté par BAud (site web personnel) . Évalué à 3.
il s'y trouve par exemple un gestionnaire de livres, sous Gnome (tous vos bouquins via leur ISBN avec saisie automatique des données titre, auteur, édition, page de garde à partir de sites en ligne) http://rubyforge.org/projects/alexandria/(...)
[^] # Re: projets en Ruby ?
Posté par patrick_g (site web personnel) . Évalué à 1.
l'emmerde c'est que 80% de ma bibliothèque c'est des livres anciens (19ieme ou même 18ieme siècle) et que je peux me brosser pour avoir des numéros ISBN....c'est l'inconvénient de la bibliophilie !
tu connais pas une autre solution ?
[^] # Re: projets en Ruby ?
Posté par BAud (site web personnel) . Évalué à 2.
les n° EAN sont gérés aussi, désolé ça t'aide pas non plus :-(
Plus sérieusement, je viens de vérifier, la saisie manuelle des données est possible dans la version dont je dispose (la 0.4.0)
Si tu as des bibliothèques en ligne qui proposent une interface comme Amazon, Proxis and Barnes and Noble tu peux la suggérer sur la ML de dév d'alexandria : ils essaieront sans doute de le prendre en compte si c'est documenté : alexandria-list at rubyforge dot org http://rubyforge.org/mailman/listinfo/alexandria-list(...)
[^] # Re: projets en Ruby ?
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
def yaml(book) File.join(self.path, book.isbn + EXT[:book]) endL'ISBN est considéré comme la clé unique et les livres sont stockés en temps que <ISBN>.yaml donc pour gérer des livres sans ISBN il faudrait un changement important (trouver ou définir un autre identifiant...) :-([^] # Re: projets en Ruby ?
Posté par Frederick Ros . Évalué à 1.
[^] # Re: projets en Ruby ?
Posté par Laurent Sansonetti . Évalué à 1.
[^] # Re: Qu'est-ce que Ruby ?
Posté par Frederick Ros . Évalué à 3.
# Différence avec Python ?
Posté par Juju . Évalué à 1.
D'après ce que je sais Python est aussi orienté objet et les API ont l'air bien complètes ? Quel est donc l'avantage de Ruby sur Python ?
[^] # Re: Différence avec Python ?
Posté par Pascal Terjan (site web personnel) . Évalué à 1.
Python : string.split(s,'","') Ruby: s.split(',')On voit mieux en Ruby qu'on appelle une methode de l'objet surtout quand on enchaine :Python: string.join(string.split(s),"|") Ruby: s.split().join('|')[^] # Re: Différence avec Python ?
Posté par Ramso . Évalué à 6.
> Python : string.split(s,'","')
T'aurais pu faire plus compliqué encore pour valoriser Ruby...
[^] # Re: Différence avec Python ?
Posté par Pascal Terjan (site web personnel) . Évalué à 0.
Pour ce qui est de ces 2 exemple, j'ai cherché un tutorial python sur google et j'ai copié 2 des exemples... Si on peut avoir des trucs lisibles en python c'est bien, mais pourquoi est-ce si peu utilisé alors ?
[^] # Re: Différence avec Python ?
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 2.
Je ne vois pas en quoi on voit un "esprit refleté dans ruby", quand on écrit mal du python comme ça ....
en python, on peut écrire aussi :
s.split(",") ## idem qu'en ruby ##
et
"|".join( s.split(",") ) ## qui est même plus parlant qu'en ruby je trouve (*) ##
* : on voit bien que le retour de ça, sera du "string"
[^] # Re: Différence avec Python ?
Posté par Pascal Terjan (site web personnel) . Évalué à 3.
J'ai oublié le mot objet :/
quand on écrit mal du python comme ça
Ce python n'est pas de moi, c'est un des premiers exempels que j'ai trouvé sur python...
on voit bien que le retour de ça, sera du "string"
ah ? tu le vois ou ?
"plop".length, on voit bien aussi que le retour sera une string ?
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
* : on voit bien que le retour de ça, sera du "string"
Super parlant en effet... Comme je l'ai dit dans un precedent commentaire, je comprends pas que l'operateur join appartienne a la classe String ...
En Ruby (je sais plus pour le Python), on parle de message, pas de methodes. Donc si je lis ton code avec un esprit de Rubyiste, je lis :
Envoie le message join a l'objet "l" ... Pas Zarb ca ?
[^] # Re: Différence avec Python ?
Posté par Volnai . Évalué à 2.
Tiens donc, on se rapprocherais donc de l'objet façon Objective C ? C'est quoi le vrai objet : avec des methodes, ou avec des messages ?
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
[^] # Re: Différence avec Python ?
Posté par applex . Évalué à 1.
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
[^] # Re: Différence avec Python ?
Posté par applex . Évalué à 0.
Et pourquoi "ben non?"
Dire "Ruby utilise la notion de message comme objectiveC" et tout aussi bon que dire "Ruby utiliser la notion de message de smalltalk" :)
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
Mon point etait que Smalltalk etant anterieur a ObjC, et ObjC ayant repris la notion de message de Smalltalk, il me semblait plus precis de dire que c'etait des messages a la Smalltalk ;)
[^] # Re: Différence avec Python ?
Posté par Éric (site web personnel) . Évalué à 4.
> trouve (*) ##
ah ?
marrant, naturellement le join je le ferai sur un tableau moi. Je joint "les éléments du tableau" "avec" "|". En Objet ça donne "les elements du tableau".join( "|" ) et pas le contraire.
En POO toujours, quand on opère deux transfo successives sur un même objet, on peut généralement les chainer : s.split(',').join('|')
C'est en voyant que ça ne marche pas qu'on peut facilement se rendre compte qu'il y a une couille dans l'ordre des paramètres.
C'est du détail mais il ne faut pas aller dire non plus que c'est "mieux" pour autant. Si j'ai bien compris si c'est différent en python c'est plus historique (appartenance au module string avec une chaine comme premier paramètre => passage en méthode de l'objet string)
> * : on voit bien que le retour de ça, sera du "string"
où ? pourquoi ? je ne suis pas d'accord. Je ne vois pas en quoi mettre "|".join(list) ou list.join("|") me donne une quelconque indication sur le type de la valeur de retour. Sauf à croire qu'une méthode qui s'applique sur une chaine ne peut retourner qu'une chaine.
[^] # Re: Différence avec Python ?
Posté par Amand Tihon (site web personnel) . Évalué à 2.
Oui, je reconnais que c'est un des bouts déroutants de Python. Mais en fait, les deux sont logiques.
Avec "|".join(t), je demande au caractère "|" de faire la jointure entre les éléments de t.
J'envoie à l'objet "|" le message "sert de glue à" "mon tableau t".
Pour l'histoire du type de retour, je suis bien sûr d'accord avec la majorité :)
[^] # Re: Différence avec Python ?
Posté par Misc (site web personnel) . Évalué à 3.
misc@skittles:~$ python
Python 2.3.4 (#2, Dec 3 2004, 13:53:17)
[GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s="oui non"
>>> s.split(' ')
['oui', 'non']
>>> ','.join(b)
'oui,non'
>>> ','.join(s.split(' '))
'oui,non'
bon, ok, l'ordre du join est moins naturel, il y a peut être une bonne raison.
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
Je vois pas en quoi l'operateur join devrait s'appliquer a une chaine ...
[^] # Re: Différence avec Python ?
Posté par applex . Évalué à 1.
Mais il est clair que tu ne pouvais pas le savoir vu que tu ne l'utilises pas ce langage (et c'est dommage de donner son avis sur un sujet que l'on ne connait pas).
Le choix d'un langage (comme de tout outil de développement) est une histoire de goût et dépend des besoins également.
A chacun d'essayer pour se faire une idée et ne pas choisir en fonctions des autres.
Et j'ai l'impression que ce flux ce transforme en troll (ou bien le concours de la plus grosse entre Python et Ruby)... Pour continuer dans la foulée, on n'a qu'à parler de Perl que certains idolâtre (même si je pense que ces derniers ont des problèmes psy :-) )
[^] # Re: Différence avec Python ?
Posté par Arthur Accroc . Évalué à 1.
Ben quoi ? Perl, ça peut être le meilleur choix, tout dépend pour quoi faire.
Pour l'administration système, en particulier :
- fonctions de manipulation de fichiers directement intégrées au langage;
- pareil pour les fonctions de traitement (au sens traitement automatisé) de texte (expressions rationnelles, ensemble de possibilités équivalentes à celles d'awk, etc.);
(et les fichiers de configuration, de logs, etc. sont pratiquement tous des fichiers texte... à part sous Windows);
- des fonctions intégrées proches du système;
- une base de modules (http://www.cpan.org/(...)) contenant, entre autres, tout ce dont on peut rêver pour l'administration système (j'ai déjà eu besoin de trucs très pointus);
- possibilité de faire des unilignes (essayez donc en Python !) plus courts et plus puissants qu'avec uniquement le Shell (et les unilignes, c'est bien pratique pour faire rapidement et de manière automatisée un traitement lourd et/ou complexe sur des fichiers; voir http://www-106.ibm.com/developerworks/linux/library/l-p101/(...) et http://www-106.ibm.com/developerworks/linux/library/l-p102.html?ca=(...));
- possibilité assez facile d'interface aussi bien texte, que graphique ou CGI (pratique pour réutiliser du code d'un script d'administration pour une interface qu'on fournit aux utilisateurs);
- disponible sur les principales plateformes et souvent déjà installé sur les systèmes de type Unix (on est parfois amené à intervenir sur des systèmes qu'on a pas installé soi-même)...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 2.
Pour ce qui est des autres points, je pense que Python (et Ruby) commence largement concurrencer Perl. Ne connaissant pas suffisamment Python (et ne voulant pas dire de betises) je ne parlerai que de Ruby (mais IMHO c'est pareil pour Python):
- Les fonctions de manipulations de fichiers et/ou de traitements sont integrees (et souvent multi-plateforme d'origine: par exemple pour concatener plusieurs composant d'un path, tu peux faire a la Perl une concatenation de chaines, ou utiliser le File.join pour avoir les delimiteurs de la plateforme: / ou \ par exemple
- Les modules de bases sont de plus en plus repandus/developpes.. Tu serais etonne de voir ce que l'on trouve sur RAA/RubyForge. Pour les installer : utiliser Ruby Gems est le plus simple ..
- Les unilignes existent aussi ..
- L'interface est souvent facilite par le fait que tu essaies de faire un design propre ..; La sortie 'ecran' n'etant qu'une facon de publier
- Seul le dernier point peche: pour le moment Ruby n'est pas installe partout ..; mais ca va venir ;) (qund j'ai commence le Perl il fallait l'installer soit meme ou demander une install ...)
J'ajouterais que de nombreuses lib sont integrees dans la distrib standard de Ruby. L'autre jour j'ai ainsi eu a reformater de long doc XML (formattes sur une seule tres tres longue ligne) : je n'ai pas eu a utiliser de module externe pour pouvoir parser du XML, et le programme terminal m'a pris 2 ou 3 lignes ..
Tu peux faire des trucs marrants juste avec la distrib d'origine:
http://redhanded.hobix.com/inspect/mp3EncodingFromAGreatDistance.ht(...)
[^] # Re: Différence avec Python ?
Posté par Arthur Accroc . Évalué à 1.
Quand on l'a programmé soi-même et pour peu qu'on ait un style propre et cohérent, on peut encore s'en sortir assez bien.
Évidemment, ceux qui passent derrière peuvent avoir plus de mal, mais bon, si c'est parce qu'on s'est fait viré de son boulot, on ne considère peut-être plus ça comme un inconvénient. ;-)
Bon, j'admet volontiers que si je voulais développer un projet de grande ampleur, j'envisagerais Ruby ou Python (et j'aurais du mal à choisir lequel...).
mais IMHO c'est pareil pour Python
Pas pour les unilignes : des unilignes dans un langage qui définit les blocs par l'indentation, même si ce choix ne me paraît pas mauvais par ailleurs, ça pose tout-de-suite un problème conceptuel...
En fait, un des buts avoués du concepteur de Ruby était de faire un langage qu'on puisse utiliser en lieu et place de Perl, alors que ce n'est pas un objectif de Python.
Ça explique la validité de tes arguments portant sur le langage (la question de la large disponibilité ou pas, quant à elle, ne dépend pas du langage lui-même...).
Tu peux faire des trucs marrants juste avec la distrib d'origine:
Je n'en doute pas. J'ai essayé Ruby en faisant un petit truc et je l'ai trouvé globalement génial... mais d'un autre côté, il y a quelques détails qui me gênent bien :
* L'absence de destructeurs : un langage objet dans destructeurs, c'est un peu comme un langage objet sans héritage multiple. Je suis habitué à utiliser les destructeurs pour enregistrer l'état, finalliser des traitements, etc. et ça me gêne bien qu'il n'y en ait pas. La construction la plus proche que j'ai trouvée consiste à prévoir des constructeurs acceptant en paramètre une closure définissant le traitement à effectuer et assurant eux-mêmes après celui-ci les éventuelles finalisations ou enregistrements, mais ça ne me plaît pas... D'un autre côté, Perl passant lui aussi au garbage collector avec la prochaine version 6, je crains aussi un peu ce qui pourra lui arriver de ce côté-là...
* Les end : c'est verbeux et puis, alors que l'indentation permet tout-de-suite avec Python de vérifier que les blocs sont correctement délimités, et que pour Perl ou le C/C++ n'importe quel éditeur un peu potable surlignera pour cela les paires d'accolades qui vont ensemble, la même vérification impliquera pour Python un éditeur avec un mode spécifique assez sophistiqué.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
Évidemment, ceux qui passent derrière peuvent avoir plus de mal, mais bon, si c'est parce qu'on s'est fait viré de son boulot, on ne considère peut-être plus ça comme un inconvénient. ;-)
Bon, j'admet volontiers que si je voulais développer un projet de grande ampleur, j'envisagerais Ruby ou Python (et j'aurais du mal à choisir lequel...).
Bof .. je fais gaffe a mon style en Perl, mais j'ai vraiment des pbs a reprendre un de mes programmes quelques temps apres .. .alors quand il s'agit de celui d'un dev qui s'en foutait un peu ...
* L'absence de destructeurs : un langage objet dans destructeurs, c'est un peu comme un langage objet sans héritage multiple. Je suis habitué à utiliser les destructeurs pour enregistrer l'état, finalliser des traitements, etc. et ça me gêne bien qu'il n'y en ait pas. La construction la plus proche que j'ai trouvée consiste à prévoir des constructeurs acceptant en paramètre une closure définissant le traitement à effectuer et assurant eux-mêmes après celui-ci les éventuelles finalisations ou enregistrements, mais ça ne me plaît pas... D'un autre côté, Perl passant lui aussi au garbage collector avec la prochaine version 6, je crains aussi un peu ce qui pourra lui arriver de ce côté-là...
Si tu as des finalisations le plus propre est sans doute de prendre l'approche block, un peu comme le File.open ...
* Les end : c'est verbeux et puis, alors que l'indentation permet tout-de-suite avec Python de vérifier que les blocs sont correctement délimités, et que pour Perl ou le C/C++ n'importe quel éditeur un peu potable surlignera pour cela les paires d'accolades qui vont ensemble, la même vérification impliquera pour Python un éditeur avec un mode spécifique assez sophistiqué.
Ben je trouve pas ca vraiment tres verbeux : tu as 2 caracteres de plus qu'avec une accolade !
[^] # Re: Différence avec Python ?
Posté par Arthur Accroc . Évalué à 1.
Oui, c'est ce que je voulais dire.
Cela dit, dans ce cas, cela oblige à être conscient de la nécessité de finalisation au niveau de l'utilisation de la classe, contrairement au principe du destructeur. C'est moins souple.
Par exemple, si après changement d'implémentation, une classe qui n'avait besoin d'aucune finalisation en a maintenant besoin, ça peut impliquer de modifier toutes ses utilisations !
Ben je trouve pas ca vraiment tres verbeux : tu as 2 caracteres de plus qu'avec une accolade !
C'est juste que je préfère laisser les lettres aux choses plus significatives, mais ce sont surtout les contraintes pour la vérification qui me dérangent.
Cela dit, ce n'est pas ce point, mais le premier, qui m'a arrêté net dans mon élan vers Ruby...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
Les justifications de ces 2 problemes que j'ai trouvee ne m'ont pas convaincu du tout.
Ensuite tout est question de gout.
[^] # Re: Différence avec Python ?
Posté par srm . Évalué à 3.
class Rectangle include Comparable attr_reader :width, :height def initialize(w, h) @width, @height = w, h end def <=>(o) [@width, @height] <=> [o.width, o.height] end end class Square < Rectangle def initialize(side) @width = @height = side end def <=>(o) if o.type == Square @width <=> o.width else o <=> self end end endPythonclass Rectangle: def width(self): return self.__width def height(self): return self.__height def __init__(self, w, h): self._width, self.__height = w, h def __cmp__(self, o): return cmp( [self._width, self.__height], [o.width(), o.height()]) class Square(Rectangle): def __init__(self, side): self._width = self.__height = side def __cmp__(self, o): if isinstance(o, Square): return cmp(self.__width, o.width()) else: return o.__cmp__(self)Merci à Lucas pour l'exemple ;-)[^] # Re: Différence avec Python ?
Posté par Volnai . Évalué à 0.
[^] # Re: Différence avec Python ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
[^] # Re: Différence avec Python ?
Posté par Volnai . Évalué à 4.
Si je devait choisir un language à apprendre, et qu'on me presentait ces 2 exemples, je ne choisirais pas python. C'est illisible (par rapport à ruby s'entends). Tout ces __ c'est d'un laid, ca pollue l'affichage.sans parler des "self" (presque 1 par ligne de code en moyenne !). C'est dommage tout ça , d'autant plus que le fait de forcer à avoir une indentation propre est une bonne idée pour la lisibilité, mais la c'est gaché.
Et effectivement, mais çà c'est une question goût (alors que personne n'osera dire que l'exemple python est plus lisible que le ruby), je trouve plus clair les appel de methodes (ou envoie de messages) dans ruby.
Je ne jugeait pas là les qualité intrinsèques aux langages. Sur ce point je suis persuadé qu'ils se valent, et qu'ils valent perl.
[^] # Re: Différence avec Python ?
Posté par applex . Évalué à 3.
Perso, je ne trouve pas cela illisible, c'est un repère.
C'est un peu comme ceux qui déclarent les variables d'instance en précédant leur nom avec "m_" ou "m" ou bien "__".
[^] # Re: Différence avec Python ?
Posté par Volnai . Évalué à 2.
Bref, pour mieux dire le fond ma pensé; on met régulierement en avant la "propreté" de python par rapport à perl (facile) ou même Java (ca se discute). L'impression que j'ai ici, c'est que face à Ruby il n'y a pas photo à ce niveau là (je ne juge pas le reste). Un peu comme il n'y a pas photo entre la lisibilité d'un programme objet en C++ et le même en Objective C.
[^] # Re: Différence avec Python ?
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 2.
Absolument pas. Ce sont des mots clés réservés de Python, qui sont utilisés pour certains comportements standards.
Un peut comme __get(), __set() en PHP5.
[^] # Re: Différence avec Python ?
Posté par Volnai . Évalué à 1.
[^] # Re: Différence avec Python ?
Posté par Éric (site web personnel) . Évalué à 3.
Je ne crois pas qu'on puisse résumer la lisibilité à des nombres d'occurences ou de caractères. Des fois rajouter des choses en les mettant explicitement peut être plus clair/lisible.
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 3.
[^] # Re: Différence avec Python ?
Posté par Volnai . Évalué à 3.
Dans cet exemple c'est faux, compte avant d'affirmer ça.
Alors oui, compter le nombre de caractères n'est pas une "méthode qui tue" pour juger un programme, je te l'accorde. Mais en même temps, si je dit juste que "python c'est moche", on me demande de justifier, alors j'essaye de prendre une mesure rationnelle de ce qui le rend moche (tout ca c'est par rapport à ruby hein).
Je me demande alors pourquoi j'ai cette impression de "gros bordel" quand je lis le code Python, et que je ne l'ai pas quand je lis le code Ruby. Bon bah la reponse est clair pour moi : l'affichage est beaucoup plus polué en Python qu"en Ruby. Et j'utilise le mot "polué" parceque tout ces self et autres _ n'apportent, a mon sens, rien à la compréhension du code; la preuve, le code Ruby n'en a pas et je le comprends aussi bien (alors que c'est probablement le premier programme ruby que je lis). Et puis passer self en parametre dans les définitions de méthodes, tu trouves ça justifiable/compréhensible ?
[^] # Re: Différence avec Python ?
Posté par Sébastien Bonnefoy (site web personnel) . Évalué à 1.
Le fait de ne pas avoir de délimiteur de fin de bloc et de n'avoir que l'indentation est assez inhabituel pour qui ne fait pas de python, et c'est une bonne raison de le trouver moche. On trouve en général moche ce qu'on a pas l'habitude de voir. Je ne pense pas que ca vienne uniquement des décorateurs.
[^] # Re: Différence avec Python ?
Posté par Volnai . Évalué à 2.
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 3.
et franchement le code python m'a tout de suite parlé ...
le code ruby : franchement bof ... j'ai du m'aider du code python pour comprendre celui de ruby !
C vraiment une question d'habitudes ...
si tu viens de perl/bash ... le ruby te parlera mieux, c évident
si tu viens de tous les autres (excepté les eiffels,smalltalk, objc ...) ... le python te parlera plus ...
(je pense que plus de dev sur terre viennent du monde c/pascal/cobol/basic que du monde perl/bash)
et même si t'es pas développeur du tout, le python te parlera plus (c là son avantage sur sa syntaxe)
maintenant, il est vrai que je connais bien python, et très peu (voire pas du tout) perl/ruby/bash, ma vision est certainement un peu biaisé ...
et j'aime tellement le python, que quand je fais autre chose (c#/php/javascript/xslt principalement), je deviens fou juste à l'idée de devoir mettre des crochets partout ... alors que mon code sera toujours indenté correctement ...
alors, si je devais mettre des "end" comme en vb un peu partout, ça me plairait pas du tout (je hais vb)... et trouverai également que ça pollue énormément le code ...
quand au "__" de python, ça "pollue" ou "améliore la lisibilité" autant que les $ et @ de ruby ... question de goût (le géniteur de ruby , je crois, regrette d'avoir pris c décisions du début)
le cas du self : tu peux l'appeler "S" ou "_" au lieu de self, tu gagneras 3 caracs ... (par convention de programmation, self c mieux, evidemment)
maintenant, quand à l'argument ruby est full OO, alors que c venu après sur python .... bof aussi ...
car le full OO, t'obliges à programmer en OO uniquement ! et ça je sais pas si c'est un avantage ... (en python, t'as le choix)
encore un truc, je suis persuadé que je m'éclaterai plus en OO avec ruby avec python, c même certain ... mais je trouve que le code ruby est rempli de hiéroglyphes qui ne me parlent pas du tout au premier abord ... et ne me donnent pas envi ...
maintenant, tout ça est subjectif ... chacun ses gouts et ses couleurs (heureusement)
moi je choisi pas le langage en fonction de ses qualités intrasecs, mais en fonction de ce qui va m'apporter ...
et en python, au niveau libs, c bien simple, tu peux tout faire dans tous les domaines ...
au niveau ouverture, tu peux faire des classes java, tout comme des classes dot.net ....
et bientôt (avec starkiller, le compilo), on devrait même pouvoir générer des "executable", et venir concurrencer le C/exe
que demander de plus ? non ?
[^] # Re: Différence avec Python ?
Posté par Volnai . Évalué à 2.
A mon avis, quelqu'un qui n'est "pas developpeur du tout" come tu le dis, il ne comprendra rien à aucun des deux codes.
Les quelques "end" te deplaisent ? un petit "end" sur un ligne ne me gene pas, en tout cas moins que de devoir mettre un self à chaque ligne, et en plus dans le prototype d'une méthode ! Serieusement, c'est comme ca qu'on fait en python ? Si oui, je ne comprends pas comment on peut defendre ca, en tout cas j'ai jamais eu à faire des constructeur avec "this" en paramétre en Java (d'ailleurs le this de java ne me plait pas plus que le self de ptyhon, mais j'ai l'impression qu'il est un peu moins présent). Franchement, si on est obliger de donner 2 parametres au constructeur d'une classe Square, ca me fait bien rigoler...J'imagine qu'il y à une bonne raison que je ne connais pas ?
quand au "__" de python, ça "pollue" ou "améliore la lisibilité" autant que les $ et @ de ruby
Non, apprends à compter, ou arrête la mauvaise fois, il y en a infiniment moins en ruby.
car le full OO, t'obliges à programmer en OO uniquement !
Et cette restriction te permet d'avoir un code plus structuré, contrairement à un langage "fourre tout" qui te permet de tout faire (perl etant l'exemple ultime). Et quand tu decide de programmer objet, autant prendre un "vrai" langage objet, et ne pas essayer de faire du procedural avec.
Si tu choisi un vraiment langage en fonction de son API, jette python et met toi à java ou .net. Ou perl.
[^] # Re: Différence avec Python ?
Posté par pifou . Évalué à 5.
C'est pas mal ça de dire que tu comprends mieux le code Python en disant 5 lignes plus tard que tu connais très bien Python :). De même je comprends beaucoup mieux l'anglais que l'allemand que je n'ai jamais appris :).
si tu viens de perl/bash ... le ruby te parlera mieux, c évident
Tu ne dois vraiment pas connaître Perl et Bash pour dire que Ruby ressemble à ces langages ! Mise à part les variables spéciales ($*) et les expressions régulières intégrées dans Ruby, il n'y a aucun point commun.
Après effectivement, pour des gens ayant appris à coder en C/C++ le Python sera surement plus lisible. Par contre le pense que Ruby est bien plus lisible pour des personnes ayant programmés en Java/SmallTalk/Eiffel que des personnes ayant fait du Perl/Bash.
(je pense que plus de dev sur terre viennent du monde c/pascal/cobol/basic que du monde perl/bash)
C'est à vérifier, car actuellement il me semble que dans les formations en informatique (sauf industrielle) on insiste plus sur les technologies objets (Java/C#/J2EE/.Net/C++ ...) que sur les langages procéduraux de type C/Pascal/Cobol/Basic qui sont bien sur toujours abordés pour des raisons historiques et techniques. Ça n'enlève rien à la puissance et l'utilité de ces langages.
et même si t'es pas développeur du tout, le python te parlera plus (c là son avantage sur sa syntaxe)
Pour la lisibilité du code pour un non développeur, je te trouve bien présomptueux, je ne me risquerais pas à dire quel langage serait le mieux. Tout dépend des bases que les personnes ont. Si tu apprends à quelqu'un à penser en procédural, il sera attiré par la syntaxe Python, en revanche si tu lui apprends à penser Objet, il sera surement attiré par Ruby.
maintenant, quand à l'argument ruby est full OO, alors que c venu après sur python .... bof aussi ... car le full OO, t'obliges à programmer en OO uniquement ! et ça je sais pas si c'est un avantage ... (en python, t'as le choix)
En Ruby aussi tu as le choix mais pour ce qui de programmer en 'full OO', personnelement je trouve que c'est un véritable avantage, ça te force à bien structurer ton programme. J'ai longtemps écrit des programmes en Perl qui marchait pas mal, par contre au niveau maintenabilité du code c'était ingérable. Je ne parle même pas de mes essais pour faire du code objet en Perl (quelle horreur, j'attends Perl6 pour voir si ça s'arrange de ce coté là). J'ai commencé à réécrire des programmes Perl en Ruby et effectivement même si c'est possible de faire une transcription bête et méchante (sans notion OO), j'ai très rapidement séparé mes bouts de code dans différentes classes. À la fin, je me retrouve avec un code moins long et beaucoup mieux organisé.
le cas du self : tu peux l'appeler "S" ou "_" au lieu de self, tu gagneras 3 caracs ... (par convention de programmation, self c mieux, evidemment)
J'aime bien les gens qui défendent mordicus les faiblesses/erreurs de conception d'un langage comme des 'features', que ce soit en Java (héritage simple), Perl (références), Python (le self dans les paramètres des messages). Pour ce qui est du 'self', je suis d'accord que c'est plus lisible de le laisser quand on fait appel à une variable, ça permet d'un coup d'oeil de savoir si une variable est locale ou appartient à l'instance de la classe. Mais de là à laisser le 'self' comme premier paramètre d'une méthode, c'est un peu gros :).
mais je trouve que le code ruby est rempli de hiéroglyphes qui ne me parlent pas du tout au premier abord ... et ne me donnent pas envi ...
Pour les 'hiéroglyphes', j'aimerais bien des exemples !
maintenant, tout ça est subjectif ... chacun ses gouts et ses couleurs (heureusement)
Ah, je suis enfin d'accord avec toi :). Mais je me suis permis de te répondre car je trouvais ton post un peu trop trollesque.
moi je choisi pas le langage en fonction de ses qualités intrasecs, mais en fonction de ce qui va m'apporter ...
Ah, pour moi les qualités intrasecs d'un langage jouent beaucoup sur ce qu'il va m'apporter. Le pouvoir d'expression d'un langage est pour moi très important, j'ai horreur de passer 2 heures pour trouver une façon d'avoir une fonctionnalité non incluses dans un langage (genre surcharges des classes de bases, modification à l'exécution de code des classes ...).
et en python, au niveau libs, c bien simple, tu peux tout faire dans tous les domaines ...
Tu serais surpris de voir le nombre de libs disponibles en Ruby, même si ces dernières sont actuellement dispatchées et manque de suivies (vive RubyGems).
au niveau ouverture, tu peux faire des classes java, tout comme des classes dot.net ....
C'est aussi possible pour Java en Ruby en utilisant JRuby http://jruby.sourceforge.net/(...) .
que demander de plus ? non ?
Personnelement, je demanderais à Python de devenir vraiment objet, d'inclure les itérateurs à la manière de SmallTalk ... il semblerait que les dernières version de Python répondent à certaines de ces attentes ... hélas j'ai depuis longtemps trouvé un langage réalisant déjà cela : Ruby.
Bref, Python et Ruby, ça n'est pas pareil, et c'est un peu idiot de les comparer même s'ils ont la même cible. Tu préféres Python, je préfére Ruby, chacun à ces raisons, mais j'ai au moins l'avantage d'avoir essayé pas mal des langages de script (je fais aussi du Python de temps en temps) avant de donner mon avis.
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 2.
> c'est un peu gros :).
au même titre que le self devant une variable t'indique que c'est un membre ...
le self dans le prototype de la méthode t'indique que c'est une méthode d'une instance (et non une méthode de class ou une méthode static)
C'est kif kif ...
C'est juste pour info ... pas pour relancer quoi que ce soit ...
[^] # Re: Différence avec Python ?
Posté par pifou . Évalué à 2.
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 3.
bon déjà les $ et @
mais je viens de faire un urpmi ruby, et je suis un tuto tout en codant un peu (et j'avoue qu'il y a des trucs qui me plaisent)
il y a aussi les "!" et "?" derrière des méthodes
je crois que ruby fait aussi de la "list comprehension" ...
en python par exemple : l =[i*2 for i in liste if i>10]
même le gars qui en a jamais fais, comprendra qu'on refait une liste des éléments plus grand que 10 en les multipliant par 2
je n'arrive plus à mettre la main sur l'équivalent ruby, que je trouve imbittable ... certes plus court, mais qui ne parle pas à un mec java/c#/c++ ...
bon je retourne dans mon ".rb"
[^] # Re: Différence avec Python ?
Posté par Alex . Évalué à 2.
sinon je te laccorde le code python me parait également plus compréhensible sur une première lecture.
Mais bon je ne pense pas que tous ces petits éxemples permetent de se faire vraiment une idée sur le langage
[^] # Re: Différence avec Python ?
Posté par pifou . Évalué à 2.
puts (0..20).to_a.select{|i| i>10}.collect {|i| i*2}
Ça fait plus PetitParlé donc logiquement plus lisible : j'ai un Range de 0 à 20 que je transforme en tableau (to_a) dans lequel je cherche tous les éléments supérieur à 10 (select) sur lesquels j'applique (collect) l'opération multiplier par 2. L'avantage de cette façon de faire c'est qu'on enlève les 'nil' qu'on retrouve dans ton code (un collect retourne toujours un tableau de même taille qu'à l'entrée).
Pour en revenir au post au dessus de manatlan pour les @ et $, c'est une façon comme une autre de mettre en valeur les variables globales et les variables d'instance. Ça vaut bien le self, et en plus ça a l'avantage de différencier l'accès d'une variable d'instance d'une méthode ayant le même nom (genre si tu as mis un attr_reader sur ta variable toto, le self.toto appel la méthode et le @toto fait référence à l'objet, dans le fond ça ne change rien sauf si tu commences à avoir des attributs dérivés).
Pour l'histoire des '!' et '?', je trouve ça très clair, les méthodes finissant par '!' indique que tu modifies directement l'objet sur lequel tu appelles la méthode au lieu de renvoyer un nouvel objet modifié. Pour le '?' ça te permet d'un seul coup d'oeil de savoir que la méthode retourne un booléen, et je trouve que quand on lis 'toto.nil?' on se dit tout de suite (car on a l'habitude de prononcer les phrases finissant par '?' d'une façon intérogative) qu'on demande juste si toto vaut 'nil'.
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
(je pense que plus de dev sur terre viennent du monde c/pascal/cobol/basic que du monde perl/bash)
Euh .. je viens du monde C, pur et dur, et franchement j'ai jamais ete foutu de lire correctement et sans me prendre la tete ne serait-ce qu'un petit bout de Python ... Ce qui n'a pas ete le cas .../
IMHO c'est pas une question d'habitude .. Plus d'esthetisme personnel .
alors, si je devais mettre des "end" comme en vb un peu partout, ça me plairait pas du tout (je hais vb)... et trouverai également que ça pollue énormément le code ...
Ben pour moi c'est juste l'inverse .. L'idee que si jamais un gard se met a mettre des tabs, qui n'ont pas le meme nombre de characteres chez lui que chez moi, et que c'est ca qui va m'indiquer la logique me fait froid dans le dos
le cas du self : tu peux l'appeler "S" ou "_" au lieu de self, tu gagneras 3 caracs ... (par convention de programmation, self c mieux, evidemment)
Que tu l'appelles self, S ou machin ne change rien. Il ne sert a rien... sauf a ressembler a une approche object codee en C...
car le full OO, t'obliges à programmer en OO uniquement ! et ça je sais pas si c'est un avantage ... (en python, t'as le choix)
En Ruby aussi .. mais meme si tu definis ce qui te semble etre une fonction, c'est en fait une methode de la classe Object...
A savoir aussi : less class que tu definis sont des instances de la classe Class :)
encore un truc, je suis persuadé que je m'éclaterai plus en OO avec ruby avec python, c même certain ... mais je trouve que le code ruby est rempli de hiéroglyphes qui ne me parlent pas du tout au premier abord ... et ne me donnent pas envi ...
Quels hiéroglyphes ? Le @ ? Il n'apparait que raremement et vaut largement les __ de Python !
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 3.
ça troll, ça troll ...
vous avez repris mes phrases les plus secs ;-), et ressorti l'argumentation habituelle ...
Alors, continuons dans le troll un peu ...
le "full oo", c'est un peu le graal tant promis, et au final on se rends compte que ça ne réponds pas tout à fait au côté maintenance, lisibilité ... tout ce qu'avais fait miroité l'arrivé de l' OO ...
preuve en est, qu'on en est à l'AOP, pour s'adapter un peu mieux aux besoins réels ...
J'ai rien contre le tout objet ... mais quel programmeur a déjà réussi à faire un très beau model objet ... en tenant compte de la lisibilité, de la maintenabilité, des temps de réponses, et des ressources utilisés ?
pour réunir tous ces critères, en programmant full oo, c'est quand même balaise ...(generalement y a des compromis à faire ... non ?)
VOus trouverez plein d'urls sur le net qui vous expliqueront que le "full oo" est à éviter dans bien des cas ... ;-) (je vais me faire tuer là ;-)
J'adore l'objet, et comme je l'ai déjà dit, je pense très certainement que je m'éclaterai bien plus avec ruby qu'avec python ... c certain !
Chacun des gouts évidemment ... il est evident que le python possède une construction objet postérieure (le python est même plus vieux que le java !) ... Le guido, ses potes et les PEP ont quand même réussi à en faire qqchose de vraiment bien, et bien réfléchi (le mec de ruby ne cache d'ailleurs pas qu'il s'est très largement inspiré de python, et donc que ruby ne serait pas ce qu'il est sans python)
finissons les trolls ...
qu'est ce qui compte après tout ?, et je me répète encore, c'est ce que tu vas pouvoir faire avec ...
et en python, les libs il y en a pour tous les gouts et tous les domaines (TOUS) ...
je sais qu'en ruby il y en a aussi ...
pour tout dire, j'avais testé le python il y a 2 ans, et j'avais abandonné ...(je faisais du code avec tk, et ça ne me plaisait pas)
l'année d'après, il fallait que je trouve un langage de script multi plateforme, et capable de faire du gui, traiter des images, etc ...
et j'hésitais entre ruby et python ... j'ai finallement choisi python, (avec wxpython et pil pour commencer)
la syntaxe de ruby ne me convenait pas trop, et les libs (bien qu'il existait un ersatz de wxruby) étaient mal documentées, etc ...
du google avec python, et je trouvais tout ce dont j'avais besoin ...
après je suis allé plus loin avec python (du reseau avec twisted, du jeu avec pygame, du web avec mod_python/cherrypy, du dev de gui ultra simple avec pythoncard, et même des chutes d'objets avec vpython : très fun) ...(je projette d'essayer soya3d, moteur 3d en python)
(je ne parle même pas de toutes les petites libs qu'on trouve ici et là pour extraire/remettre les données du palm, extraire les tags de la soupe html, les sqlobject/xmlobject, extraire les exif ... etc ... (pk il y en a pour tous les gouts/besoins))
bref, rien ne me manque ... tout est dispo ...
certes ruby est jeune, et pas assez connu (et c dommage), par conséquent moins de libs (je doute qu'il existe un equivalent de twisted, vpython, peut être un pygame-ruby (apparemment rubl mais c tout jeune) ?
ruby a beau être plus objet, et "plus beau syntaxiquement" (attention subjectivité), tu finiras par plus coder pour piloter sdl, qu'un prog en pygame ... et je crois que c pareil dans tous les domaines ... (là je vais me faire incendier) ...
maintenant, arrêtons les trolls totalement ... chacun sa croix !
chacun son choix ! et vive la liberté de choix qu'on a !
et pour affuter mes arguments la prochaine fois, je vous promet de me mettre à ruby ...(vous me verrez dans les forums ruby)
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 2.
ça troll, ça troll ...
Nope. Je reponds juste avec mes arguments. Comme je l'ai dit c'est avant tout une histoire de gouts....
le "full oo", c'est un peu le graal tant promis, et au final on se rends compte que ça ne réponds pas tout à fait au côté maintenance, lisibilité ...
Je suis pas forcement pour le tout OO dans mon design (d'ailleurs je ne fais de l'objet que pour m'amuser... dans mon boulot, je fais un edsign oriente objet et j'implemente en C). Par contre ca me plait qu'un langage dit "a objet" soit coherent... Si tout n'est pas objet je ne trouve pas ca coherent...
ruby a beau être plus objet, et "plus beau syntaxiquement" (attention subjectivité), tu finiras par plus coder pour piloter sdl, qu'un prog en pygame ... et je crois que c pareil dans tous les domaines ... (là je vais me faire incendier) ...
Avant d'avoir ces extensions, Pyhton ne les avait pas ;)
Ce qui me plait avec Ruby c'est aussi sa communaute, et le fait que ca bouge pas mal ... Il suffit de regarder le bruit que commence a faire Ruby on Rails (www.rubyonrails.com) chez les dev d'appli web, et de voir que pas mal de dev Java commence a trouver tout cela interessant (http://www.vanderburg.org/Blog(...) et http://howardlewisship.com/blog/2005/01/playing-with-ruby.html(...) par exemple) ...
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 2.
evidemment, mais si j'ai choisi python, c justement parcqu'avec python j'ai tout ce qui faut pour faire tout ce que je veux, et tout ce dont j'ai besoin ...
c'est ce que je me tue à vous dire ...
c'est pas la beauté du langage, mais c tout ce qu'on peut faire avec qui me l'a fait choisir
et je n'ai jamais dit, bien au contraire, que je ne ferai jamais de ruby, si les libs suivent et que ça apporte un réel plus, je me tournerai vers ruby ....
concernant "ruby on rails", j'ai un peu regardé y a qques temps ...
son seul avantage, par rapport à python, c'est qu'il n'est pas noyé dans une masse énorme de framework pour le dev web ... C'est le seul ! et par conséquent, si tu veux faire du web en ruby, tu prends ça, et c tout ... et tu t'adaptes à leur logique ...
en python, tu vas passez 6 mois à tester tous les frameworks pour le dev web, et prendre celui qui te conviens ;-)
et dans les framework python, il y en a vraiment pour tous les gouts, toutes les approches ... c'est plus que perturbant ! je le conçois ! Mais c'est très interessant, car c générateur de beaucoup d'idées, qui seront reprises dans d'autres frameworks, d'autres langages ...
le système de templating de ruby/nails est, je trouve, "limite" (un peu à la quixote/python) ... mélange de code et d'html ...
Pour un graphiste (pas dev pour un sous), ça va pas trop lui parler, voire le perturber ... je préfère les systèmes de balisage par attribut ou par balise ...
mais bon j'ai pas fait le tour, il y a certainement un moyen d'utiliser d'autres logique de template (celui de l'apache foundation est interessant, je trouve) (voir le coder ;-)
sinon on trouve aussi des urls de java addict qui sont interessés par des frameworks web pour python ;-)
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
son seul avantage, par rapport à python, c'est qu'il n'est pas noyé dans une masse énorme de framework pour le dev web ... C'est le seul ! et par conséquent, si tu veux faire du web en ruby, tu prends ça, et c tout ... et tu t'adaptes à leur logique ...
Ben non ce n'est pas le seul ... La seule difference c'est la productivite obtenue ... Regarde a nouveau la video de 10 minutes sur comment faire un blog (c'est juste un exemple) ...
Si Rails n'etait pas aussi novateur penses-tu que la communaute Java se mettrait a essayer d'implementer un 'Java on Rails' ?
sinon on trouve aussi des urls de java addict qui sont interessés par des frameworks web pour python ;-)
Sans doute mais ces edrnieres semaines, c'est surtout des gens qui se tournent vers le couple Ruby / Ruby on Rails ;)
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 2.
Pas mal effectivement ... mais rien de bien épatant ...
C'est vraiment un framework avec beaucoup d'objets à hériter ... et qui a pas l'air très rigide ...
(Un gars sous VS.net avec les assistants pour l'asp.net devrait réussir à faire un peu prêt la même chose dans les mêmes temps (sauf l'installe de dot.net / vs.net qui est énorme ;-), et genera un code pourri, ça je l'accorde aussi ;-)
Et j'ai vraiment l'impression que ça a les mêmes travers que "l'asp.net" ... à savoir, tant que tu suis le droit chemin (imposé ici par la conception objet), tu t'en sortiras ... mais dès que tu veux sortir un peu des sentiers battus : c'est un peu la galère ...
(mais bon, c'est le propre des frameworks qqpart)
C'est toujours le même problème récurrent avec ces "produits tout fait" ...
maintenant il est évident que je préfèrerai faire du rubyOnNails que de l'asp.net, pour 1001 raisons !!!!
maintenant, pour revenir sur le sujet "python différences"
le binding des urls page/params sur les class/méthodes/arguments, tu l'as déjà dans pas mal de framework python (et autres) ... cherrypy2 serai mon choix (car il impose très peu de choses)
le binding sur la bdd, je le ferai avec SQLObject ...
on arrive déjà à qqchose qui ressemblerait pas mal ...
comme j'expliquais avant, et comme je l'ai vu sur la video, les templates de RoN ne sont pas fait pour des graphistes (vu le code ruby que j'ai vu dedans, ça fait peur ... ça s'adresse clairement aux informaticiens) ...
je choisirai le moteur de template cheetah/python (pour avoir un beau balisage qui ne perturbera pas le graphiste dans son dev)
je monte qques classes pour encapsuler sqlobject/cheetah dans cherrypy (et qques balises pour controller les )... et """j'ai quasiment la même chose ... en plus souple""" (en étant le dev du binz je le connaitrai bien, il sera multibdd, avec des templates puissants, et pourra tourner indifféremment sous apache/iis ... en cgi, comme en mod_python ... ou alors avec le httpserver embedded de python)
Là où rubyOnNail fait très très très fort ! C'est la vidéo ! Il est évident que ça peut en jetter pas mal (surtout pour des devs web java ;-), php ou asp.net)
La communication sur un truc comme ça, c'est déjà 80% de fait !!! Et ça, c énorme !!!! Je comprends maintenant pourquoi on en parle temps !
Là où dans python, on se bat avec une 30aine de framework, qui communique "mal" sur leurs features ! ça fait mal !
EN tout cas ! bravo ! excellente vidéo qui présente bien la puissance du produit ! et la simplicité d'utilisation et d'installation !
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
(Un gars sous VS.net avec les assistants pour l'asp.net devrait réussir à faire un peu prêt la même chose dans les mêmes temps (sauf l'installe de dot.net / vs.net qui est énorme ;-), et genera un code pourri, ça je l'accorde aussi ;-)
Je suis pas sur que .NET puisse faire aussi simple ... Un des grands avantages de Ruby (et sans doute de Python je pense) dans ce cas est la generation a la volee des classes, ainsi que l'ajout de methodes par objet. ... Avec Ruby On Rails pas la peine de redemarrer ton appli, les changements fait dans le code sont pris a la volee...
Et j'ai vraiment l'impression que ça a les mêmes travers que "l'asp.net" ... à savoir, tant que tu suis le droit chemin (imposé ici par la conception objet), tu t'en sortiras ... mais dès que tu veux sortir un peu des sentiers battus : c'est un peu la galère ...
(mais bon, c'est le propre des frameworks qqpart)
Je pense pas que l'on soit aussi coince .. Il y a qq conventions a respecter (mais apparamment d'apres ce que j'ai lu de certains utilisateurs ca n'est pas 100% obligatoires ... et ces memes utilisateurs apres etre sortis des chemins battus se sont remis a suivre la convention trouvant qu'elle avait un sens ..)
le binding sur la bdd, je le ferai avec SQLObject ...
Ben la tu choisis ... Par defaut ce sont les bindings SQLRuby, mais tu peux aussi utiliser Postgres, Oracle, SQL Lite ...
comme j'expliquais avant, et comme je l'ai vu sur la video, les templates de RoN ne sont pas fait pour des graphistes (vu le code ruby que j'ai vu dedans, ça fait peur ... ça s'adresse clairement aux informaticiens) ...
Ben c'est du rhtml .. Comparable a du JSP ou autre "embedded" ...
(en étant le dev du binz je le connaitrai bien, il sera multibdd, avec des templates puissants, et pourra tourner indifféremment sous apache/iis ... en cgi, comme en mod_python ... ou alors avec le httpserver embedded de python)
L'interet c'est que justement d'autres devs le trouvent facile : http://43things.com/entries/view/562(...)
Mais si c'est aussi facile en Python pourquoi ne pas le faire ?
Là où rubyOnNail fait très très très fort ! C'est la vidéo ! Il est évident que ça peut en jetter pas mal (surtout pour des devs web java ;-), php ou asp.net)
La communication sur un truc comme ça, c'est déjà 80% de fait !!! Et ça, c énorme !!!! Je comprends maintenant pourquoi on en parle temps !
La ou son auteur fait fort c'est aussi sur le temps qu'il passe dessus .... Il est extremement reactif et tres productif
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 2.
sqlobject, ce n'est pas des simples api d'accès à une bdd ...
c'est une sorte de mappage de base de données en class python ...
une table est une classe ..., les attributs sont les champs
ajouter/supprimer/modifier des données de la base ne s'écrit qu'en python (on ne voit/touche pas le sql émis)
du coup tu peux manipuler n'importe quel bdd derrière (mysql, postgre, oracle ...) sans rien y connaitre au sql ...
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 2.
Je pense aussi, mais je ne connais pas bien zope, qu'on a des comportements similaires ... ajout d'une donnée dans la bdd, et hop : la zone se rajoute dans la page, avec les controles qui vont bien ... (à confirmer)
maintenant, le prob de python, c'est qu'il existe une foultitude de frameworks, au différences subtiles ... noyant le quidam dans une masse d'informations ... et ça n'aide pas à choisir le meilleur ...
C'est le grand problème (il y a plein d'urls qui expliquent ça)
Et aucun de ces frameworks ne se met en avant avec des vidéos à l'appui ...
Cependant, comme j'expliquais, avec qques choix stratégiques dans les libs dispos, tu devrais réussir à faire qqchose de similaires !
Mais je l'accorde, ce sera du boulot, ne serait ce que choisir les composants qui vont bien ...
Et du coup, face à un produit tout fait, clé-en-main .... ça n'a que très peu de chance ...
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 2.
il y a des pythoneux qui wiki'ise ici : http://wiki.rubyonrails.com/rails/show/PythonOnRails(...)
et qui cherche à monter l'idem en python ...
et il se baserait sur cheetah+sqlobject ... (c'était aussi mon avis ;-)
Et il y a aussi un rubien qui dit qu'ils ne devraient pas se lancer là dedans, et laisser une chance à ruby d'avoir sa killerapp ;-)
Mais les rubistes, ne vous inquietez pas trop ... la vidéo python ne verra jamais le jour ;-)
[^] # Re: Différence avec Python ?
Posté par pifou . Évalué à 1.
J'ai commencé l'informatique en apprenant l'UML et Java (et Perl) (en 1998 il me semble), mais déjà à l'époque on voyait les limitations de ces langages mais c'était déjà mieux que le bon codage pourri qui était encore de mise dans pas mal de boite d'informatique (méthodologie, structuration, maintenabilité ? on ne construit pas des voitures ici on fait du code !). Le problème, c'est que le premier langage objet à rentré dans l'industrie c'était Java et qui 7 plus tard commence à combler les manques qu'il pouvait avoir par rapport à des langages comme SmallTalk (début des années 80). Évidemment, Sun & co on fait de la pub sur la force de Java sur la notion de réutilisabilité, de maintenabilité, d'intéropérabilité qu'apportait leur langage ... mais c'était avant tout de la pub !
Le problème de l'informatique c'est la synergie des entreprises toujours frileuses à changer de technologie, finalement je défend Java car il a permis de faire évoluer les entreprises. Si tu veux découvrir la prochaine révolution niveau notion de programmation fait un petit tour sur les sites des laboratoires de recherche en génie logiciel, pour ma part la programmation orienté aspect ne me convainc pas plus que ça.
Enfin, pour ce qui est des librairies, j'ai eu exactement la même reflexion que toi, sauf qu'à mon époque c'était Perl qui détendait le maximum de fonctionnalités. Après mettre cassé la tête pour faire de l'objet sur ce langage, je suis passé à Ruby. Et vu l'évolution de ce langage, je pense que le retard par rapport à Python sera vite comblé. On est actuellement à la phase adaptation des librairies natives comme SDL, OpenGL ... arrivera ensuite les librairies plus haut niveau (comme pygame). Entre temps, l'interpréteur Ruby aura gagné en rapidité (utilisation de Parrot ?) et pourra enfin concurencer ses cousins interprétés :).
Bon, je m'arrete la, j'ai un peu pris plus de temps que j'avais prévu au début :)
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 2.
même si csharp est mieux pensé que java, car plus jeune, et qu'ils ont évité de refaire les erreurs de java ... il prendra le pas, si microsoft/longhorn percent ...
le problème qu'aura ruby, tout comme python, dans les entreprises ... c'est le passage du fortement typé au faiblement typé et très dynamique.
Accepter le fait d'avoir des erreurs à l'execution, que t'aurai pas pu avoir en compilant un fortement typé (erreurs catché à la compile)...
Les java/csharp addicts remontent en permanence ce genre d'arguments face à des python, ruby ou autres ... Ils veulent du "rock solid" !
D'ailleurs ... La communauté python (et guido) est en train de voir comment faire pour introduire un typage fort et optionnel dans python pour palier à "ces problèmes" (mêmes si les unittests restent le mieux, les dev des entreprises en sont pas très friands, et se repose sur les bons vouloirs de leurs compilos, ce n'est que mon avis)
t'auras beau venir avec des arguments, 5x moins de codes, développer 10x plus vite, maintenabilité accru (pour python ;-) ... ça compile pas ... et le dev de base aura des erreurs bêtes de type à l'execution, alors qu'il aurait pu les éviter s'il avait pu compilé ;-)
L'avantage de dot.net, c'est ça CLR, et le concept (tout comme parrot d'ailleurs) de pouvoir utiliser plusieurs langages pour generer des "exe" et s'interconnecter ...
Pour nous les devs, c'est vraiment sympa ... (faire ses dll dot.net en python pour les filer aux potes qui bosent en csharp, c sympa)
la clr v2 de crosoft sera d'ailleurs, un pas de plus vers les langages dynamiques, c confirmé chez microsoft ...(le mec derrière ironpython s'est d'ailleurs fait embaucher chez crosoft pour y travailler) ...
J'ai plus l'url, et c dommage, mais le centre de research de crosoft a pondu un langage dynamique (très proche de la syntaxe python d'ailleurs) ... mais rien ne dit si on le verra un jour ...
alors, pour qu'on puisse utiliser nos langages dynamiques qu'on aime, 1- il faudra que ça passe soit par la CLR/dot.net ...
2- il faudra adapter nos langages pour qu'ils puissent proposer ce côté
"rock solid"
3- ou alors, il faudrait que des super industriels poussent en avant ce genre de choses
Je crois au 1, car c'est dans les tuyaux ...(et ça risque de pousser encore l'adoption de dot.net ;-( ....)
le 2, ça peut aider ...
et le 3 : je ne vois pas qui ?
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 2.
regarder ce site, qui propose un même programme, dans 621 languages différents ...
il faudrait qu'un ruby'iste y refasse la version ruby ... car elle fait une 40aine de lignes, alors que la version python en fait 2 ...
une preuve que le full oo n'est pas toujours indispensable ;-)
http://www.99-bottles-of-beer.net//c.html#C#(...) (la plus belle ;-)
par contre, je suis persuadé qu'il y a moyen de raccourcir la version ruby au même niveau que la version python !
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
a,t="\n%s bottles of beer on the wall","\nTake one down, pass it around" 99.downto(0) {|i| puts((a%[i]*2)[0..-12]+t+a%[i-1==0 ? i-1 : 'No'])}Pour un autre fun : http://redhanded.hobix.com/bits/aFileSharingParagraph.html(...)[^] # Re: Différence avec Python ?
Posté par pifou . Évalué à 1.
a,t="\n%s bottles of beer on the wall", "\nTake one down, pass it aroud" 99.downto(1){|i|puts((a%[i]*2)[0..-12]+t+a%[i-1==0 ?'No':i-1])}[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
[^] # Re: Différence avec Python ?
Posté par Volnai . Évalué à 2.
vous avez repris mes phrases les plus secs ;-), et ressorti l'argumentation habituelle ...
Et toi tu devie. Le debut du "troll" c'etais juste de dire que le code python etait moins lisible que le code Ruby, pas de comparer les APIs pour voir qui à la plus grosse.
On le sait que Ruby est un language jeune par rapport à python, ca n'est pas le problème. On sait aussi que le full object n'est pas adapté à toutes les situation,on est pas idiot. Par contre tu garde la mauvaise fois de ne pas reconnaitre que le Ptyhon à des truc très très moche dans sa syntaxe, l'exemple utlime etant bien sur le "self", présent dans toutes les méthode, alors que objectivement, ca ne sert à rien du tout et c'est moche. Le python à plein d'avantages, son API est pas mal (même si on est à des années lumieres de perl et du cpan), mais pas celui de la lisibilité, surtout face à Ruby.
Par contre il eclate brainfuck à ce niveau http://esoteric.sange.fi/brainfuck/(...)
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
[^] # Re: Différence avec Python ?
Posté par applex . Évalué à 2.
Un peu comme si des mecs se prennaient la tête à savoir s'il est mieux de travailler sur du papier petits ou grands carreaux.
Et puis la syntaxe d'un langage ne vaut pas dire grand chose sur ses capacités ou son utilisation :) Il suffit de voir Lisp ou bien encore le langage C ;)
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
Non .. quand tu as la tete dedans toute la journee ca fait la difference...
Perso j'essaie d'avoir un code propre et lisible voir "artistique" .. Un truc dont je puisse etre fier.
Et puis la syntaxe d'un langage ne vaut pas dire grand chose sur ses capacités ou son utilisation :) Il suffit de voir Lisp ou bien encore le langage C ;)
Non .. mais tu preferes bosser avec un langage qui te plait ou que tu trouves illisible ? En plus Lisp est super beau :)
[^] # Re: Différence avec Python ?
Posté par applex . Évalué à 1.
Et python n'est pas illisible :) (sinon que dire du Perl ;) )
[^] # Re: Différence avec Python ?
Posté par reno . Évalué à 2.
Par contre la syntaxe du Lisp avec toutes les parentheses n'a pas franchement contribue a son succes.. D'ailleurs, il a peu de succes!
Donc tes exemples ne sont pas terrible..
[^] # Re: Différence avec Python ?
Posté par applex . Évalué à 1.
Fallait mieux lire.
J'ai écrit: "Et puis la syntaxe d'un langage ne vaut pas dire grand chose sur ses capacités ou son utilisation"
Ce n'est pas parceque le lisp est peu utilisé qu'il n'est pas puissant.
[^] # Re: Différence avec Python ?
Posté par Erwan . Évalué à 0.
Par contre, Python n'etait pas objet et ca a ete rajoute par la suite. C'est pour ca qu'on se retrouve avec un syntaxe qui (selon moi) est moche, et pas agreable a programmer.
Pour commenter l'exemple ci-dessus:
* Tous les "self" en Python montrent bien que la conception objet a ete rajoute apres.
* En Python il faut des _ pour les variable d'instance accessibles publiquement, et des __ pour les variables d'instance privees.
* En Puby il faut un @ pour les variables d'instance. Elles sont privees, il faut des methodes pour y acceder.
* Ruby cherche a avoir une syntaxe minimaliste, pour plus de lisibilite.
[^] # Re: Différence avec Python ?
Posté par Amand Tihon (site web personnel) . Évalué à 3.
« Pas du tout, efface » (tm).
Il ne faut rien de spécial pour avoir une variable d'instance (sauf le self. que certains excècrent).
En ce qui concerne les variables publiques vs. privées avec getter/setter, je préfère l'approche de Python (je ne parle pas des variables 100% privées).
On met les variables publiques, sans se faire chier à écrire les getters/setters. Si un jour la représentation interne change, on passe la variable privée (avec __) et on utilise des property, qui offrent en outre la possibilité de définir une méthode "del", et une chaîne doctype.
[^] # Re: Différence avec Python ?
Posté par Alex . Évalué à 2.
3.times{|toto| print toto}
=> 012
qu'on puisse redefinir le comportement de tous les objets :
3+2
=> 5
class Fixnum
def +(a)
self-a
end
end
3+2
=>1
c'est se qui était ressorti de différents troll que j'avais vu entre les 2 langages il y a quelques temps, ensuite les chose ont pu changer, ou on peut ne pas aimer, tout est affaire de gout. Dans tout les cas je ne pense pas que ces petits exemples puisse vraiment permettre de comparer 2 langages. Il faudrait plutot des projets plus important, mais je n'en ai pas vraiment vu en ruby.
Python a de plus l'avantage de l'ancienneté, on trouve donc plus de lib, de bindings, d'applis ou d'utils (JIT...)
[^] # Euh, on complique Python à loisir?
Posté par Richard Van Den Boom . Évalué à 3.
def width(self):
return self.__width
def height(self):
return self.__height
Tu peux en effet avoir les valeurs des variables de ton objet sans avoir à créer une fonction spécifique.
Enlève aussi les trucs superflus (les __ dans les variables) qui compliquent le visuel inutilement et ça donne :
class Rectangle:
def __init__(self, w, h):
self.width, self.height = w, h
def __cmp__(self, o):
return cmp([self.width, self.height],[o.width, o.height])
Moi, je trouve cela plus lisible. Gouts et couleurs, je suppose.
Richard
PS : Les espaces et tabs sont dégagés quand je poste, donc mes exemples ci-dessus ne sont pas justes mais bon....
[^] # Re: Euh, on complique Python à loisir?
Posté par Alex . Évalué à 2.
En fait ruby fait pareil, mais dans les cas aussi simple il suffit d'écrire attr_reader :with :height; ce qui en réalité définit 2 méthodes servant à lire la variable.
Pour les __ devant le nom des varaibles, je pense qu'ils sont ici pour définir des variables d'instance, ruby lui utilise le @.
Ensuite tout est affaire de gout
[^] # Re: Euh, on complique Python à loisir?
Posté par Sebastien . Évalué à 1.
"Privee" parce qu'on peut quand meme y acceder a l'exterieur de la classe (en tout cas en python 2.3) mais que c'est "mal" (au sens croiser les faisceaux dans Ghostbusters) : c'est pour dire au programmeur-client de la bibliotheque qu'il ne devrait pas acceder directement a cette variable.
[^] # Re: Euh, on complique Python à loisir?
Posté par Richard Van Den Boom . Évalué à 1.
Deux remarques : comme dit plus haut, pas besoin du __ pour instancier une variable, il suffit du "self." et de lui attribuer une valeur. Pour la question des valeurs de variables non modifiables, je comprends. Je les passerai plutôt en tuple en ce qui me concerne, mais je ne suis pas un bon programmeur. :-)
Richard
[^] # Re: Euh, on complique Python à loisir?
Posté par Frederick Ros . Évalué à 2.
Par exemple si l'envie me prend de changer la represenattion interne de la width au profit d'une table de hash (ca ne sert a rien just pour l'exemple), en faisant changeant juste l'implementation de ta methode width tu renvoie tj qq chose de coherent (une taille), alors que si tu n'as pas cette methode tu renverra la variable width .. qui est maintenant un hash.
Resultat: ca aura des effets de bors sur le code qui utilise ta classe... Il y a fort a parier que l'expression 5+ carre.width n'aura pas le meme comportement si width est un entier ou un hash ....
Dans le code expose en Ruby c'est fait par la ligne attr_reader :width, :height, qui cree 2 fonctions repondant au message width et height.
Du coup si tu as besoin de faire du refactoring de ta classe tu n'impact personne ....
[^] # Re: Euh, on complique Python à loisir?
Posté par Amand Tihon (site web personnel) . Évalué à 1.
Et puis je me suis dit que de toute manière ça n'avait que peu d'importance. Python et Ruby font à peu près pareil, mais avec une syntaxe et une vision des choses fort différentes, c'est tout.
Par contre, grand amoureux de ce langage, ce que je reproche le plus à Python, c'est de ne pas pouvoir modifier les types builtin, comme ça semble possible en Ruby (voir un exemple plus haut). Bien sûr, on peut en hériter, mais ce n'est pas pareil.
Je n'ai plus d'exemple en tête, mais je sais qu'il y a déjà eu un cas où j'aurais été très content de pouvoir ajouter une méthode au type str.
[^] # Re: Euh, on complique Python à loisir?
Posté par reno . Évalué à 2.
Pour ce qui est de pouvoir quasiment tout modifier en Ruby, j'imagine en effet que dans certains cas ça doit être pratique (mais dangeureux bien sûr), cependant je pense aussi qu'il doit y avoir un cout en performance, donc ce n'est pas gratuit! Ceci dit quand on cherche la performance avec Python ou Ruby, le C revient alors..
[^] # OK, merci.
Posté par Richard Van Den Boom . Évalué à -1.
[^] # Re: OK, merci.
Posté par Frederick Ros . Évalué à 1.
[^] # Re: Euh, on complique Python à loisir?
Posté par tgl . Évalué à 2.
(<disclaimer> mais ma connaissance de python est très empirique, donc limitée : j'en fait régulièrement, mais j'ai appris sur le tas et j'ai jamais lu de doc autre que celle des libs, donc il y a sûrement des trucs qui m'ont échapé</disclaimer>)
[^] # Re: Euh, on complique Python à loisir?
Posté par Richard Van Den Boom . Évalué à 1.
self.dimensions = (width,height)
Et voila, tu as l'ensemble des dimensions en read-only.
Richard
[^] # Re: Euh, on complique Python à loisir?
Posté par Frederick Ros . Évalué à 1.
[^] # Re: Différence avec Python ?
Posté par pifou . Évalué à 2.
class Array def inject(n) each { |value| n = yield(n, value) } return n end def sum inject(0) { |n, value| n + value } end def mult inject(1) { |n, value| n * value } end end puts [1, 20, 5, 7].sum # 33 puts [1, 20, 5, 7].mult # 700 puts (1..10).to_a.sum # 55 puts (1..10).to_a.mult # 3 628 800 = 10!Ce n'est pas grand chose mais c'est toujours agréable d'avoir une si grande liberté d'expression dans un langage interprété. Un autre exemple sympa, c'est la possibilité de récupéré les messages non compris par une classe (method_missing) :require 'singleton' class Roman include Singleton @@values= {" "=>0, "I"=>1, "V"=>5, "X"=>10, "L"=>50, "C"=>100, "D"=>500, "M"=>1000} def romanToInt(str) result=0; str+=" "; flag=0 (0..str.size-2).each do |i| if flag==1 then flag=0 next end if @@values[str[i+1,1]]>@@values[str[i,1]] then result+=@@values[str[i+1,1]]-@@values[str[i,1]] flag=1 else result+=@@values[str[i,1]] end end return result end def method_missing(methId) str = methId.id2name romanToInt(str.upcase) end end puts Roman.instance.DCCCLXXXVIII # 888 puts Roman.instance.MMII # 2002 puts Roman.instance.MDXV # 1515 puts Roman.instance.MCMLXXV # 1975 puts Roman.instance.LXXXVIII # 88 puts Roman.instance.MMMCMXCIX # 3999 puts Roman.instance.MMMDDDCCCLLLVVVIII # 4968J'ai écris le code 'romanToInt' vite fait, y'a surement moyen de faire beaucoup mieux niveau lisibilité. Après, je ne connais pas assez Python pour faire une comparaison objective, mais personnelement j'ai tout de suite accroché à Ruby alors que je rechigne toujours à modifier du code Python :/.[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
[^] # Re: Différence avec Python ?
Posté par pifou . Évalué à 2.
Bref, je laisse toujours la redéfinition de 'inject' dans mon code histoire que ça marche aussi avec les versions antérieurs de Ruby.
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 2.
> c'est la possibilité de récupéré les messages non compris
> par une classe
tu peux aussi le faire en python
[^] # Re: Différence avec Python ?
Posté par Erwan . Évalué à 2.
Ruby s'appelle comme ca parce que Perl avait deja un nom de pierre precieuse.
Interview de Matz:
http://www.artima.com/intv/ruby.html(...)
Stewart: What bits of Perl did you incorporate in Ruby?
Matz: A lot. Ruby's class library is an object-oriented reorganization of Perl functionality--plus some Smalltalk and Lisp stuff. I used too much I guess. I shouldn't have inherited $_, $&, and the other, ugly style variables.
Stewart: How about Python? What aspects of that language did you try to reuse in Ruby?
Matz: Far less than Perl. But I stole a few things, like exception names. Plus I learned a lot from its code.
[^] # Re: Différence avec Python ?
Posté par Alex . Évalué à 1.
[^] # Re: Différence avec Python ?
Posté par reno . Évalué à 2.
Python et Ruby sont vraiment tres similaire je trouve (surtout maintenant que Python s'est encore plus objectifié avec les itérateurs, etc).
La syntaxe de Ruby s'inspire un peu de celle de Perl certes (en *beaucoup* plus propre quand même!), mais (à mon avis) ils ont moins en commun: le Perl objet, euh je ne dirais pas ce que j'en pense: ce ne serait pas poli!
[^] # Re: Différence avec Python ?
Posté par Erwan . Évalué à 1.
[^] # Re: Différence avec Python ?
Posté par pifou . Évalué à 1.
Pour ce que est de Perl, on retrouve quelques points commun (variables spéciales, opérateur =~ pour l'application des regexp ...) mais ce n'est pas tellement énorme non plus. On pourrait tout aussi bien dire que la syntaxe de Ruby s'inspire de Pascal, Eiffel, Java ... sans vraiment être convaincu.
Pour conclure, je dirais que la syntaxe de Ruby est assez différente de celle des autres langages pour éviter de faire des raccourcis foireux :). En englobant les fonctionnalités et la syntaxe du langage je reste convaincu que la meilleur définition de Ruby est "un mélange heureux de Perl et de SmallTalk", ce n'est pas pour autant qu'on peut dire qu'il ressemble plus à un de ces 2 langages au niveau syntaxe (personnelement quand je code en Ruby ça ressemble plus a du SmallTalk, mais c'est évident que d'autre personne code plus à la façon Perl/C).
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 2.
j'ai un peu taté le ruby, grace à ces posts trollesques ...
et j'avoue que ça m'a bien plue, et je m'y attendais
Il y a plein de petits trucs qui rendent le codage sympa ...
Il y a beaucoup de travers de python, qui sont dues à l'apport de la couche OO bien postérieure à la création du langage ...
Disons que les bases sont très bonnes ...
cependant, on ne m'otera pas l'idée que ça reste moins lisible que du python ...
Il y a plein de raccourcis avec des hieroglyphes (@,$,|,&,!,?,<=> ...) qui apportent de superbes fonctionnalitées (j'adore le concept du bang!)
Mais qui rendent alors la lecture bien complexe pour un programmeur ne connaissant pas le perl/ruby/bash/smalltalk (qui sont des langages bien connu comme étant bien bruités) (comprendre : sans avoir la moindre idée de ce que fait ces hiéroglyphes, il n'est pas possible de comprendre le code (pour les dev c/c++/java/c#/basic/pascal)
Là, où le python, et c'est un postulat de base en python, se refuse d'introduire des raccourcis non lisible ... (guido refuse catégoriquement, par exemple, l'introduction d'un ( .. ? ..: ..), ou l'apport d'un bang! ...)
Tout ça pour garder le python lisible ... (au détriment de superbes fonctionnalités par raccourcis/features du langage)
(pour ne pas faire comme perl ! et ils ont raisons)
Certes l'exemple avec le carré/rectangle n'est peut être pas parlant sur les réels différences python/ruby ... (déjà en python, il y avait bien plus simple) ... ça reste un exemple très basique, un cas d'école
En python, il n'y a pas de hieroglyphe, il y a certes le "__", mais c'est des règles de codages que j'applique même maintenant en c#, pour la lisibilité .... et le coup du self, qui a des "raisons d'être" ancestrales ... même si ça apporte un qqconque bruit pour certains, ça a l'avantage de parler à tout le monde ....
Après, il est vrai que c'est une question d'habitude ... si tu connais tous les hiéroglyphes, et la structure du ruby/smalltalk/perl ... le ruby sera certainement plus lisible que le python (trop textuel au gout de certain)
La seule chose qui m'embête un peu dans tout ça ... c'est que python est à 2 doigts d'être reconnu dans le monde de l'entreprise ...(en éclipsant perl ...)
Et que la communauté du libre/language/"underground" se divise un peu, en pronnant 2 modèles de langages dynamiques ... un python déjà bien rodé et quasi prêt, et un ruby (certes mieux pensé) qui fait revenir un peu perl sur le devant de la scène ...
Bon ok, il y a encore une énorme marge entre python et ruby, question avancement ...
Parrot aurait été le bien venu pour réunir enfin python/perl/ruby ... mais j'ai l'impression que c'est limite vaporware ...
Et le mec de perl(dan) s'est pris la tarte à la crème de guido pk il n'avait pas réussi à faire tourner une implémentation python dans parrot, plus rapide que la cpython, comme il l'avait promis de faire en moins d'un an ... (bon, c'est une question de temps ok)
Il y a de la place pour ruby et python (même si je persiste à dire que je crois bien plus en python (guido et sa communauté est en train de voir/penser pour rajouter un typage fort dans python, le seul truc qui lui manquerait face à un java/c#), et il est fort probable qu'un python# soit dans la clr2 de dot.net) ...
Le monde des languages est rempli de superbes languages morts-nés. Il n'y a pas que les "features du langage", il y a aussi ses libs, la communauté et le marketing ...
(le cas de php est flagrant, au niveau langage, c'est limite nulle ... le OO avant la v5 est plus que catastrophique, et ses libs (bien que très nombreuses, et couvrant tous les besoins) sont vraiment mal golés ... et pourtant il est partout de nos jours (remplaçant bien des javas) ...)
et pour troller un peu :
(dans le cadre des entreprises) Ruby n'apporte pas grand chose sur python ... alors que python apporte énorme sur perl/php ou autres ...
bien que ruby soit un peu mieux golé que python ...
[^] # Re: Différence avec Python ?
Posté par Alex . Évalué à 1.
Moi je trouve qu'il est déjà reconnu, grace a des produits comme zope et prelude.
Et il est évidant que ruby est encore bien jeune, manque de lib (comparé a python ou a perl) et de killer apps. Néanmoins on commence a voir une communauté se créer autours de ruby (bon daccord, cest surtout dans la recherche, mais ça vient, voir http://www.rubygarden.org/ruby?RealWorldRuby(...) pour des exemples concrets)
Sinon on commence tout de même a trouver quelques applis/libs/framework sympathiques, tel rails, soap4r, ... c'est le temps qu'une commuanuté se mette en place.
Par contre j'entends beaucoup parler de smalltalk, j'avais voulu essayer mais avait été un peu rebuté par les if qui sont des méthodes et cie... ça vaut vraiment ls coup de s'y mettre ? Ya des bons tutos ? (je viens d'installer squeak... ça a l'air sympathique, en tout cas le framework de base a l'air complet, mais l'environnement est plutot... flashy)
[^] # Re: Différence avec Python ?
Posté par Frederick Ros . Évalué à 1.
Pas d''accord .... Les raccourcis (genre variable a la Perl) sont fortement deconseilles et deviennent deprecated les uns a pres les autres. Le concept du ! est une convention, pas une feature...
Là, où le python, et c'est un postulat de base en python, se refuse d'introduire des raccourcis non lisible ... (guido refuse catégoriquement, par exemple, l'introduction d'un ( .. ? ..: ..), ou l'apport d'un bang! ...)
Je vois pas en quoi l'ajout d'un ? en fin de predicat enleve a l'expressivite .. Je dirais que ca rajoute du sens a mon avis ... Les rares fois ou j'ai regarde python, ce que l'on m'a mis en avant est le "Il n'y a qu'une facon de le faire" (par opposition au 'Il y a plusieurs facon de le faire' de Perl) .. J'aime pas trop ce cote ...
Parrot aurait été le bien venu pour réunir enfin python/perl/ruby ... mais j'ai l'impression que c'est limite vaporware ...
Non apparamment ca avance bien... Le codage de la VM Ruby (Rite) aussi apparamment .. Y'a un seul dev dessus mais il semblerait qu'il en soit a 80% ... le code (pas dans son integralite, certaines fonctionnalites ne sont pas encore implementees) tourne dessus avec un gain non-negligeable...
(dans le cadre des entreprises) Ruby n'apporte pas grand chose sur python ... alors que python apporte énorme sur perl/php ou autres ...
bien que ruby soit un peu mieux golé que python ...
Tu vois que tu t'y mets aussi ;) Si ca apporte .. Dans ma boite par exemple, jusqu'a present seul le Perl est authorise comme langage interprete. Certains utilisent (ou essaient) d'utiliser Python, mais ca n'a pas emballe les managers .. Par contre Ruby trouvent un meilleur echo (le coup des messages a bien plu par exemple)
[^] # Re: Différence avec Python ?
Posté par pifou . Évalué à 2.
cependant, on ne m'otera pas l'idée que ça reste moins lisible que du python ...
Il y a plein de raccourcis avec des hieroglyphes (@,$,|,&,!,?,<=> ...) qui apportent de superbes fonctionnalitées (j'adore le concept du bang!)
Mais qui rendent alors la lecture bien complexe pour un programmeur ne connaissant pas le perl/ruby/bash/smalltalk (qui sont des langages bien connu comme étant bien bruités) (comprendre : sans avoir la moindre idée de ce que fait ces hiéroglyphes, il n'est pas possible de comprendre le code (pour les dev c/c++/java/c#/basic/pascal)
C'est dommage qu'on ne puisse t'oter l'idée que Ruby est moins lisible que Python :). Prennons les 'hiéroglyphes' cités un par un :
@ : Ça désigne juste une variable d'instance, ce n'est pas pire que de mettre des self devant. Par contre ça devient un peu moche quand on accède au variable de classe @@ (ça me fait penser au __ de Python :)
$ : c'est une variable globale, il me semble, mais j'en met jamais dans mes programmes et c'est très limité dans les codes des librairies
| : Ah? ça n'existe pas le | dans Python, on ne peut pas faire d'opération sur les bits ? c'est un opérateurs utilisés dans la plupart des langages
& : pareil que pour |
? et ! : ne sont pas obligatoire, ça rajoute juste du sens, comme les __ dans Python à part que le '?' et '!' veulent déjà signifier qqchose dans le langage commun ce qui facilite leurs compréhensions
<=> On aurait pu mettre 'cmp' à la place, mais comme Ruby a pris le partie de surcharger les opérateurs arithmétique (+, -, *, % ...) je trouve ça plutôt cohérent.
Et encore tu as oublié de citer que les variables en majuscule sont considérée comme constante. En gros, en Ruby au lieu de juste donner des conventions de codage (majuscule pour les constantes, ajouter un '!' pour les "bang', un '?' pour les méthodes de type booléene) il prend en compte la syntaxe pour ajouter du sens (je parle bien de sémantique) au code.
Effectivement avant de lire du Ruby il faut connaître c'est quelques spécificités, mais c'est comme dans tous les langages.
Pour rappel tous ces 'hiéroglyphes' n'existent pas dans Perl/SmallTalk/Java et consort où n'ont pas du tout la même signification (genre en Perl $ désigne une variable scalaire, @ un tableau et % un hachage). Donc ça n'aide pas vraiment de connaître ces langages avant de faire du Ruby (au contraire). Ce que je ne comprends pas c'est qu'on puisse trouver que c'est un problème pour la lisibilité ! Le nombre de signes (3 importants : @, @@ et $) dont on doit apprendre la négligeable et la plupart du temps se comprend juste en lisant du code.
Je vais me répéter mais l'introduction des '!' et '?' facilitent grandement la compréhension d'un code. Après je comprend que les développeurs de Python refuse de les incorporer, ça les obligeraient à modifier toutes les libs existantes pour rendre tout le code cohérent ! Ça n'est pas envisageable comme pour le plupart des langages, ils sont obligés de garder le bagage des versions précédentes pour garder une compatibilité. Et c'est bien ce que je reproche à Python (ou Java), il essaye d'ajouter de nouvelles fonctionnalités dans un langage qui n'a pas était prévu pour dès le début. Du coup pour ne pas casser brutalement la compatibilité, on ajoute par petite touche les nouveautés en trouvant des astuces pour rester cohérent avec la syntaxe de départ (voir l'exemple du super en Python).
Pour le rapprochement avec Perl, je dirais que ça n'a rien à voir, le problème de Perl est de permettre d'écrire la même chose de 36000 façons différentes en utilisant des astuces abracabrantesques (surtout les variables magiques) qui rendent le code illisible pour qqun ne connaissant pas bien le langage. En Ruby on n'a pas ce problème, je me répéte, la seule chose qu'a garder Ruby par rapport à Perl c'est l'intégration des regexp dans la syntaxe du langage (=~) et les noms des variables globales ($0 représente le nom de ton programme en cours d'exécution par exemple), rien de plus. Alors bien sûr pour savoir ce que représente les variables $* il faut mieux connaître Bash/Perl ou alors prendre une doc expliquant ces variables :).
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 2.
ça je suis entièrement d'accord ! et c'est ce que je dis dans mes moults posts
> , mais c'est comme dans tous les langages.
ça je suis pas d'accord !
Les pythoneux se refusent d'ajouter de tels hiéroglyphes dans le langage python, non pas à cause de devoir refaire toutes les libs
mais uniquement, pk ça ne parlera pas à un novice (qui par conséquent ne connaitra pas ses hieroglyphes) !
Toute la philosophie python est justement là ! !! (et je crois sincèrement qu'ils ont raisons de faire ça ... de ne pas torturer le langage ... quand tu vois tous les remous qu'a causé l'ajout des décorateurs dans la 2.4 : tu comprends ! (les purs et dures voulaient même forker ;-) )
Avouer qu'un mec qui vient du c, du basic, ou du java ... comprendra le code python, sans trop d'efforts ... les mots clés sont identiques ... l'indentation ne pause pas de trouble ... il n'y a pas de hiéroglyphes inconnus (on retrouve les classiques != / ==) ... et le "self" laisse bien transparaître qu'on fait de l'objet dans une instance ...
Maintenant, les gars qui me disent le contraire, c'est qu'ils ont déjà fait du bash, du perl, du smalltalk ... et se doute que tel hieroglyphe doit servir à ça dans ce contexte précis ...
ils ont un bagage plus rare, plus poussé, que le dev de base du monde c/java/basic/cobol/php ...
that's all ...
[^] # Re: Différence avec Python ?
Posté par Volnai . Évalué à 4.
ça je suis pas d'accord !
Et bien tu es de mauvaise foie
En python, je n'avais pas deviné ce que voulais dire __.
En python, le fait d'avoir un paramétre self dans la définition de la méthode me perturbe (et franchement me laisse perplexe).
En python, l'indentation du code est cruciale, ce n'est pas non plus habituel.
En Ruby aussi il y à plein de truc qu'on ne comprends pas sans se renseigner un minimum, et en perl encore plus. C'est pareil dans tout les langages, ca ne s'invente pas.
D'ailleurs python n'a pas de "hiéroglyphes " et se refuse d'en ajouter, mais ils l'ont fait quand même avec les décorateurs (ah tiens, ca utilise des @ les décorateurs, curieux non ?).
C'est comme pour l'objet, c"est une fonctionnalité pensé après, du coup forcement c'est un peu moins propre que si c'étais une fonctionnalité de base du langage.
Avouer qu'un mec qui vient du c, du basic, ou du java ... comprendra le code python, sans trop d'efforts
peut être, ca reste à vérifier, toujours est-il que cela ne fait pas du code python un code plus propre et plus lisible (dans le sens "moins polué") qu'un code Ruby
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 2.
?!?
> En python, je n'avais pas deviné ce que voulais dire __
tu n'as jamais entendu parlé de convention de codage qui consiste à mettre un "_" devant une variable ou une methode, pour dire qu'elle est locale ?!??
si ça c pas de la mauvaise "foie" ?!? je sais plus ...
et quand il y a 2 "_" ... et bien, elle est super locale ... non ?!
> En python, le fait d'avoir un paramétre self dans la définition
> de la méthode me perturbe (et franchement me laisse perplexe).
et bien, tu fais avec ... comme moi je ferai avec les hieroglyphes en ruby !
> En python, l'indentation du code est cruciale, ce n'est pas
> non plus habituel.
et cette indentation t'empêcherait de bien lire le code ?!?
franchement, là tu trolls graves ou c'est une mauvaise "foie" absolu
(sinon pour l'indentation, j'y ai tellement pris coup que je ne conçois même plus devoir baliser mes blocks avec des {} ou des "end" dans les autres langages... ça me dépasse, et je trouve ça archaique, à l'epok où tout le monde indent son code ?!)
> (ah tiens, ca utilise des @ les décorateurs, curieux non ?).
et pour le coup des décorateurs ... tu n'es pas sans savoir que ça a été la grosse polémique de fin 2004 dans le monde python ...
et que beaucoup de pur et dur voulait même "forker" ;-), pk ça dénaturait le langage ...
moi je suis totalement pour, mais il est vrai que la syntaxe ne me plait pas non plus ... un @ ... on croirait une variable d'instance de ruby ;-)
[^] # Re: Différence avec Python ?
Posté par Volnai . Évalué à 2.
Euh franchement...Non :)
A ma décharge, developper n'est pas mon metier (ce qui d'ailleurs je pense me donne plus de légitimité pour juger de la lisibilité d'un code), mais j'ai fait pas mal (meme beaucoup) de Java (jamais vu de _ dans une variable), de perl (ca a du arriver, mais ca ne m'a marquer comme une "convention") et visiblement en Ruby ce n'est pas le cas non plus. Peut être en C, bof ?
Qaunt a la définition de "super-locale"...
comme moi je ferai avec les hieroglyphes en ruby !
Si tu fait réference au @, il existe aussi en python. Et puis non, je n'ai pas pu ignorer les "self" en parametres. Je me suis dit "tient, on peut utiliser un mot réservé dans les paramétres de méthode ?". Et aprés je me suis dit, 'non c'est quand meme bizarre'. Et puis j'ai cherché pour enfin comprendre que c'etait vraiment le vrai "self" qui était là, dans les paramétres de méthode. Et ca désolé, même sans être developpeur professionel, c'est vraiment indéfendable, c'est le seul langage objet qui fait ca, ca ne sert à rien. A part à poluer le code.
et cette indentation t'empêcherait de bien lire le code ?!?
Non, c'est juste que quand on ne conait pas, ca surprend de ne pas voir de fin de bloc. Mais effectivement ce n'est pas un bon argument, c'est une bonne chose.
[^] # Re: Différence avec Python ?
Posté par pifou . Évalué à 2.
Faux, il y a aussi Perl :), comment ? tu parlais de langage objet ... ah je suis désolé :) mais j'aime vraiment troller ;).
Bref, moi pour mes développement persos je vais rester en Ruby, je suis sûr que d'ici peu de temps ça sera de base dans les distribs comme pour Perl à une époque (je me rappel encore de mettre #!/usr/local/bin/perl dans mes premiers scripts Perl :).
[^] # Re: Différence avec Python ?
Posté par Volnai . Évalué à 2.
[^] # Re: Différence avec Python ?
Posté par pifou . Évalué à 2.
Ah comme c'est bizarre :)
La première fois que j'ai regardé du code Python, j'ai me suis posé ces questions :
- où sont les 'new' pour la création d'objet ? réponse : il y en a pas tu appelles directement MaClasse(). C'est assez peu commun.
- la façon d'hérité d'une classe ne me parle pas du tout, je croyais que ça permettait de faire une sorte de Template à la C++ :).
- les ':' à chaque fin de if else while ... genre hyéroglyphe c'est pas mal sauf pour les gens qui ont fait du Bash :).
Je ne parle même pas de la manière d'avoir la liste des méthodes d'une classe ou même de faire référence à une méthode mére (super) ou mieux de faire de l'introspection (genre code illisible à coup de 'dir()', '__builtins__' et 'hasattr'). Comme tu le vois c'est assez facile d'être de mauvaise fois avec Python comme tu le fais avec Ruby :).
>Maintenant, les gars qui me disent le contraire, c'est qu'ils ont déjà fait du bash, du perl, du smalltalk ... et se doute que tel hieroglyphe doit servir à ça dans ce contexte précis
Je me répéte, 95% des hiéroglyphes de Ruby sont propre à Ruby (ils n'existent PAS d'équivalent ou ils ne signifient PAS DU TOUT la même chose dans les autres langages). Donc, d'avoir fait du SmallTalk avant te fera juste dire : "tiens on retrouve la même notion de bloc et d'itérateur" qui par ailleurs est très lisible (au moins autant que l'équivalent Python). Pour le Bash et Perl, ça permet juste de comprendre les variables $* qui sont assez identifiables et facilement accessible dans diverses docs. En gros, il a juste @ et @@ qui sont importants (tu peux très bien te passer des $*, c'est même conseiller, ils ne sont là que pour faire des petits scripts systèmes), et je ne vois pas ce que ça de pire que les __ de Python ?
Je dis juste, que comme tout nouveau langage il faut un temps d'adaptation. D'ailleurs je n'arrive toujours pas à m'habituer à Python, surement parce que je ne connais pas très bien la bibliothèque standard. Et je suis convaincu que c'est dans ce dernier point que l'on peut dire que l'on connait un langage ou non et s'il nous plait.
Je trouve que l'avantage de Ruby est de permettre beaucoup plus de liberté syntaxique et sémantique: tu peux tout modifier. Ça permet d'écrire des classes dont l'utilisation devient beaucoup plus clair; la surcharge des opérateurs, les mixins, les yield et autre fonctionnalités permettent un niveau d'abstration beaucoup plus important qu'en Python. Mais évidemment si c'est pour faire du scripting procédural (comme Perl) autant utiliser Python :).
Pour en revenir aux efforts à donner pour comprendre un langage, c'est assez difficile d'avoir une quantification objective, chaque informaticien à son bagage. Un gars n'ayant fait que du C/Bash/Perl (sans utiliser d'objets) aura de tout manière du mal à penser objet que ce soit en Ruby ou en Python. Pour quelqu'un venant du monde Java, il sera surement plus attiré par le coté tout objet de Ruby plutôt que de retrouver les même limitations dans Python (type primitif surtout).
De toute façon l'effort le plus important à fournir quand un apprend un langage c'est surtout ses bibliothèques et ses fonctionnalités intrinsèques (objet, héritage, introspection, surcharge d'opérateur/classe ...), que ce soit en C, Java, C# (.Net), Python, Ruby, Visual Basic, Php ...
Bref, on est plus que 3 à se battre sur ce troll qui ne restera surement pas dans les annales de LinuxFR. Le gros avantage de Python, c'est d'avoir pu permettre aux informaticiens effrayés par la POO (genre ceux n'ayant fait que du C avant) d'aborder cette notion doucement sans les brusquer (on ressent bien l'influence du C quand on code en Python je trouve, mais je peux me tromper) ... mais ça aurait été aussi possible avec Ruby si (mais je ne suis madame-soleil) ce dernier était sorti avant Python.
Pour moi Python est arrivé un peu trop tard, le jour ou j'ai voulu m'y mettre pour remplacer Perl par un langage de script Objet, Ruby pointait déjà le bout de son nez. Et tu pourras dire ce que tu veux, dans le style langage objet, Ruby est 10x fois puissant que Python (d'ailleur tu en es convaincu il me semble d'après tes dernières réponses).
[^] # Re: Différence avec Python ?
Posté par Volnai . Évalué à 2.
Bref, on est plus que 3 à se battre sur ce troll
Belle bataille, Soldat.
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 3.
seul ça me déplait encore, et je ne peux laisser passer ça:
> Ruby est 10x fois puissant que Python
les fonctionnalités intrinsèques d'un langage, ne t'en déplaise, ne SONT PAS IMPORTANTES !!! et ne font pas qu'un language soit adopté !!!!
Il est evident que ça fait plaisir au développeur de faire de l'art avec du code (et je suis un fan de l'art dans le code aussi !)
les cimetières sont remplis de superbes langages, avec des fonctionnalités de ouf, des logiques de programmation transcendantales, et une syntaxe magnifique ...
Mattez la réalité ! (et je me répète encore)
PHP en est le plus bel exemple ... la syntaxe est horrible et tordu, le côté OO est plus que naze, et les api sont truffés de fonctions aux formes bizarres ...
et pourtant, il est partout ...et pourquoi ? pas à cause de ses maigres "fonctionnalités intrinsèques du langage" ! ni à cause de son model objet hors normes ...
Que dire du C/c++/java/csharp ?! on peut faire quasiment le même topo ...
Mais tous possèdent des librairies pour faire quasiment tout, dans tous les domaines, et de milles façons différentes ...
maintenant à l'heure actuel dire que "ruby est 10x plus puissant que python" ... on délire totalement ?! non ?
les fonctionnalités intrinsèques au langage de ruby sont certainement mieux pensés que python (python est même plus vieux que java)...
Mais au niveau lib, dans la vraie vie, bin tu seras limité avec ruby, et tu feras avec les libs actuels ...
On est encore très loin de python dans ce domaine !!! (cf post : pygame, vpython, ..)
Un jour, ruby possèdera autant de lib mature ... mais pas avant 4/5 ans. Et quand on pourra tout faire avec ruby ... et bien je ferai du ruby, ça me pose aucun problème moi ;-)
donc dire que ruby est 10x que patati patata ... on nage dans le délire total ...
[^] # Re: Différence avec Python ?
Posté par pifou . Évalué à 2.
Bien sûr, il existe plein de bon langage super bien conçu que sont mort industriellement, je ne citerais que SmallTalk qui était trop nouveau pour son époque (et qui n'a pas été des mieux gérés niveau commercial (problème de licence d'utilisation))
> les fonctionnalités intrinsèques d'un langage, ne t'en déplaise, ne SONT PAS IMPORTANTES !!! et ne font pas qu'un language soit adopté !!!!
La dessus, je ne suis pas d'accord, l'avantage de Ruby par rapport à Python, c'est justement d'apporter ce petit plus par rapport aux autres langages. Je m'explique : pour les 3/4 des logiciels, actuellement on s'en fout de se genre de fonctionnalités, et d'ailleurs qu'on écrivent ces derniers en Python ou en Ruby le code se ressemblera surement au niveau structure. Par contre, pour le dernier quart, Ruby permet d'envisager d'autres méthodes de conception/codage n'étant pas accessible (ou difficilement ou encore par des méthodes assez moches) dans Python par exemple. Prennons l'exemple de RubyOnRails, je ne pas regardé le code, mais j'imagine que ça doit utiliser plein de fonctionnalité d'introspection, de surcharge etc. . Si une version PythonOnRails sort ça serait intéressant de comparer la lisibilité du code, mais dans les parties un peu chaude, j'ai peur que le code ressemble à une potion magique de fonctions aux noms étranges. Après, c'est sûr que de toute façon, pour utiliser ce genre de fonctionnalité il faut avoir une vue des langages assez abstraite, et que pour qqun qui n'a fait que du C ça devrait sembler assez incompréhensible (changer à la volée le code executé même si c'est possible en C, ce n'est pas très courant).
Pour résumer, ce que je trouve bien avec Ruby par rapport à Python, c'est qu'il a franchi une étape de plus vers l'abstraction des langages informatique (disons pour être plus cohérents qu'il rejoint SmallTalk sur ce point :). Ça permettra surement au gens qui essayent Ruby (comme toi il me semble) de découvrir des nouveaux paradigmes qu'ils ne sont pas obligé d'utiliser mais qui a coup sûr leurs permettrons de faire évoluer leur manière de coder. Et aujourd'hui on demande de plus en plus aux programmes de supporter des plugins, de modifier leurs comportements à la volée, de gérer la persistance de leurs données .... Tu vas me dire qu'ils existent des dizaines de framework qui permettent de fair ça en Python ... et je te réponderais que le problème des frameworks c'est leur rigidité (tu l'as dit toi même plus haut) et qu'au contraire apporter des fonctionnalités comme le propose Ruby permet au programmeur de réaliser ce genre de chose lui-même en un temps record (et qui de plus correspondera à ses besoins). Par exemple j'ai réaliser en moins d'une heure un système de cache d'information et stockage persistent d'objet complétement transparents (en utilisant le method_missing, et la serialisation. le client appele ça méthode normalement et la mise à jour des informations et leurs sauvegardes sont faites automatiquement). En Java (que je connais bien aussi) ça m'aurait surement pris plus de temps et m'aurait obligé à définir un nouveau protocole pour les appels clients.
Pour les librairies, plus la communauté Rubiste augmentera plus ça avancera vite, et pour ton délai de 4/5 ans je trouve assez méchant, il suffit de voir le temps qu'à mis Python à rattraper Perl dans ce domaine.
Bon on peux s'accorder sur le point suivant je pense : Python a 10x plus de librairies que Ruby, mais Ruby a 10x plus de puissance d'expression que Python ... le problème c'est que Python d'après ce que tu dis à propos de ses dév ne gagnera plus grand chose en pouvoir d'expression ... par contre Ruby ne peux qu'avoir des librairies en plus.
Enfin, je pense que si tout le monde se limitait à dire 'y'a pas assez de lib pour investir dans ce langage' (comme tu le dis pour Ruby), en serait toujours en train de coder en C en utilisant la Glib :). Et pour vraiment finir (promis), Ruby aura toujours moins de libs que Python (comme Python en aura moins que Perl) car tout simplement la commauté Ruby (comme celle de Python envers Perl) évitera de développer celles qui ont peu d'intérêt (la plupart du temps car une nouvelle lib a supplantée la version historique).
[^] # Re: Différence avec Python ?
Posté par manatlan (site web personnel) . Évalué à 2.
> il vaudrait mieux comparer Ruby a Perl. L'auteur de Ruby
> aimait Perl, il s'en est beaucoup inspire. Par contre il
> n'a jamais trop aime Python.
et pourtant il a récupéré de python beaucoup de bonnes idées, (et il le dit lui même)
[^] # Re: Différence avec Python ?
Posté par pifou . Évalué à 2.
Si Ruby était si ressemblant à un langage existant (genre Perl/Python), il n'y aurait pas de communauté autour et ce langage serait mort né comme beaucoup d'autres. S'il prend de l'ampleur c'est qu'il doit bien répondre à des exigences qu'on ne retrouvent pas dans les autres langages, ça me parraît évident.
Le problème en informatique comme je l'ai déjà dit c'est la lenteur d'évolution des moeurs des décideurs (et développeurs) envers les technologies. Microsoft (ou IBM, Sun ...) resortirait un SmallTalk like aujourd'hui et tout le monde (surtout les décideurs) crierait au génie, à la révolution de l'informatique ... c'est quand même con d'avoir attendu 20 ans pour s'en rendre compte. Tous les langages objets actuels tendent de plus en plus vers ce style de langage (introspection, itérateurs ...), l'avantage avec Ruby c'est d'avoir intégré dès ses premières versions ces fonctionnalités (et pas après coup comme en Php, Python ou Perl voire Java dans une certaine mesure).
Ce post n'est pas pour aller en contradiction avec ce que tu dis, il me semble même qu'on a à peu près la même vision (d'après ce que j'ai pu lire de tes posts) :).
# allez ...
Posté par manatlan (site web personnel) . Évalué à 2.
Je souhaiterai apprendre un peu le ruby, pour voir ...
J'ai configuré mon SciTE, et suis donc prêt ...
J'ai fait qques petits scripts avec "des class de pommes" ;-)
Connaissez vous un petit tuto du genre "dive into python" ?
ou qqchose d'aasez rapide, qui fait bien le tour du langage (pas des libs)
[^] # Re: allez ...
Posté par Alex . Évalué à 1.
[^] # Re: allez ...
Posté par Frederick Ros . Évalué à 1.
http://www.rubycentral.com/book/(...)
http://poignantguide.net/ruby/(...)
http://www.ruby-doc.org/docs/(...)
Et sinon, n'hesite pas a poster sur le newsgroup comp.lang.lang.ruby ... ou a m'envoyer un mail :)
[^] # Re: allez ...
Posté par manatlan (site web personnel) . Évalué à 2.
C'est assez bien pensé, (mais je suis très loin d'avoir fait le tour) ...
Par contre, je suis rassuré ...
On ne peut pas comparer ruby et python ... même s'ils ont qques particularités communes (langage de script, interprétés, dynamique et objet(avec un avantage certain pour ruby))
Ils ne jouent carrément pas dans la même cour ... mais alors pas du tout !
Même si le code suivant est très "human readable" :
exit unless "restaurant".include? "aura"
en très gros : on ne sort pas du "restaurant" à moins qu'il inclue "aura" ...
C'est très naturel, et se rapproche quasiment du langage humain ...
Là où ça pêche, c'est qu'on peut formuler la même idée d'au moins 5 façon différentes (au moins)
Là où python ne laisse qu'une seule forme :
if "aura" not in "restaurant": exit
(je continue à croire que tout programmeur venant du monde c/java/c#/basic sera plus habitué à comprendre la (seule et unique) "forme python")
L'esprit des 2 langages diffèrent énormément sur ce point. Python dit qu'il ne doit y avoir qu'une seule façon de faire (et le respect bien), et ruby laisse au programmeur la liberté de faire comme bon lui semble ...
A partir de ce constat : il est évident que le tant d'apprentissage du ruby est bien supérieur au tant d'apprentissage du python. Car il existe, de manière générale, différentes formes de construction du code.(et je l'ai vécu, au bout d'1h d'apprentissage de python, j'arrivai à faire des choses déjà bien ... je ne peux pas en dire autant après 1h de ruby)
Dans le même ordre d'idée, ça doit compliquer également la maintenance d'un code d'un tier (pour peu qu'il utilise pas les mêmes formes que soi ... à moins de toutes les connaître bien évidemment)
C'est assez flagrant, car même sur les sites du tutoriels, ils n'expliquent pas forcément la même forme pour faire tel ou tel chose (et ça, ça m'a perturbé ... je me suis même demandé s'il n'avait pas changé le langage entre les 2 docs ... mais peut être suis déjà trop formatté python 'one way')
Bref, les 2 langages ne jouent pas du tout dans la même catégorie. J'ai un peu peur que ruby ne se cantonne qu'à une niche de programmeur expérimenté. Certes la conception du langage est très interessante (et m'a donné envi de voir smalltalk) ... Mais je continue à croire que son appréhension reste difficile pour le programmeur lambda que je suis ...
Je vais perseverer ...
[^] # Re: allez ...
Posté par Frederick Ros . Évalué à 2.
C'est très naturel, et se rapproche quasiment du langage humain ...
Là où ça pêche, c'est qu'on peut formuler la même idée d'au moins 5 façon différentes (au moins)
Là où python ne laisse qu'une seule forme :
if "aura" not in "restaurant": exit
C'est bien la un des points que je n'aime pas avec le Python ....
(je continue à croire que tout programmeur venant du monde c/java/c#/basic sera plus habitué à comprendre la (seule et unique) "forme python")
Pas d'accord. Je viens du monde C et je n'ai eu aucun pb avec cette approche.
L'esprit des 2 langages diffèrent énormément sur ce point. Python dit qu'il ne doit y avoir qu'une seule façon de faire (et le respect bien), et ruby laisse au programmeur la liberté de faire comme bon lui semble ...
Cette liberte est une des choses les plus fondamentales qui doivent exister au sein d'un langage, a mon avis. Tu ne peux t'approprier et innover que si tu as la liberte de le faire. Avoir une seule facon de dire les choses, communes a tous les developpeurs, ne peut favorise l'enrichissement d'un langage et la liberte de s'exprimer au mieux selon le contexte...
C'est cette liberte aui m'avait fait m'enthousiasmer lorsque j'ai edcouvert le Perl il y a 8 ans ...
A partir de ce constat : il est évident que le tant d'apprentissage du ruby est bien supérieur au tant d'apprentissage du python. Car il existe, de manière générale, différentes formes de construction du code.(et je l'ai vécu, au bout d'1h d'apprentissage de python, j'arrivai à faire des choses déjà bien ... je ne peux pas en dire autant après 1h de ruby)
Dans le même ordre d'idée, ça doit compliquer également la maintenance d'un code d'un tier (pour peu qu'il utilise pas les mêmes formes que soi ... à moins de toutes les connaître bien évidemment)
Je ne suis pas tout a fait d'accord. Si tu suis une des idees de l'Agile Programming, le developpeur (mais ca s'applique a d'autre disciplines) suit ce que l'on appelle en Aikido le Shu-Ha-Ri. Dans l'etape Shu, il debute et se conforme uniquement a une ecole, un style. Dans l'etape du Ha, il commence a suivre d'autres ecoles (styles) et a ainsi construire une base encore plus importante. Dans la derniere etape le Ri, il construit son propre style, fort qu'il est de sa connaissance, et de ses automatismes. Les 2 premiers styles lui ont permis de comprendre la philosophie inherente et de pouvoir se detacher et/ou appliquer le meilleur style la ou il doit etre applique.
Le temps d'apprentissage est alors peut-etre plus long, mais il est nettement plus enrichissant (IMHO).
Encore une fois le code Ruby se lit souvent assez facilement car il fait souvent ce que l'on lit....
Malgre le 'une seule' facon mis en avant de Python, je n'arrive toujours pas alire/comprendre certains programmes (meme courts).
L'auteur de Ruby a mis en avant une chose importante: Ruby a ete ecrit pour lui, par lui. Il a voulu qu'il y ait plusieurs styles possibles pour que le plus grand nombre puissent eventuellement l'utiliser. Dans les langage 'une seule facon', le dev doit coller a la facon de penser/voir de l'auteur du langage ....
Un dernier lien : http://www.ntecs.de/blog/Blog/HumanUnderstandabilityRuby.rdoc(...)
[^] # Re: allez ...
Posté par manatlan (site web personnel) . Évalué à 2.
> aucun pb avec cette approche.
evidemment ;-)
Toi t'as u aucun prob, ça veut pas dire que tout le monde n'a u aucun prob avec cette approche
Cette approche, moi-même ne me choque pas non plus (mais avoue ne l'avoir jamais rencontré dans tous les autres langages que j'ai vu dans ma vie de développeur)...
> Cette liberte est une des choses les plus fondamentales
> qui doivent exister au sein d'un langage
dans ta vision ... Mais avoue que cette liberté introduit énormément de problèmes si plusieurs développeurs se succèdent sur un même code. Et ça, dans la vraie vie, c'est pas un avantage.
J'adore le codage, j'aime quand mon code est "beau", et je t'assure qu'en python il y a moyen de se faire plaisir dans ce créneau. Ce n'est pas réservé aux perls/ruby ...
Mais j'aime également être productif ... et pouvoir reprendre mon code 4ans après, et repartir dessus comme en 40 ;-)
> Malgre le 'une seule' facon mis en avant de Python, je n'arrive
> toujours pas alire/comprendre certains programmes (meme courts).
ça je dirai que c'est de la mauvaise "foie" ;-). SI moi j'arrive à lire du ruby, t'arrives à lire du python ... le problème doit se poser ici sur la motivation ;-)
> http://www.ntecs.de/blog/Blog/HumanUnderstandabilityRuby.rdoc(...)
ça c'est aussi rigolo, un test à une personne (sa copine), et qui réussi 4 tests sur 7 (juste la moyenne)
ça veut absolument rien dire ... les formes pythons de ces tests auraient peut être été mieux compris (j'en suis presque persuadé)
ça sert à rien de se battre sur ces points de lisibilité de codes. Python est tellement au-dessus ;-) http://mcsp.wartburg.edu/zelle/python/python-first.html(...)
sinon on peut arrêter de troller, il n'y a que très peux de points communs entre les 2 langages. Ils ne sont pas du tout dans les mêmes catégories, on ne peut pas les comparer.
je suis globalement d'accord avec tout ce qui est dit ici : http://www.rexx.com/~oinkoink/Ruby_v_Python.html(...)
sinon ... même matz troll :
"Ruby inherited the Perl philosophy of having more than one way to do the same thing. I inherited that philosophy from Larry Wall, who is my hero actually. I want to make Ruby users free. I want to give them the freedom to choose. People are different. People choose different criteria. But if there is a better way among many alternatives, I want to encourage that way by making it comfortable. So that's what I've tried to do. Maybe Python code is a bit more readable. Everyone can write the same style of Python code, so it can be easier to read, maybe. But the difference from one person to the next is so big, providing only one way is little help even if you're using Python, I think. I'd rather provide many ways if it's possible, but encourage or guide users to choose a better way if it's possible"
Je pense que ce n'est pas la bonne direction (déjà prendre perl en exemple, à la base, c'est pas bon) ... "laisser autant de liberté au programmeur ... quand il existe, par nature, une seule façon de faire qqchose" ... c'est introduire des problèmes sur le long terme.
Le programmeur est certes plus heureux d'harmoniser son code à sa guise, et de faire comme il veut ... mais moi, j'ai passé l'age (en qqsorte) ... disons que la productivité prime sur le look'n'feel du code ...
Exemple : Pour mes projets perso à la maison (et qui prends donc du temps sur ma vie), je préfère aller à l'essentiel, je n'ai pas le temps de philosopher sur la façon d'agencer mes opérandes (ex: me poser la "question quelle est la plus belle façon de coder cette condition ?").
Et pour ça python, son "one way", sa communauté, et ses "libs mature" (DANS TOUS LES DOMAINES !!!!) m'apporte une plus-value que ne peut pas m'apporter le ruby de nos jours ... donc basta
le sujet est clos (pour moi, enfin ;-)
Cependant je garde mon ruby de côté, et je coderai avec pour le fun.
De plus en plus, j'ai l'impression que les rubistes (en commençant par matz) cherche à discutaller comparaison avec le python (maintenant que le perl n'est plus), uniquement pour faire parler de ruby, et donner une légitimité au langage. En faisant croire qu'ils sont sur le même terrain de jeu ...
Et je suis absolument pas d'accord avec ça ...
[^] # Re: allez ...
Posté par manatlan (site web personnel) . Évalué à 3.
le "one way" de python permet au développeur de se concentrer sur l'implémentation de son algo ...
sa tête n'est pas brouillée par des considérations comme "quelle forme de condition vais-je utiliser ici", ou quel est le "hieroglyphe" maintenant qui "permet de faire gagner 2 lignes de codes" ?
le fait qu'il n'existe qu'une seule façon de faire, fait que le dev ( qui a forcément toutes les formes en têtes pour chaque cas) "pisse" le code tout en restant concentré sur ce qu'il est en train d'implémenter ... et non sur la sémantique de chaque opérande ... (c'est un point très important !)
(ok, le dev ruby utilisera les formes qu'il utilise habituellement ... mais quid du nouveau dev qui arrive dans son code, et qui n'utilise pas les mêmes formes)
ce côté là n'a pas de prix ... et je m'en rends compte chaque jour de l'avantage que ça apporte, en terme de production/maintenance/coût de dev ... avoir la tete libre, et "pisser" le code naturellement
Sinon, tous ces posts/trolls m'ont fait beaucoup réfléchir et m'ont apporté beaucoup ...
ils m'auront fait découvrir un peu plus ruby (et aimé), ils m'auront amener à réfléchir sur les langages, et ils m'auront aider à comprendre pourquoi j'aime tellement le python ...
Comme quoi on n'a pas ergoté pour rien à travers ces posts ...
[^] # Re: allez ...
Posté par pifou . Évalué à 3.
Si on prend Perl à l'opposé, c'est un langage plus permissif mais dont le gros problème vient du fait qu'il n'y a aucune structure établie, je veux dire par là que ce n'est déjà pas un langage objet, et à demie procédurale. Bref on peut faire n'importe quoi au niveau structure (et d'ailleurs la plupart du temps on fait vraiment n'importe quoi :). Ensuite Perl permet d'omettre un nombre considérable de commande pour faire une action (utilisation abusive des variables magiques) ce qui rend le code illisible.
Après il y à Ruby qui par rapport à Perl apporte déjà une structure claire : c'est un langage pur objet. Ensuite, il limite considérablement l'utilisation de raccourcie syntaxique, on ne peut pas rendre obscur un bout de code juste pour ce faire plaisir comme en Perl. La seule chose que permet Ruby c'est d'utiliser facilement des principes objets un peu évolué (et rien de plus, ça se limite toujours à des notions d'héritage/composition/surcharge ...). Pour l'instant, je n'ai jamais eu de problème pour lire du code en Ruby. Bien sûr il doit bien y avoir moyen de faire des choses complétement obscurs, mais je ne vois pas pourquoi un développeur normal irait se prendre la tête à le faire (en tout cas pas plus qu'en Python). Il utilisera juste la puissance que le langage lui offre pour répondre au mieux à ses besoins. Et c'est là que Ruby depasse Python, au lieu de limiter le développeur à faire toujours la même chose (principe du "on a toujours fait comme ça") il lui laisse une porte ouverte (qu'il est libre de prendre ou pas) pour faire évoluer ça façon de programmer. Tout cela en gardant une réelle cohérence, rien ne contredit l'approche objet et tout reste lisible au contraire de Python par exemple pour l'introspection (je trouve que demander à l'objet ou une classe les méthodes qu'il fournit plus logique que d'utiliser des fonctions externes (dir()).
Bref, je suis convaincu que Ruby apporte vraiment de nombreux plus tout en restant accessible au plus grand nombre de développeur (quelque soit leur origine).
[^] # Re: allez ...
Posté par Frederick Ros . Évalué à 1.
sa tête n'est pas brouillée par des considérations comme "quelle forme de condition vais-je utiliser ici", ou quel est le "hieroglyphe" maintenant qui "permet de faire gagner 2 lignes de codes" ?
Tu es de mauvaise foi ici ... Quel hieroglyphes te fait gagner 2 lignes de codes ?? Je pourrai dire de meme que Ruby te permet de te concentrer sur l'algo sans te demander si tu dois rajouter des __ au debut et a la fin de ta methode ;)
e fait qu'il n'existe qu'une seule façon de faire, fait que le dev ( qui a forcément toutes les formes en têtes pour chaque cas) "pisse" le code tout en restant concentré sur ce qu'il est en train d'implémenter ... et non sur la sémantique de chaque opérande ... (c'est un point très important !)
(ok, le dev ruby utilisera les formes qu'il utilise habituellement ... mais quid du nouveau dev qui arrive dans son code, et qui n'utilise pas les mêmes formes)
Pisser du code sans lever la tete est ce qu'il y a de pire IMHO : tu te concentres sur le code que tu as sous les yeux en perdant de vue ton design ....
Comme quoi on n'a pas ergoté pour rien à travers ces posts ...
Je suis d'accord avec toi ... Comme quoi on peut on peut avoir une discussion animée tout en respectant l'autre ;)
[^] # Re: allez ...
Posté par Frederick Ros . Évalué à 1.
Toi t'as u aucun prob, ça veut pas dire que tout le monde n'a u aucun prob avec cette approche
Cette approche, moi-même ne me choque pas non plus (mais avoue ne l'avoir jamais rencontré dans tous les autres langages que j'ai vu dans ma vie de développeur)...
J'ai jamais dit ca... J'ai juste voulu dire que si tu viens du C/Java ..etc.. l'approche Python ne paraissait pas plus naturelle comme tu l'affirmais ...
J'adore le codage, j'aime quand mon code est "beau", et je t'assure qu'en python il y a moyen de se faire plaisir dans ce créneau. Ce n'est pas réservé aux perls/ruby ...
Mais j'aime également être productif ... et pouvoir reprendre mon code 4ans après, et repartir dessus comme en 40 ;-)
Pareil ... mais je trouve que justement il est plus beau en Ruby ;) et puis au niveau lisibilite que dire de l'indentation ... Bien sur tout le monde devrait utiliser des espaces et pas des tabs, bien sur une tab devrait faire 8 espaces (enfin je crois de tete)... mais dans la realite ca n'arrive jamais .. Les gens ne maitrisent pas leur editeur et insere des tabs, leur tabs font 4 espaces ... etc ... au final bonjour la lisibilite (j'ai le meme probleme avec le C: les tabs sont interdites dans ma boite ..; pourtant :( )
Donc reprendre un code comme ca meme apres 4h .... alors si en plus cette indentation sert a indiquer la logique de ton programme ...
ça je dirai que c'est de la mauvaise "foie" ;-). SI moi j'arrive à lire du ruby, t'arrives à lire du python ... le problème doit se poser ici sur la motivation ;-)
Non, non ...J'ai essaye de me mettre a Python bien avant de connaitre Ruby (de tete j'ai du vouloir jouer avec en 98 ou 99) .. et ca ne m'a pas plus des le debut ... J'ai re-essaye y'a un ou deux ans en me disant "peut-etre que ca se passera mieux" et boum .. pareil ..
ça je dirai que c'est de la mauvaise "foie" ;-). SI moi j'arrive à lire du ruby, t'arrives à lire du python ... le problème doit se poser ici sur la motivation ;-)
Bof .. je prefere http://savannah.nongnu.org/projects/pgubook/(...) et pourtant l'ASM n'est pas plus lisible ;)
Je pense que ce n'est pas la bonne direction (déjà prendre perl en exemple, à la base, c'est pas bon) ... "laisser autant de liberté au programmeur ... quand il existe, par nature, une seule façon de faire qqchose" ... c'est introduire des problèmes sur le long terme.
Il exitste une seule facon de faire les choses ne veut pas dire qu'il n'y a qu'un moyen de les exprimer ... sinon on parlerai tous un anglais standardise...
Exemple : Pour mes projets perso à la maison (et qui prends donc du temps sur ma vie), je préfère aller à l'essentiel, je n'ai pas le temps de philosopher sur la façon d'agencer mes opérandes (ex: me poser la "question quelle est la plus belle façon de coder cette condition ?").
Justement tu n'es pas oblige de te poser cette question .. Tu programmes comme tu penses ... sans te demander comment l'auetru du langage aurait pense cette construction ..
De plus en plus, j'ai l'impression que les rubistes (en commençant par matz) cherche à discutaller comparaison avec le python (maintenant que le perl n'est plus), uniquement pour faire parler de ruby, et donner une légitimité au langage. En faisant croire qu'ils sont sur le même terrain de jeu ...
Et je suis absolument pas d'accord avec ça ...
Ben les dernieres fois ou y'a eu des discussion sur la ML au sujet de cette comparaison c'etait des questions de nouveau-venus ou de Pythoneux qui venaient demander pourquoi l'on pensait que c'etait mieux ...Quand au Perl il a encore de beaux jours devant lui .. Et si l'on en croit ce qui devrait se faire en perl 6 ca risque d'etre sympa ...
[^] # Re: allez ...
Posté par manatlan (site web personnel) . Évalué à 3.
Mon avis est fait, je l'ai beaucoup travaillé, et me suis même mis à ruby ... (tout en appréciant encore plus le python pour certaines de ses idées de bases, que je n'avais pas assimilé avant tous ces posts)
il y a juste encore un point (c le dernier promis !) que je ne peux pas laisser ....
> J'ai juste voulu dire que si tu viens du C/Java ..etc..
> l'approche Python ne paraissait pas plus naturelle comme
> tu l'affirmais ...
Comment un développeur, qui a certainement commencé à coder avec C, java ou basic, peut dire que le code suivant n'est pas plus naturel (dans le sens facile à comprendre) ?!?
--------------------------------------------
if "poisson" not in restaurant : exit
--------------------------------------------
traduit litteralement : si il n'y a pas de poisson dans le restaurant je sors ;-)
c'est d'ailleurs la même formulation qu'en algorithmie (ça s'apprends plus à l'école ou quoi ?!?)
comment peut on soutenir mordicus qu'une forme comme celle ci :
--------------------------------------------
exit unless restaurant.include? "poisson"
--------------------------------------------
est plus parlante ?!? ça me dépasse totalement ...
certes j'ai commencé l'info avec le basic du zx80, puis du c64, pour passer à l'asm 68000 de l'amiga, puis le C plus tard
Je ne sais plus trop ce qu'on enseigne en école, si l'algorithmie a changé totalement ou n'est plus au programme...
Mais là, le gars, en gros, il commence par parler de sortir du restaurant, et se pose la question après coup "il y a t il du poisson ?" ... c'est assez négatif comme comportement ... non ?! à la base
mais que ce soit en basic/asm/c ou java ; on se pose la question avant, et on agit après ... (comme dans la vie, non ?!)
soutenir que cette forme est plus lisible que le classique if/then/else ... ça me dépasse ...
je ne parle même pas de la sémantique, car si on oublie le "?" ça pète ... et si naturellement on a envie de le mettre à la fin, ça pète aussi ...
ce "unless" est nouveau ... (il me fait pensé au "until" s'opposant au "while") ... C'est certes très "concept" ... très moderne ... et très original.
Mais ça n'apporte que du bruit, là où un classique if/then suffirait ?! (et qui plus est, est toléré egalement)
(Laisser la liberté au codeur d'utiliser la forme qu'il souhaite est une hérésie totale ?! et n'apporte vraiment rien ... à part de la satisfaction au dev, une certaine libertée d'expression ... mais au détriement de pas mal de choses qui me paraissent bien plus importantes .. ***le résultat est plus important que la façon d'y arriver***)
Suis-je fou totalement ? est-ce que je divague quand je comprends pas sleeper ?! est-ce que les cours d'info ont tellement changé en 10 ans ? aidez moi ...
Suis je vraiment de mauvaise foi ?
Je ne crois pas, au contraire, ruby est maintenant installé sur mon poste, et je compte même m'y mettre plus sérieusement ...
Je concède même que sa forme OO est bien plus poussée que python, et que c'est certainement le langage objet le plus interessant du monde libre !
Je concède que python a une syntaxe surchargée objet prise sur le tard, et par conséquent possède des petits héritages peut être pas très beaux pour certains (cf le self) ... mais je l'ai connu comme ça, et j'ai appris à l'aimer malgré ses imperfections ;-)
Je suis peut être trop pragmatique ... trop matérialiste ... m'attachant plus au résultat qu'à la façon d'y arriver...
mais le coup du if/then face au unless ... non
[^] # Re: allez ...
Posté par Frederick Ros . Évalué à 1.
--------------------------------------------
if "poisson" not in restaurant : exit
--------------------------------------------
traduit litteralement : si il n'y a pas de poisson dans le restaurant je sors ;-)
c'est d'ailleurs la même formulation qu'en algorithmie (ça s'apprends plus à l'école ou quoi ?!?)
comment peut on soutenir mordicus qu'une forme comme celle ci :
--------------------------------------------
exit unless restaurant.include? "poisson"
--------------------------------------------
Tout simplement en lisant ! Le code dit exactement ce qu'il fait : " sort a moins que restaurant n'inclue poisson
certes j'ai commencé l'info avec le basic du zx80, puis du c64, pour passer à l'asm 68000 de l'amiga, puis le C plus tard
Je ne sais plus trop ce qu'on enseigne en école, si l'algorithmie a changé totalement ou n'est plus au programme...
J'ai a peu pret le meme parcours ( a part un C128 a la place du C64), et de l'ASM x86...
L'algorithmie n'a strictement rien a voir : tu confonds algorithmie et moyen de l'exprimer !
mais que ce soit en basic/asm/c ou java ; on se pose la question avant, et on agit après ... (comme dans la vie, non ?!)
Tu veux dire que tu fais, dans la vie, toute tes phrases comme cela ? Tu ne dis jamais quelque chose comme : "je vais a la plage s'il fait beau" ?
Je comprends pas bien ton raisonnement la ... Encore une fois tu confonds ce que tu veux faire et comment l'exprimer ...
(Laisser la liberté au codeur d'utiliser la forme qu'il souhaite est une hérésie totale ?! et n'apporte vraiment rien ... à part de la satisfaction au dev, une certaine libertée d'expression ... mais au détriement de pas mal de choses qui me paraissent bien plus importantes .. ***le résultat est plus important que la façon d'y arriver***)
Non. Ce qui est une heresie c'est de forcer tous les codeurs a penser comme soi.
Si le "resultat est plus important que la facon d'y arriver" pourquoi ne pas tout faire directement en binaire ... finallement ca simplifie encore les choses ...
Quelles sont ces choses qui te paraissent importantes ? Quand les autres te parlent tu ne les comprends pas parce qu'il n'utilisent pas la meme syntaxe que toi ? Non, je ne pense pas ..; Alors pourquoi cela poserait-il un probleme quand on en vient au code ?
Suis-je fou totalement ? est-ce que je divague quand je comprends pas sleeper ?! est-ce que les cours d'info ont tellement changé en 10 ans ? aidez moi ...
Je peux pas t'aider ..; mes derniers cours d'info remontent a 10 ans :)
mais le coup du if/then face au unless ... non
Si, si ... ca fait partie des idiomatismes d'un langage tout en evitant la lourdeur d'un if/then quand il n'y a pas lieu ...
[^] # Re: allez ...
Posté par manatlan (site web personnel) . Évalué à 2.
> a 10 ans :)
si tu viens de strasbourg, on était peut être ensemble ;-)
(remarque la construction if/then ;-)
pour ergoter encore un tout petit peu, sur un "unless" par rapport à un "if/then" ...
Le unless a peut être sa place, dans une belle implémentation d'un tri "quicksort la bulle", en une quinzaine de lignes...
Mais dans nos developpements, on doit résoudre des problèmes bien plus complexes (en général) pour ne pas avoir à s'embêter avec des enchevêtrements de if/then, d'unless, ou des (..?.. : ..)
(avec plein de briques simples, on peut construire des cathédrales ... laisser 10 façons de faire un if/then/else ne peut que nuire)
> L'algorithmie n'a strictement rien a voir
en algorithmie, les conditions étaient clairement "SI / ALORS / SINON" (il y a 10 ans) ... et non "à moins que" ;-)
sinon pourquoi pas inventer aussi le AS LONG AS (aussi longtemps que) ou le "as from the moment when" (à partir du moment où) ... etc ...
Il existe de très belles formules dans notre langage qui ne sont pas présentes dans nos langages de codages ...
je crois au KISS ... keep it stupid and simple ...
[^] # Re: allez ...
Posté par Frederick Ros . Évalué à 1.
(remarque la construction if/then ;-)
Nope .. Pas de strasbourg :(
Mais dans nos developpements, on doit résoudre des problèmes bien plus complexes (en général) pour ne pas avoir à s'embêter avec des enchevêtrements de if/then, d'unless, ou des (..?.. : ..)
(avec plein de briques simples, on peut construire des cathédrales ... laisser 10 façons de faire un if/then/else ne peut que nuire)
La complexite ne vient pas de la facon dont tu exprimes ton code .. Si ton design est propre ta complexite locale devient quasi-nulle ... Tu peux alors ecrire des choses propres, utiliser la construction syntaxique qui se rapproche le plus de ce que tu as en tete ... etc...
Pour ce qui est des cathedrales: elles sont rarement construire avec des briques de meme forme ...
en algorithmie, les conditions étaient clairement "SI / ALORS / SINON" (il y a 10 ans) ... et non "à moins que" ;-)
sinon pourquoi pas inventer aussi le AS LONG AS (aussi longtemps que) ou le "as from the moment when" (à partir du moment où) ... etc ...
Il existe de très belles formules dans notre langage qui ne sont pas présentes dans nos langages de codages ...
Et c'est justement l'un des problemes .. Je suis assez d'accord avec http://www.onboard.jetbrains.com/articles/04/10/lop/(...)
Et je suis adepte du KISS et du DRY (Do not Repeat Yourself) .. qui se plie mal au cas du self ;)
[^] # Re: allez ...
Posté par manatlan (site web personnel) . Évalué à 2.
Interessant ton lien ... j'ai pas tout lu ... mais ça me dépasse aussi ;-)
On pourrait débattre encore des heures sur ce qu'un langage doit implémenter en matière de "forme naturelle" ...
Maintenant, toutes ces masturbations spirituelles pour dire qu'il ne devrait pas y avoir de différence entre un texte de Proust et un bout de code ... j'y crois pas ... enfin ... c'est pas pour tout de suite ...
Un jour peut être, pour peu qu'on utilise encore le clavier pour mettre à plat le design situé dans la caboche ...
C'est certes plus beau de se dire qu'il existe 15 façons d'écrire le quicksort ... comme il existe peut être 15 façons d'écrire l'étranger de camus (?!) ... ("mon dieu, quel comparaison !" )
j'aurai tendance à croire qu'il ne devrait exister qu'une seule façon d'écrire le quicksort ... ça facilliterait tellement les choses ... (le quicksort n'étant, après tout, qu'un outil devéloppé avec un outil)
Mais l'homme est ainsi fait ...
Pour tout ça, je me dis que je suis bien dans le camp des pythoneux : résumons au plus simple, pour pouvoir faire toujours plus complexe ...(si on commence déjà à gambergé de la meilleure manière d'implémenter son simple if/then/else, on avance pas)
Regarde où en est la communauté python ...
ils sont en train de voir comment implémenter un typage fort (optionnel) dans un futur python ...
http://aroberge.blogspot.com/2005/01/where-keyword-and-python-as-ps(...)
(cette approche est ma préférée)
Tout ça uniquement pour rendre les programmes "rock solid" (erreurs de types trappées à la compile), aider les futurs compilateurs à générer du code natif ... bref, aider à faire pénétrer python encore et toujours dans le milieur des entreprises ....
ça n'a pas non plus un sens profond, c'est juste parceque les entreprises auraient du mal à troquer leur baril de java/c/csharp fortement typé, contre un baril de langage dynamique qui peut pêter à tout instant (sans unittest) (cf mes posts bien au-dessus)
non, vraiment ... les 2 langages ne jouent pas du tout dans la même cours ... les 2 communautés sont vraiment très différentes ...
Vive python, vive ruby, vive [votre langage préféré] ! Vive cette diversité, et vive ce bouillon d'idées qui germent de tous les côtés de la toile grace à une floppée de petits gars qui pensent, qui discutent et qui agissent
Le monde informatique du futur sera vraiment plus qu'interessant ...
bon, je retourne dans mon csharp ;-(
[^] # Re: allez ...
Posté par Frederick Ros . Évalué à 1.
Justement .. on ne se pose pas la question: on ecrit ...
Tout ça uniquement pour rendre les programmes "rock solid" (erreurs de types trappées à la compile), aider les futurs compilateurs à générer du code natif ... bref, aider à faire pénétrer python encore et toujours dans le milieur des entreprises ....
Oui j'ai vu ca .. mais je ne suis pas encore convaincu du benefice reel d'un typage fort. En pratique (du moins en Ruby) les erreurs du a du 'trans-typing' sont extremement rares .. maintenant qu'il soit optionnel ...
Dans le camp Ruby on prend presque la direction opposee : le Duck Typing : 'If it walks like a duck, and talks like a Duck, then it's a Duck' .. qui est vraiment tres pratique ...
Vive python, vive ruby, vive [votre langage préféré] ! Vive cette diversité, et vive ce bouillon d'idées qui germent de tous les côtés de la toile grace à une floppée de petits gars qui pensent, qui discutent et qui agissent
Le monde informatique du futur sera vraiment plus qu'interessant ...
Tout a fait d'accord avec toi ..
[^] # Re: allez ...
Posté par manatlan (site web personnel) . Évalué à 2.
Je suis tombé sur un article, qui retrace exactement tous nos propos ... C'est même assez incroyable !
C'est le blog de l'auteur "thinking in java" (et thinking in python) qui explique pourquoi il ne fera pas "un thinking in ruby" ...
http://onthethought.blogspot.com/2005/01/thinking-in-ruby-not.html(...)
Il faut tout lire ... même les commentaires des rubistes ... on retombe dans les mêmes débats, avec les mêmes exemples que j'ai pris (c'est fou ?! est on trop formatté python ?)
au sujet de l'indentation (problème qui revient souvent), j'adore :
"... Hey, the first time I picked up a Python book (after two intense months with Perl had come crashing down upon discovering how lame references and objects were, which I suspect was a major impetus in the creation of Ruby), I threw it down, saying "Indentation to determine blocks? That's the most ridiculous thing I've ever seen!" I eventually picked up the book again. A couple of years later, I was responsible for that year's Python Conference T-shirt "Life's better without braces!" (cartoon of a smiling kid who had just gotten his braces off)... "
non, c'est vraiment 2 mondes différents ... je n'ai vraiment plus aucun doute ... et je sais aussi pourquoi j'aime le python à ce point !
[^] # Re: allez ...
Posté par Frederick Ros . Évalué à 1.
http://onthethought.blogspot.com/2005/01/thinking-in-ruby-not.html((...))
On doit qvoir les memes sources ;) je l'ai lu aussi aujourd'hui ... et aussi certains autres commentaires sur la Ruby ML, ou un pythonneux est venu demander pourquoi tous les Rubyistes ne se mettaient pas a Pyhton ...
Et c'est vrai que les memes arguments reviennent .. et en premier lieu le 'One Way' ...
Je sais aussi pourquoi j'aime Ruby ;)
[^] # Re: allez ...
Posté par Frederick Ros . Évalué à 1.
> The Zen of Python, by Tim Peters
> ...
> Although that way may not be obvious at first unless you're Dutch.
"It also makes sense if you grew up Pennsylvania Dutch [...]"
Bruce Eckle, commenting on the readability of a given Ruby example.
http://onthethought.blogspot.com/2005/01/thinking-in-ruby-not.html(...)
:)
[^] # Re: allez ...
Posté par pifou . Évalué à 2.
J'espère aussi que ça va être mon dernier post, et effectivement il n'y a pas trop lieu de comparer les deux langages. Mais tu sembles tout de même continuer de le faire dans la suite de ton post :).
Je voulais juste dire que, pour moi, la véritable différence entre Python et Ruby ne se trouve pas sur des questions pseudos syntaxiques sur l'introduction des ! et ? et autres unless, loop .... mais plutôt sur les possiblités de manipulation du langage (encore et toujours la puissance d'expression du langage). Et cela en gardant une réelle cohérence (objet), je trouve même dommage qu'il n'utilise pas la notion SmallTalk pour les structures conditionnelles (genre les if-else, while ... faisant parti de la classe boolean : i==0 ifTrue {puts "Vrai"} else {puts "Faux"}), mais ça se comprends, il ne fallait pas trop chambouler les habitudes des programmeurs.
Bref, je voulais juste dire que pour moi il n'y a pas de raison de discuter sur la facilité de lecture d'un code, soit on accepte de faire un minimum d'effort pour le lire soit on se braque. Après, moi je me suis braqué sur Python car il n'offrait pas à mon goût de nouveautés d'expressions comme le faisait Ruby, après comme on l'a déjà dit, Python dispose de beaucoup plus de lib que Ruby ce qui est aussi à prendre en compte.
Vive Ruby, Vive Python (ou l'inverse) mais surtout Vive les programmeurs \o/.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.