Parmi les nouveautés, citons le nouveau moteur d’expression rationnelles Oniguruma, la gestion de m17n (Multilingualization, notamment une meilleure gestion d'Unicode), l'intégration de RubyGems et de Rake et le remplacement du module CSV par FasterCSV.
Ruby est un langage connu dans le monde des serveurs pour son framework Ruby on Rails ou bien les interpréteurs Ruby dans Java permettant un développement plus rapide. Mais il possède également des bindings pour de nombreuses bibliothèques, dont les plus courantes dans le monde du libre (GTK/Gnome, QT/KDE, Cairo, OpenGL, XML, Curl, SDL, etc.), le rendant également utile pour le développement d'applications de bureau, de jeux, etc.
Un projet récent, Gosu permet par exemple de développer des jeux 2D complets mêlant des effets 3D en quelques centaines de lignes de Ruby, utilisant le moteur physique Chipmunk, l'accélération OpenGL et la puissance, concision et clarté du langage Ruby.
![[en]](../images/en.png)
Ruby 1.9.0 Released (508 hits)-
Changements de Ruby 1.9.0 (460 hits)
-
Benchmark 1.8.5 vs 1.9.0 de février 2007 (445 hits)
-
Gosu (859 hits)
-
Rubyforge, un sourceforge spécialisé Ruby (239 hits)
![[fr]](../images/fr.png)
Ruby France (802 hits)
> Lire la dépêche (83 commentaires, moyenne: 1,7).
Vous avez demandé le commentaire #895258.
Run by 
Cette page a été générée par Templeet en 0.1201s (dont 0.0194 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
troll de noel
Je me suis toujours dis que Ruby faisait double emploi avec python.
Je suis un grand amateur de python, langage à bibliothèque très fournie et à multiple paradigmes, qui permet de décrire des choses assez compliquées en restant très concis, tout en gardant une clarté à le relecture très importante.
Quels sont pour vous les gros points fort de ruby qui pourraient me motiver a regarder ça de plus près?
Je est un autre.
[^]Re: troll de noel
Les avantages sont multiples, en voici une courte liste (non exhaustive) :
- C'est hype
- C'est tendance
- C'est fashion
[^]Re: troll de noel
dur à dire...
j'ai toujours eu du mal avec python. Je trouve que c'est un langage intéressant mais je n'ai jamais pu m'y faire "graphiquement" (et pourtant je trouve le principe de l'indentation forcée dans python très intéressant)
Mais avoir par exemple :
Pourquoi avoir un ':' ?
et surtout, pourquoi autant de fonctions préfixés _et_ postfixé par '__'
et pouquoi self partout ?
(désolé pour les '.' mais je savais pas comment faire plus rapidement ;-))
En ruby on aurait plutôt
Ok, tout ça c'est juste des arguments graphiques. Mais c'est quelque chose qui compte pas mal je trouve dans l'adoption dans langage ou non (après ça dépend aussi des usages qu'on veut en faire...)
En réalité quand j'ai voulu varier de perl, je pensais me tourner vers python. J'ai commencé à regardé et ... bof
J'ai installé ruby et commencé à lire la doc fournie avec et ... cool !
Donc je suis resté sur ruby.
Y'a pas vraiment d'arguments objectifs la dedans...
Disons que ruby permet aussi d'être très concis, mais en étant (de base) très lisible.
Le modèle objet de ruby est, je trouve, l'un des meilleurs que j'ai vu pour le moment (c'est pas parfait, mais bcp mieux que certains autres langages)
Maintenant (et c'est absolument pas un argument) j'ai l'impression que beaucoup plus de personnes utilisant perl se tourne vers ruby plutôt que python.
[^]Re: troll de noel
Pourquoi avoir un ':' ?
Pourquoi avoir un 'end' à la fin des fonctions et classes ?
et surtout, pourquoi autant de fonctions préfixés _et_ postfixé par '__'
Parce que ce sont des fonctions particulières liées au fonctionnement interne de la VM, c'est un moyen de les repérer facilement. En plus c'est esthétique.
et pouquoi self partout ?
Parce que explicit is better than implicit (tape "import this" dans ton interpréteur Python).
j'ai l'impression que beaucoup plus de personnes utilisant perl se tourne vers ruby plutôt que python
Faut dire qu'il faut avoir sacrément mauvais goût pour programmer en Perl :-)
[^]Re: troll de noel
je trouve différent d'avoir ':' et 'end'
le 'end' est remplacé en python par l'indentation. Mais pourquoi le début de la clause / définition non ?
Je pense justement le contraire ;-)
Voici enfin une vrai différence entre python et ruby. Et je crois que je commence à comprendre pourquoi j'aime ruby et non python ;-)
En fait, ce qui fait la force de ruby je trouve (et on peut le voir encore plus dans un framework comme RoR mais c'est pas le seul cas) est de se baser tant que possible sur des conventions, de l'implicite, ... au contraire de python.
Et c'est probablement aussi ça qui fait que ce langage est souvent aimé des utilisateurs de perl (car là niveau implicite...)
M'enfin, je comprend tout de même la volonté d'être explicite. Par contre, de là à passer self dans chaque méthode d'une classe ... vu comme ça on dirait plutôt un mauvais modèle objet... (désolé, mais fallait bien contre balancer la tentative de troll sur perl...)
[^]Re: troll de noel
Par contre, de là à passer self dans chaque méthode d'une classe ... vu comme ça on dirait plutôt un mauvais modèle objet...
Heu, tu sais, le "self" ou "this" ou quelque soit son nom est aussi "passé" dans les autres langages objets... simplement, de façon magique et implicite plutôt qu'explicite.
[^]Re: troll de noel
oui je sais, j'en suis bien conscient (pour le moment j'utilise même un langage où il faut forcément le 'this' pour accéder à un membre) et ça ne me gène pas.
Disons que dans les 2 cas on peut y trouver des avantages
Mais de là à devoir le passer aux méthodes d'une classe... c'est ce point et uniquement celui-ci que je ne comprend pas.
Dans une méthode d'une classe il y a une très très très forte probabilité de devoir utiliser au moins un membre de la calsse et donc de devoir utiliser self dans ce cas. Alors oui, explicite toussa mais là je comprend pas où est l'avantage par rapport à l'implicite... et c'est ce point qui donne une mauvaise impression sur le modèle objet de python (note : je parle bien d'impression, j'y connais pas assez en python pour descendre le modèle objet en lui-même...)
[^]Re: troll de noel
Il ne faut pas le passer aux méthodes de classe soit même en temps normal; C'est fait implicitement lorsque tu appelle ta méthode avec
ton_objet.ta_methode()C'est seulement à la définition que tu doit juste rajouter self en premier dans la liste des argument, ou lorsque tu appelle une méthode d'une classe de base.[^]Re: troll de noel
Allez, un truc amusant que je viens juste de découvrir:
>>>class Spam:
...a = 5
...
>>>def egg(self):
...print self.a
...
>>>x = Spam()
>>>Spam.egg = egg
>>>x.egg()
5
>>>egg(x)
5
Plus sérieusement, le "instance comme argument", à l'utilisation, ça permet de rester cohérent sans introduire de syntaxe magique. Par exemple, supposons que a soit une instance de la classe A, qui hérite de la classe B, qui définissent tous deux une méthode foo. En C++, pour appeler le foo de B, tu aurais une syntaxe magique (de mémoire, ça fait un moment que j'ai plus fais de C++) et absolument immonde du type: a::B.foo(). En python, tu restes cohérent: B.foo est une fonction, tu as juste à l'appeler comme n'importe quelle fonction: B.foo(a).
Autre avantage, si tu prends x = [a1,a2,a3] (trois instances de A) et que tu veux appeler foo sur ces trois, tu as juste à faire map(A.foo, x): cela va donner [A.foo(a1), A.foo(a2), A.foo(a3)], ce qui, grace à l'argument explicite, est équivalent à [a1.foo(), a2.foo(), a3.foo()]
Autre avantage (le principal IMHO), l'instance passe très bien à travers les arguments du type *args ou **kwargs (l'équivalent, en plus puissant, des ... du C, comme avec printf). Ou à travers des décorateurs.
Enfin, ce n'est pas parce qu'une fonction est dans une classe que c'est une méthode d'instance (méthode de classe/statique). Là où un autre langage demanderait probablement "yet another keyword", en python, ça se fait par un décorateur tellement basique que n'importe quel pékin peut écrire soit même si ça le chante (il y en a un "standard", mais pour t'illustrer à quel point ça évite les cas et les constructions particuliers, je vais le faire moi-meme):
>>> def classmethod(meth):
... def call(*args, **kwargs):
... return meth(args[0].__class__, *args[1:], **kwargs)
... return call
...
>>> class Spam:
... @classmethod
... def hello(klass, who):
... print "Hello, %s (from %r)" % (who, klass)
...
>>> s = Spam()
>>> s.hello("world")
Hello, world (from <class __main__.Spam at 0xb7c6b7dc>)
[^]Re: troll de noel
ok, je comprend mieux.
Mais bon, ça reste une manière étrange de faire, et surtout assez contraingnante je trouve (le fait de _devoir_ le mettre dans les définitions de méthode)
Et pourtant, on peut faire le même effet mais sans se prendre la tête à la définition : MyClass.myFunc.call(x, args)
C'est une autre façon et qui ne nécessite pas de passer self (et en plus c'est plus explicite que python puisqu'on rajoute call ;-) )
Par contre, le coup de map(A.foo, x) est assez intéressant.
Par contre, des derniers exemples illustrent tout à fait ce que je pense de python : c'est pas beau ;-)
entre les __ et les ** ... beurk
Bon ok dans ruby il y a @, mais en parlant de beauté on est clairement dans le subjectif...
[^]Re: troll de noel
> Et pourtant, on peut faire le même effet mais sans se prendre la tête à la définition : MyClass.myFunc.call(x, args)
Hmmm, marche pas ici:
class Foo
def bar(args)
print args + "\n"
end
end
f = Foo.new()
Foo.bar.call("hello, world")
$ ruby test.rb
test.rb:8: undefined method `bar' for Foo:Class (NoMethodError)
> et en plus c'est plus explicite que python puisqu'on rajoute call ;-)
Si tu insistes, tu peu rajouter un __call__ en python... Mais je doute que tu apprécies, vu ta réaction aux __ :)
> Bon ok dans ruby il y a @, mais en parlant de beauté on est clairement dans le subjectif...
J'ai vu vraiment très peu de ruby, mais du peu que j'ai vu, je t'accorde le côté plus agréable à l'œil. Mais j'aime beaucoup moins des choses comme la différentiation entre méthode/fonction/attribut. En python, méthode et fonction, c'est la même chose (d'où le self explicite), et mieux, une méthode n'est qu'un attribut comme un autre (getattr et setattr fonctionnent aussi avec les méthodes ! Une méthode n'est qu'un attribut possédant lui même un attribut __call__). Ça a un côté "unification" que je ne retrouve pas en ruby (mais peut être que cela vient du fait que je n'en ai pas fait assez ?)
Sinon, par simple curiosité, comment fait ruby pour un nombre variable d'arguments ? (le *args de python)
[^]Re: troll de noel
oups, désolé le "MyClass.myFunc.call" était pas du ruby du tout ;-) (du javascript en fait) Désolé pour la confusion.
vi, rajouter un __call__ ... c'est moyen je trouve. Ou plutôt ça doit rester du code "interne"
Concernant les méthodes, attributs, ... Une méthode et un attribut c'est normale que ce ne soit pas pareil
Mais en fait ça dépend comment on fait ;-)
Un attribut est par défaut uniquement privé (et ça c'est le bien)
Mais on peut évidemment le rendre public.
Et on peut également définir les méthodes d'accès aux attributs, mais ces méthodes on l'énorme avantage (selon moi) de se comporter de l'extérieur comme si on accédait directement à l'attribut (pas de get...() set...(value) tout pas beau et lourd)
ex :
$ cat test.rb
class MyClass
attr_accessor :myAttr
def myAttr=(value)
@myAttr = "myAttr is set to #{value}"
end
def myAttr
print @myAttr + "\n"
end
end
obj = MyClass.new
obj.myAttr = 2
obj.myAttr
$ ruby test.rb
myAttr is set to 2
def myFunc(*args)
print args.join(", ")
end
myFunc(1, 2, 3, 4)
1, 2, 3, 4
[^]Aors ? enfin des destructeurs ???
Alors, j'ai failli me mettre à Ruby : j'ai commencé un truc en Ruby pour essayer, je m'y suis mis super-vite, j'ai trouvé ça joli, sympa... et puis j'ai eu besoin d'un destructeur. Donc, j'ai tout jeté et j'ai arrêté définitivement Ruby (à moins qu'il n'existe vraiment un jour des destructeurs).
J'ai envisagé de me mettre à Python (pour écrire du code un peu plus abordable pour le commun des mortels, en particulier pour mes collègues), mais l'idée de devoir écrire du code genre
variable_avec_un_nom_significatif = variable_avec_un_nom_significatif + 1
parce que le concepteur estime que l'opérateur ++ est une complexité superflue, ça me bloque.
Plus joli que celui de Perl 5, OK. Mais l'un des meilleurs, rappelez-moi quand il incluera les destructeurs ! Je préfère largement un modèle objet un peu moche à un modèle objet limité.
Pas la peine de me dire pour la n-ième fois qu'il suffit d'utiliser les fermetures, ça n'a rien à voir, il faut le faire à l'utilisation des objets et non pas à la définition d'une classe : à ce stade-là, il faudrait, au lieu de définir une variable au début d'un bloc, passer systématiquement le bloc en paramètre au constructeur de la variable, au cas où l'on s'aperçoive ultérieurement qu'on a une finalisation à faire sur ce type d'objet. Et là, comme lisibilité de code, il y aura de quoi envier Perl !!!
Ah, j'ai failli passer sur le fait que les end, c'est naze, parce que c'est moins facile pour déterminer à quoi il correspondent (notamment quand on s'aperçoit qu'on en a oublié un quelque part) qu'avec une indentation comme Python ou des accolades comme Perl ou le C/C++ (de nombreux éditeurs, quand on passe sur une accolade, surlignent l'autre accolade correspondante).
« Ils font la fête au mois de juillet,
en souvenir d'une révolution,
qui n'a jamais éliminé
la misère et l'exploitation. »
Renaud, Hexagone
[^]Re: Aors ? enfin des destructeurs ???
J'ai envisagé de me mettre à Python (pour écrire du code un peu plus abordable pour le commun des mortels, en particulier pour mes collègues), mais l'idée de devoir écrire du code genre
variable_avec_un_nom_significatif = variable_avec_un_nom_significatif + 1
parce que le concepteur estime que l'opérateur ++ est une complexité superflue, ça me bloque.
Bah, tu peux utiliser la methode __iadd__ :
variable_avec_un_nom_significatif += 1
[^]À propos de Python
Merci de l'info.
C"est récent, cette possibilité (moins de quelques années), ou c'est la doc que j'avais trouvée quand j'avais essayé Python qui était toute pourrie ?
« Ils font la fête au mois de juillet,
en souvenir d'une révolution,
qui n'a jamais éliminé
la misère et l'exploitation. »
Renaud, Hexagone
[^]Re: À propos de Python
Ca date de python 2.0:
http://www.python.org/dev/peps/pep-0203/
donc grosso merdo 2000~2001.
[^]Re: À propos de Python
Il me semble que j'avais essayé un peu après ça, mais la doc que j'avais trouvée n'était peut-être pas hyper à jour...
Existerait-il une doc (à peu près à jour...) genre "Python en 30 mn pour ceux qui programment déjà dans un langage de script" ?
(Ce n'est pas que je ne pourrais pas chercher moi-même, c'est juste que si je tombe aussi bien que la dernière fois...)
« Ils font la fête au mois de juillet,
en souvenir d'une révolution,
qui n'a jamais éliminé
la misère et l'exploitation. »
Renaud, Hexagone
[^]Re: À propos de Python
Existerait-il une doc (à peu près à jour...) genre "Python en 30 mn pour ceux qui programment déjà dans un langage de script" ?
Le tutorial officiel :
http://docs.python.org/tut/tut.html
La documentation officielle des types intégrés et des modules standard :
http://docs.python.org/lib/lib.html
Il y a aussi Dive Into Python, qui commence à dater (2004) mais fournit une bonne introduction :
http://www.diveintopython.org/
[^]Re: À propos de Python
Python précis et concis :
http://www.oreilly.fr/catalogue/2841773604
qui couvre 2.4 et qui est très concis, donc n'explique rien au pourquoi du comment, mais qui donne la syntaxe et les fonctions de base du langage et les modules principaux (os, string, sys, ...).
[^]Re: Aors ? enfin des destructeurs ???
Le problème c'est que avec un GC tu n'as pas vraiment de controle sur le moment de destruction de tes objets comme en C++ .
Java non plus ne garantissait pas l'appel des destructeurs avant la fin du programme jusqu'à la version 1.5 (a verifier).
[^]Re: Alors ? enfin des destructeurs ???
J'en suis conscient. La conclusion logique est de ne pas utiliser un GC.
Sur le coup, j'ai presque failli me lancer à faire un fork de Ruby avec un comptage de références et des destructeurs (mais bon, je me suis assis et j'ai attendu que ça passe ;-) ).
Bon, Perl 6 est sensé avoir un GC et des destructeurs. J'ai jeté un coup d'oeil à la description du principe, ça a l'air complexe, voire lourd, donc j'attends de voir (et dans le doute, je suis peut-être le perliste le moins impatient de la sortie de Perl 6)...
« Ils font la fête au mois de juillet,
en souvenir d'une révolution,
qui n'a jamais éliminé
la misère et l'exploitation. »
Renaud, Hexagone
[^]Re: Alors ? enfin des destructeurs ???
Sur le coup, j'ai presque failli me lancer à faire un fork de Ruby avec un comptage de références et des destructeurs
Tu peux réessayer Python, qui a un comptage de références et des destructeurs et un détecteur de cycles pour compléter le boulot ;-)
(et si tu te lasses des destructeurs il y a aussi les weakref avec callback optionnel)
Pour répondre à ton autre message, pouvoir écrire "x += 1" en Python est tout de même assez vieux...
[^]Poster du code
http://linuxfr.org/tips/572.html
Jeu thématique : le recoder en Ruby (ça ne doit pas être très difficile).
« Ils font la fête au mois de juillet,
en souvenir d'une révolution,
qui n'a jamais éliminé
la misère et l'exploitation. »
Renaud, Hexagone
[^]Re: troll de noel
Moi, pour avoir fait du python, on peut dire que j'apprécie ce langage (le principe d'indentation est génial), mais plusieurs choses mon embétté :
- langage pas fortement typé : quoi de plus destabilisant qu'une fonction qui prend un paramètre dont le nom est pas très explicite et dont on connais pas le type... Je trouve abérrant de devoir parfois tester si le retour d'une fonction est une liste, une chaine ou autre... De plus, ça limite forcément l'autocomplétion, et ça, c'est un gros défaut !
- la doc est fouilli... trouvé quelque chose n'est pas toujours simple. Comparé avec la doc de Qt ou de Java, et on voit clairement que c'est pas pratique (surtout quand il n'y a pas d'autocompletion)
- beaucoup de reste d'un langage pas objet à la base
- de même, j'ai tendance a oublier les self....
Bref, en fait la seul chose que j'aimerais ça serait d'avoir un typage obligatoire... Et donc permettre une bonne autocomplétion (pour l'instant le seul IDE que je connais qui autocomplète le python c'est Eclipse+Pydev)
Je ne connais absolument pas Ruby, ça répond à quelques un de ces points ? Ou alors Python va-t-il s'améliorer avec Py3k ?
[^]Re: troll de noel
> quoi de plus destabilisant qu'une fonction qui prend un paramètre dont le nom est pas très explicite et dont on connais pas le type...
Normalement, les types possibles des paramètres et des valeurs de retour doivent être documentés. Après, c'est certain que le langage n'interdit personne à mal coder, hein :)
> la doc est fouilli... trouvé quelque chose n'est pas toujours simple. Comparé avec la doc de Qt ou de Java
La doc de Qt, je ne sais pas. J'en ai entendu beaucoup de bien, même si je l'ai jamais essayée moi même. Mais honnêtement, ma maigre expérience de Java a été un cauchemar au niveau documentation en ligne (peut être que la doc intégrée aux IDEs est meilleure...). Honnêtement, je vois très mal comment préférer http://java.sun.com/j2se/1.4.2/docs/api/ à http://docs.python.org/
> - beaucoup de reste d'un langage pas objet à la base
Pardon ???
Il va falloir epliquer plus profondément que ça. Quand tu sais que même les modules, les classes et les fonctions sont des objets, je vois mal ce qu'il te manque ;)
>- de même, j'ai tendance a oublier les self....
Ça m'a pris quelques mois pour attraper le réflexe, mais c'est vrai que c'est dur, au début ;)
> Bref, en fait la seul chose que j'aimerais ça serait d'avoir un typage obligatoire
Tu enlèves là un gros avantage du langage. Même si dans, disons, 80% des cas, le type est connu à l'avance, le typage fort (ou, le typage de python est fort) dynamique est carrément jouissif dans les 20% autres cas (surtout quand tu penses au nombre de lignes supplémentaires que ça aurait pris dans un langage à typage statique). Certaines choses que j'ai faites proprement en Python en quelques lignes grâce à ce typage dynamique m'auraient prises plusieurs fichiers et une bonne centaine de lignes en Java.
> Ou alors Python va-t-il s'améliorer avec Py3k ?
Pour l'autocompletion, un truc asez intéressant va arriver dans Python 3k: la possibilité d'annoter les fonctions. Par exemple, les définitions suivantes deviennent valide en Python 3000:
def compile(source: "something compilable",
filename: "where the compilable thing comes from",
mode: "is this a single statement or a suite?"):
def haul(item: Haulable, *vargs: PackAnimal) -> Distance:
Par défaut, l'interpréteur n'en fait rien, mais on peut très bien l'utiliser comme:
- documentation
- dire quels types sont supportés
- vérification de type à l'aide d'un décorateur
Après, il faut bien sûr que les IDEs en tirent partie. Mais c'est là une autre histoire :)
Et ruby répond à ton problème du self ;)
[^]Re: troll de noel
Effectivement, ce sont des langages qui sont assez proches, je me suis toujours dit que Python faisait double emploi avec Ruby (ok j'arrête le troll ... :p)
Sinon, plus sérieusement, les trucs que j'apprécie par rapport à python :
_ au niveau POO, c'est plus propre :
- pas besoin que le premier argument de chaque fonction d'une classe soit "self"
- pas besoin de dire à chaque fois self.bidule, self.truc, pour accéder aux attributs
- tout est objet : -199.abs en ruby, abs(-199) en python
- l'encapsulation : on ne laisse pas d'attribut accessible par défaut. (je sais pas comment fait python, tout est accessible non?)
_ la programmation par blocks (un délice)
_ la création de wrapper de bibliothèques C est franchement pas dur. (je sais pas ce qu'il en est en python?)
_ support natif des expression régulières (comme en perl)
_ syntaxe non basée sur l'indentation (je préfère)
Enfin,globalement, ils sont assez similaires en syntaxe, et c'est assez facile de passer de l'un à l'autre. Moi je le trouve plus clair et plus propre, plus agréable à lire et à écrire.
[^]Re: troll de noel
-199.abs en ruby, abs(-199) en python
Oh, tu peux écrire (-199).__abs__() si ça te chante....
D'ailleurs la fonction abs() est elle-même un objet (comme tout en Python), donc dire que Python n'est pas objet parce qu'il y a des fonctions est un peu bidon...
_ la création de wrapper de bibliothèques C est franchement pas dur. (je sais pas ce qu'il en est en python?)
En Python tu peux utiliser Pyrex, ou bien ctypes, ou bien swig, ou bien tout faire à la main.
[^]Re: troll de noel
Pourquoi il faut ajouter les __ dans la deuxième version en Python?
[^]Re: troll de noel
Pourquoi il faut ajouter les __ dans la deuxième version en Python?
Précisément parce que tu n'es pas censé appeler cette méthode toi-même mais utiliser la fonction abs() à la place ;)
Python essaie de séparer protocole interne et API publique :
- le protocole interne, c'est mon_entier.__abs__()
- l'API publique, c'est abs(mon_entier) qui appelle en sous-main la méthode mon_entier.__abs__()
Dans un cas simple on ne voit pas trop la différence, mais ça se justifie dans des cas plus complexes (par exemple la transformation en chaîne unicode via unicode(objet) peut appeler objet.__str__() ou objet.__unicode__() selon que l'un ou l'autre est défini).
C'est utilisé aussi pour les opérateurs. Par exemple "a + b" appelle a.__add__(b).
[^]Re: troll de noel
_ la création de wrapper de bibliothèques C est franchement pas dur. (je sais pas ce qu'il en est en python?)
En Python tu peux utiliser Pyrex, ou bien ctypes, ou bien swig, ou bien tout faire à la main.
ou boost.
phil.freehackers.org
[^]Re: troll de noel
Je me suis toujours dis que Linux faisait double emploi avec MS Windows. Tu saisis maintenant le ridicule de ton propos ?
Si tu aimes python et ne te sens pas limité dans tes actions, pourquoi changer ?
Si tu veux en apprendre plus sur Ruby, essaye.
Demander à quelqu'un de te motiver à y regarder de plus près, c'est déja perdu d'avance.
[^]Re: troll de noel
>Je me suis toujours dis que Ruby faisait double emploi avec python.
Je suis plutôt d'accord: quand je recherchais un nouveau langage (dégoutté de Perl), apres avoir tenter et rejeter Ocaml, j'ai été bien perplexe pour choisir entre Python et Ruby car je trouve ces langages très semblable..
Mais au final je préfère la syntaxe de Ruby a celle de Python, donc pour moi c'est Python qui fait double emploi avec Ruby pas le contraire..
:-)
[^]Re: troll de noel
Hé, non, OCaml, c'est le language le plus mieux sur la terre, tu as du faire une erreur ;-) (sauf pour les bibliothèques, et par défaut, le manque de syntaxe pour regexp et try...finally, mais pour ces deux choses, y'a des extentions de syntaxe très bien).
[^]Re: troll de noel
Il y a principalement deux choses que je n'aimais pas avec OCaml:
- l'accent mis sur le coté fonctionnel: pour un langage soi-disant multi-paradigme, le manuel (soit dit en passant le manuel était en Français, c'est rare) mettait bien trop l'accent sur le coté fonctionnel a mon gout..
- la syntaxe, et apparemment je ne suis pas le seul a ne pas l'aimer car il y en a une autre qui existe et Microsoft pour faire F# en a pris encore une autre (qui a l'air pas mal du tout celle la)..
Donc ces obstacles m'ont rebuté pour apprendre le langage, mais je ne considère pas pour autant qu'OCaml soit un mauvais langage, juste pas interressant pour moi (par contre je considère Perl5 comme un mauvais langage)..
[^]Re: troll de noel
Pour ma part, des deux langages j'ai commencé par testé python, que j'ai de suite trouvé trés sympa, mais je n'ai jamais fais une ligne de code utile avec, vas savoir pourquoi.
Puis j'ai testé rails, et je suis venue naturellement à ruby, et la boum paf, la claque, ruby powa, je me suis amusé à refaire des scripts perl en ruby, et à la lecture, reclaque, c'est fluide court et tout aussi efficace.
Je sais pas pourquoi mais ruby est pour moi bien plus agréable que python.
tes tournures de phrases ne vallent pas la verité de tes actes
[^]Re: troll de noel
En ce qui me concerne je suis tombé dans python depuis quelques années et comme pour la drogue c'est pas facile de décrocher. Pour ruby ca fait déjà trop longtemps que c'est marqué "essayer ruby" sur ma todo-list...
Pour moi un des points forts de ruby c'est Rails: il s'agit clairement du framework mvc le plus avancé. Après avoir bien joué avec Django j'ai de plus en plus envie de gouter à Rails, car il dispose de certaines fonctionnalités uniques.