>C'est mon dernier post sur ce sujet, car je crois qu'il n'y a pas lieu de comparer quoi que ce soit, tellement les 2 langages diffèrent ...
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/.
> c'est le seul langage objet qui fait ca, ca ne sert à rien.
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 :).
Je n'ai pas dit le contraire, effectivement on retrace assez facilement les résultats d'un algo génétique mais de là à comprendre le résultat il a un grouffre. Prennons l'exemple des paramètres du noyau Linux, tu auras beau avoir le cheminement de l'algo G qui donne une bonne solution, ça ne sera pas facile de comprendre pourquoi cette ensemble de valeurs marche bien. Bref, c'est assez empirique comme façon de faire, on arrive à un bon résultat sans être capable de l'expliquer facilement (afin par exemple de le reproduire dans un contexte un peu différent). Je me trompe peut être (surement), je n'ai pas regardé les algos G depuis plus d'un an et les méthodes d'analyses des résultats ont surement évoluées. En tout cas, c'était le ressentiment que j'avais eu à l'époque (qui vaut ce qu'il vaut).
Tout à fait d'accord avec tes compléments d'informations, on peut même ajouter le problème de compréhension des solutions générées. Car même si on trouve une solution efficace grâce à un algorithme génétique ça n'est pas évident qu'on arrive à comprendre pourquoi ! Ce qui est un peu bête si on veut vérifier si par hazard ce n'est pas la solution optimum et donc de continuer à chercher quelque chose de mieux (qui n'existe peut être pas). Je me rappelle l'exemple d'un algo génétique qui simuler le bon vieux cas d'école des fourmis (recherche de nourriture, trace de phéromone ...), et bien ils étaient tombé sur la solution optimale (d'après les paramètres mis en jeu) mais on mis un temps énorme à le prouver :).
Comme d'hab je ne suis pas d'accord. Le problème de Python est justement de ne pas laisser de lattitude aux programmeurs, à les enfermer dans une façon de faire. Effectivement, ça permet au premier abord de gagner de la lisibilité et de la maintenabilité, c'est con comme la lune (pour qqun aimant et comprennant la philosophie du langage, ce qui n'est pas toujours le cas par exemple pour moi) de reprendre du code, y'a même pas besoin d'essayer de comprendre comment le gars avant à conçu son code ... puisqu'en fin de compte ça donnera grosso modo toujours le même résultat (un code rempli de références abusives (self, __) avec aucune possibilité d'abstraction). On peut se satisfaire de cet état de fait comme on le fait en C (et ça n'a rien de péjoratif).
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).
Excuse moi , j'étais un peu fatigué quand j'ai lancé le bon troll sur l" "x10 plus puissant que Python" :). Mais je maintiens que Ruby est stricto facto plus puissant que Pytho au niveau pouvoir d'expression.
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).
C'est bien à quoi je pensais quand je disais "Bref, mon random semble un peu chaotique quoique normallement il faudrait lancer beaucoup plus de fois la commande pour savoir si j'ai un vrai biais dans la fonction aléatoire" :).
Ça me refait penser aux gars qui venaient dans l'emission Mystères avec de prétendus pouvoirs télékynésiques capable de forcer des pièces à tomber toujours du même coté (genre 9 fois sur 10 essais). Il demandait au gens qui regardaient l'emission de faire l'expérience chez eux et d'appeller si ça marchait. Ça parrait balaise, mais faites le test chez vous, vous verrez que vous tomberez assez souvent 8 fois sur le même coté sur 10 essais. Donc évidemment avec les millions de téléspectateur à lancer des pièces chez eux, le standard explosait d'appel de gens pour qui le medium avait réussi sa manipulation parapsychique, le pouvoir de notre gars était par la même occasion validé \o/ clap clap \o/. C'est un peu le même style que le gars qui demandait d'allumer toutes les ampoules de la maison et qui les faisait griller par télékynésie. Je conseil aux personnes que ça interesse de regarder du coté de la zététique (attention domaine sujet à gros trolls velus :).
Bref, quelque soit la méthode (même si la deuxième est exacte par rapport à la première) c'est bien ce que je disais au début, c'est une question d'échantillonage. La preuve en modifiant un peu votre script pour passer en paramètre le nombre d'essai à faire on se rend compte que plus on l'augmente plus on s'approche des 16% théorique
En 40 coups, je ne tombe que 3 fois sur 0 (dont 2 à la fin) ! D'un autre coté si j'ai vraiment lancé cette commande c'est que mon système est un peu bancal, et ça m'aurait permis en cas de perte de données système de refaire une install propre :). Bref, mon random semble un peu chaotique quoique normallement il faudrait lancer beaucoup plus de fois la commande pour savoir si j'ai un vrai biais dans la fonction aléatoire. Peu être que le fait de lancé les commandes très rapidement joue sur le résultat. Les résultats sont plus normaux quand je passe mon processeur (ntel(R) Pentium(R) 4 Mobile CPU 1.80GHz) à 14% (T14=86%) de sa puissance (j'utilise wmthrottle) :
Plus de 20 essais avant de me faire avoir ! je finissait par croire que le code ne marchait pas :). C'est quand même drôle qu'il commence par effacer ma partoche windows :)
> ça je suis pas d'accord !
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).
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 :).
Heureusement qu'il a "récupéré" des bonnes idées de Python et pas des mauvaises :). Mais je pense avant tout qu'il a voulu faire un langage de script style Perl (avec la puissance des expressions régulières, la facilité d'écriture de code ..) totalement objet (style SmallTalk). Après quand il avait des choix à faire il me parrait évident qu'il a regardé sur les langages existants et ne s'est pas privé pour reprendre les bonnes idées (qu'elles viennent de Python, Perl, Lisp, SmallTalk, Java ...). C'est comme ça qu'évolue les langages de programmation (prendre ce qu'il y a de bien dans les langages existant en ajoutant de nouvelle 'features').
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) :).
Ouais, pour la lisibilité, je pense qu'à ce niveau la c'est une question d'habitude, personnelement, le collect me parait plus parlant ayant déjà fait du SmallTalk (qui comme son nom l'indique devait être du PetitParlé). Mais pour respecter l'esprit SmallTalk j'aurais plutôt écrit le code suivant même si c'est un peu moins optimisé (on peut remplacer 'select' par 'find_all' si on veut):
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'.
Deux petites erreurs, il faut mettre '99.downto(1)' au lieu de '99.downto(0)' et tu as inversé le sens du ton '...?...:...' :). Voici le code qui va bien :
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])}
Ouais, je suis pas trop convaincu (on s'en serait douté :), dans un langage objet il me semble logique de considérer qu'une méthode est de base d'instance, le cas des méthodes statiques étant moins courant (sauf librairie spéciale, style File, Dir, Math ...). Je trouve plus parlante la syntaxe de Ruby pour différencier les deux :
class Toto
def Toto.coincoin # méthode de classe
end
def plop #méthode d'instance
end
end
De plus, dans Python le fait de laisser le choix au programmeur de choisir le nom de la référence sur l'instance courante ne peux poser que des problèmes de maintenabilité (genre il doit bien y avoir des gars qui mettent 'this' (pour les fans de Java/C#/C++/Php) au lieu de 'self', voir 'current' (pour les fans de Eiffel), 'plop' (pour les moules) ...). Du coup je me demandais comment on faisait en Python pour accéder à la méthode définie dans la super-classe (mot clé 'super' en Ruby/Java/SmallTalk) ? en cherchant vite fait sur google je suis tombé sur cette page http://merd.sourceforge.net/pixel/language-study/syntax-across-lang(...) (assez marrante ma fois) qui m'apprend que ça ressemble à ça :
super(Class, self).meth(args), j'ai connu plus simple comme syntaxe (tu peux remarquer l'effort que je fais pour lancer un nouveau troll :).
Réponse rapide sur le "full OO", il faut être un peu stupide pour croire qu'un langage/framework/notion puisse être la solution idéale à tous les problèmes ... comme dans la vie réelle il n'existe pas de solution miracle. L'avantage avec l'objet c'est que ça a permis de faire évoluer le pouvoir d'expression de pas mal de langage informatique, de faire évoluer les mentalités des informaticiens, d'ajouter une couche d'abstration supplémentaire par rapport au langage machine.
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 :)
et franchement le code python m'a tout de suite parlé ...
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.
Je ne suis pas d'accord avec toi :). Je ne vois pas en quoi la syntaxe de Ruby s'inspirent de celle du C ! Je n'ai jamais vu de class|def|begin..end en C, ni de if...then...else...end, ni de loop do...end ... bref si ça se rapproche de C ce n'est pas au niveau des structures conditionnelles. Ensuite pour le code en lui même, puisque Ruby est un langage objet ça ne ressemble en rien à du C mais plutot à du SmallTalk (surtout avec l'utilisation des blocs et itérateurs). De plus en Ruby il est déconseillé d'utiliser les accolades tout comme les points virgules dans son code. Même l'utilisation des parenthèses est souvent limitée. Plus je regarde du code Ruby, plus je me demande comment on peut faire une comparaison avec C ou Python :).
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).
Oui en fait, c'est une des nouveauté de Ruby 1.8.x ! Avant cela il fallait bien faire la surcharge de la classe Array (ou du module Enumerable) comme c'est encore indiqué dans le livre "Programming Ruby" ici : http://www.rubycentral.com/book/tut_containers.html(...)
Bref, je laisse toujours la redéfinition de 'inject' dans mon code histoire que ça marche aussi avec les versions antérieurs de Ruby.
Pour ce qui est de la différence entre Python et Ruby, c'est surtout une affaire de goût. Personnelement j'adore le pouvoir d'expression de Ruby. Ça me fait penser (à raison puisque que c'était le but) à la syntaxe de SmallTalk en ajoutant tout un tas de bonnes idées d'autres langages plus convientionnel (Perl pour l'intégration des expressions régulières^Wrationnelles par exemple).
Je trouve la page Wikipédia sur Ruby pas trop mal faite car elle montre assez simplement les petits plus du langage http://fr.wikipedia.org/wiki/Ruby(...) . Par exemple, je trouve l'utilisation des blocs et itérateurs super simple et beaucoup plus lisible que les structures du style 'for ...'. Sans compter le pouvoir de surcharge des classes de base comme en SmallTalk. Je cherchais le moyen de pouvoir ajouter la méthode 'sum' sur un tableau d'entier (pour sommer tous les éléments du tableau), une petite recherche sur Internet m'a donné le code inspiré de SmallTalk suivant :
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 # 4968
J'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 :/.
Effectivement, il y a GeexBox (http://www.geexbox.org/fr/index.html(...) ) qui est très léger (moins de 8Mo) et qui fonctionne sur presque toutes les machines. Le problème c'est qu'il manque pas mal de fonctionnalitée pour l'instant comme la lecture de radio sur Internet, Streaming de la TV ...
Personnelement, sur mon Shuttle (http://us.shuttle.com/specs2.asp?pro_id=432(...) ), j'ai installé une Knoppix sur mon disque dur puis j'ai ajoutée les sources apt pour Freevo. Ensuite après la config de Freevo (il faut prendre pas mal de temps pour faire quelquechose de soigné), il suffit de configurer Kdm pour lui dire de se connecter sur un compte utilisateur dans lequel tu as mis un fichier .xinitrc qui lance Freevo.
Je n'ai pas encore testé vraiment MythTV, je dirais que la principale différence avec Freevo c'est qu'il se configure presque entièrement à partir des menus (à l'opposé de Freevo où il faut modifier les fichiers de config à la main) et qu'il semble accès sur la partage global des ressources de ton PC sur ton réseau.
Un conseil : ne néglige pas le temps de mise en place de ces différentes applis si tu veux donner ton cadeau dans les temps :) (par exemple pour mettre à jour les programmes de TV par nxvtepg ...).
Il ne faut pas oublier que par contre, non seulement le papier est recyclable, mais qu'il est fait à base d'arbres qui pour croître, ont absorbé le gaz carbonique contenu dans l'air: Utiliser du papier venant de forêt exploitées avec raison (comme en Europe) contribue donc à réduire la pollution atmosphérique...
Le problème avec cet "technique" c'est que tu ne fais que déplacer le problème de quelques années, tout le gaz carbonique que l'arbre à absorbé pendant ça vie sera tôt au tard repartit dans l'atmosphère après combustion ou décomposisition du papier. Effectivement aujourd'hui en Europe comme on fait pousser plus d'arbre que l'on en coupe (forêt en progression), la pollution engendrée à partir de la combustion/décomposition des arbres diminue (il y a plus d'arbre qui "consomme" le gaz carbonique que d'arbre qui partent en fumé) ... mais ça ne fait que retarder le problème, on ne pourra pas continuer à agrandir les forêt pendants des dizaines d'années. Mais il faut bien avouer qu'actuellement ça peut permettre de limiter la pollution par le gaz carbonique en attendant de trouver mieux ... le problème c'est que si on trouve pas mieux on sera dans la merde :/ (d'autant plus que les arbres n'ont pas une vie illimitée donc ils finiront par ce décomposer même si on ne les utilisent pas).
Il ne faut pas non plus négliger la cout "écologique" de la transformation chimique du bois vers le papier et ensuite à chaque recyclage.
Bref, c'est sûr que c'est moins pire que de jeter des PC à la poubelle (je trouve que le problème ici, c'est la rentabilité du PC, si tu utilises ton PC pendant 5 ans, son cout écologique par jour devient moins important que si tu l'utilises que pendant 1 an avant d'en acheter un nouveau), mais il faut tout de même faire attention à sa consomation de papier.
[^] # Re: allez ...
Posté par pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. É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/.
[^] # Re: Différence avec Python ?
Posté par pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. É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: Algorithme génétique ?
Posté par pifou . En réponse à la dépêche Améliorer les performances du noyau avec un algorithme génétique. Évalué à 2.
[^] # Re: Algorithme génétique ?
Posté par pifou . En réponse à la dépêche Améliorer les performances du noyau avec un algorithme génétique. Évalué à 5.
[^] # Re: allez ...
Posté par pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. É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: Différence avec Python ?
Posté par pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. É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: Ben dit donc il en aura fallu du temps avant de mourrir
Posté par pifou . En réponse au journal Roulette linuxienne. Évalué à 2.
Ça me refait penser aux gars qui venaient dans l'emission Mystères avec de prétendus pouvoirs télékynésiques capable de forcer des pièces à tomber toujours du même coté (genre 9 fois sur 10 essais). Il demandait au gens qui regardaient l'emission de faire l'expérience chez eux et d'appeller si ça marchait. Ça parrait balaise, mais faites le test chez vous, vous verrez que vous tomberez assez souvent 8 fois sur le même coté sur 10 essais. Donc évidemment avec les millions de téléspectateur à lancer des pièces chez eux, le standard explosait d'appel de gens pour qui le medium avait réussi sa manipulation parapsychique, le pouvoir de notre gars était par la même occasion validé \o/ clap clap \o/. C'est un peu le même style que le gars qui demandait d'allumer toutes les ampoules de la maison et qui les faisait griller par télékynésie. Je conseil aux personnes que ça interesse de regarder du coté de la zététique (attention domaine sujet à gros trolls velus :).
[^] # Re: Ben dit donc il en aura fallu du temps avant de mourrir
Posté par pifou . En réponse au journal Roulette linuxienne. Évalué à 2.
[^] # Re: Ben dit donc il en aura fallu du temps avant de mourrir
Posté par pifou . En réponse au journal Roulette linuxienne. Évalué à 1.
# Ben dit donc il en aura fallu du temps avant de mourrir
Posté par pifou . En réponse au journal Roulette linuxienne. Évalué à 6.
[^] # Re: Différence avec Python ?
Posté par pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. É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) :).
[^] # Re: Différence avec Python ?
Posté par pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. Évalué à 2.
[^] # Re: Différence avec Python ?
Posté par pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. É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: XP
Posté par pifou . En réponse au message Menu web. Évalué à 4.
Le site précédent vient de me faire découvrir ce site http://www.alsacreations.com/articles/modelesmenus/(...) qui a l'air pas mal et surtout il est en Français.
Et plus généralement un petit tour sur http://www.openweb.eu.org/(...) ou/et http://meyerweb.com/eric/css/edge/index.html(...) ne fait jamais de mal pour trouver des liens.
Bref, ce n'est pas très difficile de trouver des informations en cherchant un peu.
[^] # Re: Distribution + Freevo ou MythTV
Posté par pifou . En réponse au message Linux intuitif pour DivXBox. Évalué à 2.
# Distribution + Freevo ou MythTV
Posté par pifou . En réponse au message Linux intuitif pour DivXBox. Évalué à 2.
Selon moi, le mieux est d'utiliser Freevo (http://freevo.sourceforge.net/(...) ) ou MythTV (http://www.mythtv.org/(...) ) sur ta distribution préférée.
Il y avait des projets intéressants de modification de Knoppix pour intégrer directement ces logiciels sur un CD bootable mais je ne l'ai pas testé : http://www.mysettopbox.tv/knoppmyth.html,(...) http://www.lasolution.be/index.php?pageid=110(...) ...
Personnelement, sur mon Shuttle (http://us.shuttle.com/specs2.asp?pro_id=432(...) ), j'ai installé une Knoppix sur mon disque dur puis j'ai ajoutée les sources apt pour Freevo. Ensuite après la config de Freevo (il faut prendre pas mal de temps pour faire quelquechose de soigné), il suffit de configurer Kdm pour lui dire de se connecter sur un compte utilisateur dans lequel tu as mis un fichier .xinitrc qui lance Freevo.
Je n'ai pas encore testé vraiment MythTV, je dirais que la principale différence avec Freevo c'est qu'il se configure presque entièrement à partir des menus (à l'opposé de Freevo où il faut modifier les fichiers de config à la main) et qu'il semble accès sur la partage global des ressources de ton PC sur ton réseau.
Un conseil : ne néglige pas le temps de mise en place de ces différentes applis si tu veux donner ton cadeau dans les temps :) (par exemple pour mettre à jour les programmes de TV par nxvtepg ...).
Bon courage.
[^] # Re: Et vous? Comment faites vous ?
Posté par pifou . En réponse à la dépêche Le Patriarche : enfin libre !. Évalué à 1.
Le problème avec cet "technique" c'est que tu ne fais que déplacer le problème de quelques années, tout le gaz carbonique que l'arbre à absorbé pendant ça vie sera tôt au tard repartit dans l'atmosphère après combustion ou décomposisition du papier. Effectivement aujourd'hui en Europe comme on fait pousser plus d'arbre que l'on en coupe (forêt en progression), la pollution engendrée à partir de la combustion/décomposition des arbres diminue (il y a plus d'arbre qui "consomme" le gaz carbonique que d'arbre qui partent en fumé) ... mais ça ne fait que retarder le problème, on ne pourra pas continuer à agrandir les forêt pendants des dizaines d'années. Mais il faut bien avouer qu'actuellement ça peut permettre de limiter la pollution par le gaz carbonique en attendant de trouver mieux ... le problème c'est que si on trouve pas mieux on sera dans la merde :/ (d'autant plus que les arbres n'ont pas une vie illimitée donc ils finiront par ce décomposer même si on ne les utilisent pas).
Il ne faut pas non plus négliger la cout "écologique" de la transformation chimique du bois vers le papier et ensuite à chaque recyclage.
Bref, c'est sûr que c'est moins pire que de jeter des PC à la poubelle (je trouve que le problème ici, c'est la rentabilité du PC, si tu utilises ton PC pendant 5 ans, son cout écologique par jour devient moins important que si tu l'utilises que pendant 1 an avant d'en acheter un nouveau), mais il faut tout de même faire attention à sa consomation de papier.