mais n'y'a't'il pas une commande de plus haut niveau capable de faire la même chose pour les oggs et eventuellement les mpc
j'ai besoin d'obtenir du mp3 128 cbr à partir de :
- mp3 (vbr ou >128)
- ogg
(- mpc)
j'ai tendance à encoder mes cd en ogg (avant je faisais en mp3) ... mais je me retrouve embêté dès que je veux les écouter sur mes lecteurs mp3 (discman et clé usb)
si j'arrivais à faire un script, qui me prennent un peu prêt tout en entrer, et me ressorte du mp3 128 cbr, ce serait le bonheur
> Je peux pas t'aider ..; mes derniers cours d'info remontent
> 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 ...
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 ...
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...
encore un truc que j'ai oublié de préciser et que je voulais faire ... mais le feu de l'action m'a précipité sur le bouton "envoyer"
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 ...
> Pas d'accord. Je viens du monde C et je n'ai eu
> 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 ;-)
ç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é)
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.
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 ...
Bon ... c'est pas mal ...
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 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)
je suis d'accord avec tout ce que tu dis ... en gros ...
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 ...
> 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 ;-)
> Effectivement avant de lire du Ruby il faut connaître c'est quelques spécificités,
ç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 ...
> Mais si c'est aussi facile en Python pourquoi ne pas le faire ?
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 ...
pour info :
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 ...
C'est clair que ça n'a rien à voir avec le C ou le java (à part le OO)
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 ...
> Ce n'est pas une tres bonne idee de comparer Ruby a Python,
> 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)
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 !
> Pour les 'hiéroglyphes', j'aimerais bien des exemples !
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++ ...
> Mais de là à laisser le 'self' comme premier paramètre d'une méthode,
> 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 ...
JAVA, c bien et ça a effectivement fait un peu évoluer les entreprises. C#/dot.net arrive aussi à grands pas (en tout cas chez nous, on y est jusqu'au coup (grande banque)! et pas une goute de java) ...
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 ?
> Avant d'avoir ces extensions, Pyhton ne les avait pas ;)
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 ;-)
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)
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
[^] # Re: Faisons la fête !
Posté par manatlan (site web personnel) . En réponse au journal Adieu au professeur Choron !. Évalué à 2.
[^] # Re: Encodeur LAME
Posté par manatlan (site web personnel) . En réponse au message downgrader en mp3. Évalué à 2.
mais n'y'a't'il pas une commande de plus haut niveau capable de faire la même chose pour les oggs et eventuellement les mpc
j'ai besoin d'obtenir du mp3 128 cbr à partir de :
- mp3 (vbr ou >128)
- ogg
(- mpc)
j'ai tendance à encoder mes cd en ogg (avant je faisais en mp3) ... mais je me retrouve embêté dès que je veux les écouter sur mes lecteurs mp3 (discman et clé usb)
si j'arrivais à faire un script, qui me prennent un peu prêt tout en entrer, et me ressorte du mp3 128 cbr, ce serait le bonheur
[^] # Re: allez ...
Posté par manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 ...
# allez ...
Posté par manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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: Différence avec Python ?
Posté par manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 manatlan (site web personnel) . En réponse à la dépêche Sortie de Ruby 1.8.2. É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 ?