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. Ruby est un langage intéressant pour le prototypage. Sa syntaxe concise permet un developpement rapide d'application, on peut ensuite convertir les parties les plus gourmandes en C afin d'obtenir de meilleures performances.
Aller plus loin
- Ruby 1.9.0 Released (10 clics)
- Changements de Ruby 1.9.0 (15 clics)
- Benchmark 1.8.5 vs 1.9.0 de février 2007 (14 clics)
- Gosu (15 clics)
- Rubyforge, un sourceforge spécialisé Ruby (10 clics)
- Ruby France (6 clics)
# Version pour tout le monde ou uniquement pour les developpeur de Ruby?
Posté par reno . Évalué à 4.
[^] # Re: Version pour tout le monde ou uniquement pour les developpeur de Rub
Posté par reno . Évalué à 2.
[^] # Re: Version pour tout le monde ou uniquement pour les developpeur de Rub
Posté par Guillaume Laville . Évalué à 3.
Depuis quelques mois, Matz a changé la politique de sortie et abandonné la numérotation paire/impaire.
Normalement, c'est la version 1.9.1 qui devait sortir pour Noël, qui sera une version pratiquement stable. Etant donné les soucis de stabilité jusqu'a tout dernierement, c'est une version 1.9.0, preview, qui l'a remplacée.
Le but est de permettre au maximum de monde de commencer à mettre à jour ses extensions et jouer avec les nouvelles fonctions fournies : L'utilisation des 1.9.x reste déconseillée en production.
# troll de noel
Posté par Pierre . Évalué à 1.
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?
[^] # Re: troll de noel
Posté par Axel . Évalué à 3.
- C'est hype
- C'est tendance
- C'est fashion
[^] # Re: troll de noel
Posté par CrEv (site web personnel) . Évalué à 3.
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
Posté par Antoine . Évalué à 1.
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
Posté par CrEv (site web personnel) . Évalué à 2.
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
Posté par Antoine . Évalué à 2.
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
Posté par CrEv (site web personnel) . Évalué à 2.
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
Posté par Batchyx . Évalué à 2.
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
Posté par Moonz . Évalué à 2.
>>>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
Posté par CrEv (site web personnel) . Évalué à 2.
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
Posté par Moonz . Évalué à 2.
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
Posté par CrEv (site web personnel) . Évalué à 2.
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 ???
Posté par Arthur Accroc . Évalué à 1.
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).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Aors ? enfin des destructeurs ???
Posté par Sebastien . Évalué à 2.
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
Posté par Arthur Accroc . Évalué à 1.
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 ?
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: À propos de Python
Posté par Sebastien . Évalué à 1.
http://www.python.org/dev/peps/pep-0203/
donc grosso merdo 2000~2001.
[^] # Re: À propos de Python
Posté par Arthur Accroc . Évalué à 1.
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...)
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: À propos de Python
Posté par Antoine . Évalué à 3.
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
Posté par H_francis . Évalué à 1.
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 ???
Posté par Hank Lords . Évalué à 1.
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 ???
Posté par Arthur Accroc . Évalué à 1.
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)...
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: Alors ? enfin des destructeurs ???
Posté par Antoine . Évalué à 2.
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
Posté par Arthur Accroc . Évalué à 1.
http://linuxfr.org/tips/572.html
Jeu thématique : le recoder en Ruby (ça ne doit pas être très difficile).
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
[^] # Re: troll de noel
Posté par HoloAddict (site web personnel) . Évalué à 1.
- 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
Posté par Moonz . Évalué à 2.
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
Posté par Youx . Évalué à 2.
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
Posté par Antoine . Évalué à 2.
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
Posté par reno . Évalué à 2.
[^] # Re: troll de noel
Posté par Antoine . Évalué à 2.
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
Posté par Philippe F (site web personnel) . Évalué à 1.
_ 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.
[^] # Re: troll de noel
Posté par Psychofox (Mastodon) . Évalué à 3.
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
Posté par reno . Évalué à 3.
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
Posté par TeXitoi (site web personnel) . Évalué à 1.
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
Posté par reno . Évalué à 2.
- 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
Posté par nanard . Évalué à 2.
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.
Allez tous vous faire spéculer.
[^] # Re: troll de noel
Posté par _p4_ . Évalué à 3.
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.
# Python
Posté par Julien . Évalué à 1.
Quelques critiques à propos de Ruby (je n'ai pas testé la version 1.9):
- C'est très lent (mais cette critique semble tomber à l'eau avec la version 1.9). Il est vrai que la vitesse d'exécution n'est pas primordiale dans ce genre de langage (Perl, Python, Ruby, ...) ... mais il y a des limites.
- Pas de support de l'Unicode, qui est pour moi _le_ plus gros problème de Ruby.
- J'ai retrouvé beaucoup de truc que j'aimais pas en Perl (notamment les variables @, ...), le langage est un peu "fouilli".
- Pas de multihéritage (mais on dirait que c'est le truc du moment à proscrire..)
Quelques avantages de Python:
- La librairie de base est bien plus fournie que celle de Ruby.
- Langage clair, propre et simple, et surtout qui ne change pas à chaque version (à l'exception de Python 3000), comme en Perl ou PHP. Je suis presque sur qu'un programme écrit il y a 10 ans tourne sans modifications sur les WM actuelles.
- La "communauté" Python met en place des petits "standard" (les PEP) légers comme DBAPI, WSGI, ...
- "There is only one way to do it"
Et puis on trouve vraiment d'excellentes libraires comme Pylons, SQLAlchemy, Genshi, ... on a vraiment plus de choix qu'en Ruby.
Les principales critiques que j'entends toujours à propos de Python:
- L'indentation: on aime ou on aime pas..
- Il faut mettre "self" partout: oui, "explicit is better than implicit". Je trouve ça plus lisible d'accéder à une variable (ou méthode) de l'objet via "self.x" plutot que betement "x"
- Il n'y a pas de support des variables privées: oui et non. On peut créer des variables à peu près privée avec __foo, mais la philosophie de Python est plutot "si vous ne voulez pas accéder à une variable privée, n'y accéder pas et puis c'est tout". De plus ce n'est, pour moi, pas le plus important en POO. Quand on regarde la majorité des programmes Java, on a en général un setVariable() et un getVariable() qui contiennent en général une ligne avec une assignation pour le premier et un return pour le 2ème .. De plus Python a un concept de "properties" (ala C#) qui permet de faire ça de manière élégante.
Pour finir, je me demande aussi si Ruby aurait autant de succès aujourd'hui si Ruby on Rails n'avait pas existé (... d'ailleurs je me demande toujours comment ce framework a autant de succès tant il est inintéressant et mal foutu ...)
[^] # Re: Python
Posté par reno . Évalué à 2.
Bin d'après la nouvelle c'est aussi dans la 1.9 (cf la partie sur m17n) mais je n'ai pas réussi a trouver l'info dans le changelog..
Ceci dit tant que ce n'est pas dans une version stable, ça ne fait pas trop avancer le schmilblick..
Sinon le @ de Ruby n'a rien a voir avec le @ de Perl, donc je ne vois pas pourquoi tu les compare.
Je fais partie de ceux qui trouve que les self partout c'est laid: le concept "explicit is better than implicit", si tu l'applique jusqu'au bout tu programmes sans GC, voire en assembleur(!), ce qui montre bien, qu'il faut être sélectif dans son application..
Pour ta question, oui Ruby avait du mal a décoller avant RoR, mais ce qui fait la force de RoR c'est Ruby..
[^] # Re: Python
Posté par Julien . Évalué à 1.
[^] # Re: Python
Posté par Gniarf . Évalué à 2.
[^] # Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . Évalué à 0.
Les données de Harr disent :
- le nombre d'instruction par jour est le même par développeur quelque soit le langage utilisé ;
- certains langage sont plus concis que d'autres (à condition de coder dans le langage);
De mêmoire si le C est une base référence :
C++ => 1,5 x plus concis
java VB => 2
perl/php/ruby/python => 6
à coté de ça :
le nombre de bug augmente plus que linéairement avec la taille, ainsi que le temps de développement
Conclusion
tout langage suffisamment concis devrait être favorisé.
Après tous les langages se valent tant que on respecte l'esprit de concision pour son problème :
C'est une question de goût et de contexte. Après le one best way to do it, est une erreur car tous les problèmes ne sont pas isomorphes. Si vous préférez un même chapeau ne va pas à tout le monde : on va pas sur un chantier avec un stetson, et au soleil avec un casque de chantier ...
Je préfère le perl ^^ parce que c'est concis est que l'on peut écrire littérairement du code. Pour moi le code est une rédaction littéraire que j'ai besoin de comprendre pour le relire, le modifier. En plus je me sens à l'aise car comme en français, j'ai la possibilité de pouvoir développer un style. Un programme, est une dissertation qui répond à la question comment résoudre tel problème. Nos codes doivent répondre à la question de la manière la plus lisible selon le style de l'auteur.
Chacun sa manière de coder, moi je code pas, je raconte une histoire, avec un argot, des tournures littéraires, en empruntant les meilleurs mots des autres, et ça m'éclate.
Tant que je m'éclate je continuerais à faire ce boulot, et je conçois que comme certains préfèrent le français à l'italien ou l'anglais à l'allemand on puisse se taper dessus pour des langages. Et c'est pour ça que j'adore les trolls de langage, ça reste des discussions de personne qui aiment au delà des langages la littérature.
Bref python, et ruby sucent des ours, le perl les écrase. Pas de troll ni de mauvaise foi, juste une constatation objective.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par H_francis . Évalué à 1.
C'est certain que c'est plus facile d'écrire un code horrible en perl qu'avec python. Je comprends donc votre aversion pour python. Félicitation pour cette conclusion.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . Évalué à 0.
Il y a toujours des personnes pour se faire avoir <:o)
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par nanard . Évalué à 1.
Encore un nouveau troll ? wouha t'est doué :)
Allez tous vous faire spéculer.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . Évalué à 1.
J'assume préféré des langages, mais je ferais jamais croire que des critères subjectifs valent pour tout le monde.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . Évalué à 1.
la variation en productivité et en qualité, liées aux développeurs est supérieure à celle liées aux techniques informatique et managériale ou autres.
Un bon développeur fera toujours du bon code quelque soit le langage.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par reno . Évalué à 2.
Certes mais il n'apprécie pas pour autant forcément le langage..
Je me considère comme un bon programmeur, je connais suffisamment de Perl pour faire des programmes propres (c'est à dire qui fonctionnent et qui soient compréhensibles*), mais je peux te dire que quand je dois programmer en Perl, qu'est-ce que je peut le maudire ce langage!
Le coup des tableaux qu'il faut passer par référence a une fonction pour qu'on puisse récupérer leur contenu sans les mélanger et bien d'autres trucs me dégoute..
(*) enfin autant que possible avec ce langage..
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . Évalué à 0.
Au final, ma philosophie est que plus on me paie cher pour écrire dans un langage plus je suis volontaire pour le faire. C'est à mon avis le critère de choix pour utiliser un langage.
Ce qui fait que j'utilise presque tous les langages du marché et je ne les trouve pas foncièrement différents ; les erreurs dans les programmes sont plus souvent -à mon expérience- dans la conception d'une solution ou dans le choix de mauvais développeurs, que dans le choix, ou dans la syntaxe du langage.
Si vous préférez le langage est au développeur ce que le marteau est au menuisier. Rien qu'un truc, un machin, un outil. Sûrement pas le principal quoi. Donc un troll sur les langages qui n'est pas pour le fun, est un sujet de personne qui sont des esthètes de l'informatique, et entre nous un bon informaticien n'est pas là pour aimer l'informatique, il est là pour apporter des solutions. Et c'est pas avec le langage informatique, mais avec sa cervelle qu'on travaille.
Pour résumé : troll de langage = truc de geeks. Et je suis loin d'être convaincu qu'un geek ça fasse un bon développeur.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Yusei (Mastodon) . Évalué à 4.
En une heure de temps, la cervelle peut résoudre un nombre limité de problèmes. Selon les cas, la cervelle peut travailler à résoudre le problème sur lequel elle travaille, ou bien travailler à résoudre les problèmes posés par son outil. L'informaticien est donc plus efficace lorsque son outil n'oblige pas sa cervelle à penser à l'outil, mais la laisse se concentrer sur le problème réel.
Je préfère Ruby à Perl parce que j'ai moins besoin de réfléchir à son fonctionnement (et je préférais Perl à C pour les mêmes raisons). Je n'ai pas à me souvenir si le nom de ma variable doit commencer par un $, un % ou un @, si je dois utiliser des crochets ou des accolades, comment sont automatiquement convertis les types, etc. De nombreuses fois, plutôt que d'ailler regarder dans l'API comment on fait une chose, je l'ai écrite comme je pensais que ça devrait s'écrire... et ça a marché.
Pour reprendre ton argument, je pourrais dire qu'un bon mathématicien n'est pas là pour aimer les mathématiques, mais pour trouver des théorèmes. Ce n'est pas avec un formalisme qu'on travaille, mais avec sa cervelle. Par conséquent, il ne sert pas à grand chose de développer de nouveaux formalismes équivalents à des formalismes existants. Par exemple, le lambda calcul ne sert à rien puisqu'il est équivalent aux machines de Turing.
Et pourtant, en formulant les choses différemment, on peut parfois trouver une solution plus facilement. Quand il est difficile/pénible d'exprimer un concept dans un langage, on ne peut pas attendre du programmeur d'utiliser ce concept naturellement. Ce n'est pas qu'une histoire de concision.
Évidemment, la plupart des langages de programmation visent l'universalité, et donc essayent d'incorporer le plus possible de concepts. Ce n'est pas pour cela que ces concepts sont naturels, et ce n'est pas suffisant pour conclure que tous les langages se valent.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . Évalué à 1.
En fait, perl, php, ruby, pyhton sont équivalents en concision car ce sont des langages à typage dynamique. (cf complete coding / Steve Mc Connell)
La plus grande force d'un langage ne réside pas dans sa syntaxe ou ses structures de contrôles, mais dans les données. Plus les types de bases sont intéressants (comme la hashtable) plus leur manipulation est aisé (GC inclus) plus le langage est concis.
Et en plus tu réduis le développement au code or comme la doc de sloccount l'exprime si bien
http://www.dwheeler.com/sloccount/sloccount.html#cocomo
qui reprend les données de Harr/boehm : coder est une part minimal du développement.
Le reste c'est du déboguage, de la conception, de la compréhension du problème, de la doc, de la négociation ... Et même dans le déboguage la partie facteur humain passe devant le code. Alors comme notre boulot est minoritairement de coder, je vois pas pourquoi le langage est si important.
Remarque même si j'ai plus de plaisir à prendre un langage que j'aime comme tout le monde, le plaisir, le goût sont quand même pas des critères objectifs et absolus, ou alors j'ai loupé un cours de français. Donc pourquoi imposer son langage préféré alors que pour le client ça change rien d'autre que des emmerdes à devoir gérer un langage en plus.
Mais bon ton analogie avec les maths est bonne, car je viens de la physique, et je te laisse imaginer que je conçois que les langages informatiques sont à l'informatique réel, ce que les maths sont à la physique. Utile, mais pas ma tasse de thé. Je trouve que les matheux sont nécessaires, mais qu'ils ont rarement la structure de pensée pour résoudre un cas pratique réel. Bref un matheux a pour moi autant d'intérêt en physique qu'un amoureux des langages en informatique de production : c'est un idéologue au milieu d'un environnement de travail, une gêne quoi. Exactement ce que tu prouves en prenant une analogie sur des maths : que t'es pas orienté résolution de problèmes, mais esthète des technologies créateur de discussions infinies sur des coupage de poils de fesse en 4.
Bref, à mon avis, je crois que t'a pas compris notre métier.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Yusei (Mastodon) . Évalué à 3.
Le langage est important justement parce que j'ai autre chose à faire que de coder. Je n'aime pas coder.
Elle est bien bonne, celle là. Au passage, je doute fort que nous ayons le même métier.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Antoine . Évalué à 3.
Le deuxième problème c'est que bien faire son métier c'est aussi se préparer à l'avenir et améliorer son efficacité en se frottant à de nouvelles méthodes, de nouveaux outils. "Satisfaire le client" en faisant la maintenance de programmes écrits en COBOL ne remplit pas vraiment ce critère.
Le troisième problème c'est que le facteur plaisir dans le métier est important quoique tu en penses, sinon autant devenir trader pour s'en mettre plein les fouilles. De plus les gens qui éprouvent du plaisir à leur métier sont en général plus efficaces.
Après on peut faire des trucs propres en PHP, oui, et on peut même s'y amuser relativement (l'autre jour j'ai dû écrire un bout d'ORM dans ce merveilleux langage). Mais c'est comme utiliser un ersatz de langue française dont la moitié de la puissance d'expression serait passée à la trappe : c'est vite frustrant, sauf pour les rappeurs et les fans de l'oulipo.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . Évalué à 1.
Oui, mais passer de c# ou de MS C++ à php ça reste la fête au village.
Et bizarrement, ce qui joue le plus est autant le typage dynamique, que la doc. Autant j'ai pu me battre avec php et ses problèmes énormes en encodage de chaine multi octet alors que c# se débrouille mieux, autant les man pages de c# sont inutilisables tant elles sont verbeuses et le code d'exemple digne d'un stagiaire. Php.net est quand même un bon référentiel documentaire.
Pour en revenir au facteur humain, mon plus gros problème en c# était que les fanas su langage pensait que "parce qu'ils avaient le meilleur langage" tout était résolu. Quand on vous présente les "dataset*" comme un ORM, vous avez peur. Le plus gros problème que j'ai pu rencontré en environnement windows est le manque de culture informatique. Et ça c'est pire que le mauvais langage.
Anecdote :
Chez un client : tout dans les pages asp était présenté en mettant les attributs de présentation en dur dans le code asp, (border=1px; color=blue...). Le truc casse couille pour modifier l'apparence, on agrééra. Client qui me parlait fort des bonnes pratiques, de la séparation du code et de la présentation etc ... Donc, j'ai utilisé les CSS. Et 3 jours plus tard je reçois un mail du directeur technique, pro de l'informatique qui m'enjoint d'arrêter en mettant en référence un lien sur un article de security focus "The danger of CSS". Evidemment, CSS ici voulait dire cross site scripting, mais lui a pensé Cascading Stylesheet : je lui cassais les couilles avec un truc qu'il connaissait pas, un petit tour de google, il lit pas l'article et me renvoie directement la référence. J'ai jamais pu lui faire valoir qu'il parlait pas de la même chose : si security focus a dit non aux CSS, alors pas de css.
Par contre quand je lui ai montré que l'on pouvait injecter du html arbitraire dans ses pages webs grace à textarea compréhensifs, il a pas vu le problème.
J'ai moults anecdotes de ce style qui me font penser que la culture informatique en entreprise est quand même faible, et que c'est bien le frein le plus important, plus important que le choix du langage.
Je vous raconte même pas php et l'utf8 sur un windows IIS mysql PHP.
Bref le choix du langage est pour moi un problème d'optimisation alors qu'en entreprise --souvent**-- tout est à faire. On chipote sur le langage alors que le facteur humain est largement plus bloquant
* http://en.wikipedia.org/wiki/Data_set
** oui il y a aussi de très bons professionnels, mais je suis souvent surpris de l'endroit où je les trouve.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Yusei (Mastodon) . Évalué à 2.
Mais voyons, on chipote aussi sur le facteur humain. Si tu as des doutes à ce sujet, tu n'as qu'à créer un journal disant que tu hésites entre aller à l'Epita et à la fac.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . Évalué à 0.
La productivité en informatique par développeur est :
0) indépendante du diplôme ;
1) indépendante de l'expérience au delà de 2 ans;
2) varie d'un facteur 1 à 10 par individu.
(Sackmann Grant et al)
L'informatique n'est pas une question de diplôme mais de créativité. Vu comment l'enseignement est dogmatique, particulièrement en école, j'imagine pas vraiment en quoi étudier résout les problèmes de facteur humain.
Ensuite d'organisation à organisation les variabilités de productivité sont encore d'un facteur 1 à 10.
La conclusion (Peopleware de Di Marco, Myhtical Man Month de F. Brooks, Complete Coding Steve Mc Connell) est que pour améliorer la productivité en informatique,
1) il faut recruter et bien recruter non sur les diplômes, mais miser sur des équipes, et
2) s'organiser non à la française (modèle héirarchique de base), mais dans des modèles plus organiques (par "atelier" par exemple)
Pour tout ce qui est technologie le meilleur gain de productivité hors concision du langage (qui peut faire gagner un facteur 6 par rapport au C en prenant un langage à typage dynamique (php/perl/ruby/python)) est au mieux de 10%.
Tu m'expliques en quoi se focaliser sur un gain de 10% est plus intelligent qu'un que s'intéresser à un gain de 1000% x 1000% ?
Aller, je t'aide combien de fois 0,1 faut il pour faire 100 ? Question subsidiaire, à quel point significatif est 0,1 / 100 si on garde les décimales ?
Pour les journaux, ça existe déjà :
http://www.codinghorror.com/blog/archives/000960.html
http://www.joelonsoftware.com/
C'est juste qu'aux états unis ils sont les leaders mondiaux de l'édition de logiciel, va savoir pourquoi ?
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Yusei (Mastodon) . Évalué à 3.
Formulé autrement, parce que je conçois que ce ne soit pas très clair: qu'est-ce que c'est que ces âneries ? Je ne sais pas si tu essayes de faire passer un message, c'est un peu masqué par la forme ridicule de tes propos, mais tu as l'air d'être passé complètement à côté du fait que mon post était une plaisanterie.
En admettant que tu sois sérieux, j'aimerais bien savoir où tu as cru voir quelqu'un prétendre que le "facteur humain" n'était pas le plus important.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par lezardbreton . Évalué à 1.
Pour tout te dire, je n'ai pas d'opinion tranchée sur les autodidactes, principalement parce que je n'en connais pas. Par contre, je suis capable de reconnaitre tout ce que m'ont apporté mes études, notamment en termes de structuration de la pensée, de construction de l'individu, de diversification des connaissances. Je ne dis pas que l'on ne peut pas acquérir cela ailleurs, mais je suis persuadé que mes semblables peuvent confirmer que cela était le cas aussi pour eux.
Vu comment l'enseignement est dogmatique
Ha, tu vois donc l'enseignement comme uniforme et rigide, et d'où sors-tu cette conclusion ?
La productivité en informatique par développeur est :
0) indépendante du diplôme ;
1) indépendante de l'expérience au delà de 2 ans;
Là, au moins, je ne vois aucune raison factuelle pour être d'accord avec toi, tout simplement. Ca contredit à 100% mon expérience professionnelle.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par pasBill pasGates . Évalué à 2.
C'est faux. La creativite est un aspect, mais nombre d'autres elements entrent en compte. La maniere dont un soft est defini architecturalement est extremement importante par exemple, penser a la facon dont le soft sera maintenu apres sa sortie influe aussi, la testabilite du soft... toutes ces choses la ne peuvent venir que de 2 endroits : l'experience ou l'etude.
Tu peux tout a fait etre creatif, creer un soft super-innovant, mais qui d'un point de vue developpement est une bouse immonde et impossible a maintenir/faire evoluer.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Julien . Évalué à 2.
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Jul (site web personnel) . Évalué à 0.
Dis moi, tu colles un langage vachement bien à un manager tu crois qu'il va faire du bon code ?
Que coder en ruby ou en python ou en java empêche les développeurs de mettre les réglages en dur dans le code et les oblige à faire des fichiers de conf ?
Enfin, on a les croyances que l'on veut. Il me semblait pourtant que les informaticiens étaient des scientifiques et pas des religieux.
Remarque quand les idéologues décident de faire du code on voit ce que ça donne : GNU/Hurd, je te laisse l'utiliser en prod, je vais continuer à prendre ces vieux trucs obsolètes de linux ou BSD qui sont si vieux et mal conçus (c'est vrai pas de micro-noyaux, pas de driver user space, pas de marketeux pour dire comment c'est bien) .
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Yusei (Mastodon) . Évalué à 2.
- Mauvaise développeur implique mauvais code, donc PHP est aussi bien qu'un autre langage.
- Linux (codé en C) est plus abouti que The Hurd (codé en C), donc le choix du langage n'est pas important.
C'est bien ça ?
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par Sebastien . Évalué à 1.
euh... je vais peut-etre dire une connerie, mais il me semblait que GNU/Hurd-L4 est/etait (sera... un jour...) code en C++.
En tout cas, L4, c'est du C++.
http://hg.l4ka.org/l4ka-pistachio/file/22f8bbd4984e/kernel/s(...)
On en deduira ce que l'on voudra bien en deduire :P
[^] # Re: Python suce des ours, et ruby en tong dans le bac à sable
Posté par TeXitoi (site web personnel) . Évalué à 1.
# Langages ne sont plus comparables en tant que tel
Posté par Bungee Tux . Évalué à 1.
Tous les arguments en faveur de ruby tombent les uns apres les autres si on tient compte d'eclipse et des librairies tierces:
- accesseurs verbeux en java , mais c'est généré en 3 clics dans eclipse
- mixin c'est cool, mais variable + generate delegate method dans eclipse marche tres bien en java
- typage laxiste ruby versus completion de code complete en java
- syntaxe legere (a voire) ruby versus correction du code en java
et ainsi de suite.
Quand aux perfs, j'ai un facteur 10 sur le même programme en java et ruby a l'avantage de java.
Rajouter a ca, le fait que java est mille fois mieux loti en librairies tierces
Java 1 / Ruby 0
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Moonz . Évalué à 3.
Un IDE pour Java, c'est un peu comme caler un table bancale avec un livre. Ça marche, mais ça ne rend pas les tables bancales équivalentes aux tables stables pour autant...
Faire l'apologie de Java grâce aux IDEs, c'est un peu comme faire l'apologie des tables bancales grâce aux livres: c'est franchement stupide...
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Antoine . Évalué à 4.
L'intérêt de Java c'est que la bêtise verbeuse du langage alimente toute une industrie visant à « programmer mieux » (ou moins pire) : IDEs, littérature envahissante, perpétuation d'une caste de parasites (consultants spécialisés, « experts » pontifiants, etc.). Avec toutes ces couches de complexité surajoutées, on crée naturellement une barrière à l'entrée ce qui permet de protéger l'« industrie » du logiciel mal écrit et de l'incompétence (SSII), au détriment de tout le reste du monde informatique.
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Bungee Tux . Évalué à 1.
Mon point de vue est pragmatique, j'ai essayé de programmer en ruby et je suis pas convaincu par les "avantages" du dit langage.
Et on choisit pas un langage de programmation sur le papier, ca s'eprouve. Et je suis ouvert, j'ai essayé ocaml, python, ruby, java, c/c++, perl, php, prolog, bash, ksh, assembleur 68k et x86, lisp.
J'ai essayé des methodes de conception :
programmation par aspects, rad / test unitaires, plein de design pattern etc ...
Les bonnes idées sont souvent transposables. Faut toujours se confronter a de nouvelles idées.
Ca n'empeche que ruby n'est pas le meilleur langage pour programmer rapidement comme il le vente sur leur site. Et Eclipse + IDE, ben c'est de la balle pour programmer tres vite et bien.
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Sinon, pour avoir moi aussi testé un paquet de langages (grosso modo les mêmes que toi), je trouve que Ruby est un très bon langage. Quand j'essaye un autre langage, je tombe souvent sur des trucs qui existent en Ruby et qui me manquent dans les autres langages, alors que l'inverse est beaucoup plus rare.
Pour ce qui est du cas particulier de Java, je trouve que ce langage assez moche, et se utiliser des outils/IDE pour parer ses problèmes n'est pas une bonne idée. Si tu en as le courage, je te conseille la lecture de http://steve-yegge.blogspot.com/2007/12/codes-worst-enemy.ht(...) qui explique bien le problème.
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Bungee Tux . Évalué à 1.
C'est un des langages dont j'ai le plus apprécier la découverte.
Y'a plein plein de trucs que je n'aime pas en Java:
- Les primitifs ne sont pas vus comme des objets par le programmeur
- il existe des objets en 2 Parfums Mutable / pas mutable, ex String/StringBuffer, pourquoi n'est ce pas généralisé pour tous les types courants Double, Float, Point
- il existe des objects en 2 Parfums ThreadSafe/ pas ThreadSafe, pourquoi leur nommage est il aussi débile=> Arraylist/Vector , HashMap/HashTable etc ...
- impossibilité de renvoyer deux valeurs de retours sans utiliser une classe nommée déclarée préalablement.
Et la je parle des defauts non pris en charge par l'IDE.
Seulement, au final, c'est l'ecosysteme ou je reste largement le plus productif dans 99% de mes réalisations. Et je doute d'arriver a la même chose en ruby passé la phase d'apprentissage.
J'ai mis en bookmark la lecture pour plus tard Merki pour le lien.
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par reno . Évalué à 2.
Acces a la plateforme Java ET une syntaxe propre (et pas trop verbeuse comme celle de Java).
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Bungee Tux . Évalué à 1.
Merci pour cette découverte, j'ai fait qques exemples et franchement c'est tres interessant. Exactement ce que j'espérais, le support IDE est spartiate pour l'instant mais il n'y a aucune raison que ca n'évolue pas dans le bon sens.
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Bruno Michel (site web personnel) . Évalué à 2.
Ca oblige à utiliser un IDE là ou un semble éditeur de texte suffit. Rien de dramatique, mais ca n'en fait pas un argument pour Java.
Heu, tu es sérieux quand tu dis ca ? Si c'est le cas, en de hors des évidentes raisons esthétiques, ca doit être très chiant à maintenir, et qui dit plus de lignes de codes dit plus de bugs.
Tu opposes deux choses qui n'ont rien à voir. La complétion de code fonctionne très bien pour Ruby sous Netbeans par exemple.
Là encore, tu compares des choses qui n'ont rien à voir. Bien que ce soit une question de goût, je trouve la syntaxe de Ruby très agréable. Par contre, cela ne change rien à la correction du code. Si cela fait référence à la vérification des types, c'est très loin d'être suffisant pour éviter les bugs, et en Ruby comme en Java, j'ai tendance à considérer du code non testé comme du code buggé.
Comparer les performances sur un programme est assez ridicule. Pour ce que j'en sais, les performances de Ruby restent tout à fait correctes face à celles de Java.
Je suis d'accord que Java est mieux loti que Ruby de ce coté. Avec un peu de mauvaise foie, je pourrais dire que ce n'est pas grave car JRuby permet d'utiliser toutes les bibliothèques Java.
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Bungee Tux . Évalué à 1.
- plus de ligne de code != plus de bugs dans un code généré.
- typage laxiste => meconnaissance du type a la compilation => completion de code non ciblé sur le type => completion ne permettant pas de programmer rapidement => resultat je programme plus vite avec un ide et un env typé
- syntaxe élégante et riche pour ruby, syntaxe verbeuse et pauvre/simple pour Java. La relative pauvreté de java en fait un langage simple a parser et a en détecter les erreurs, Ide eclipse propose un remarquable service de correction a la volée. Ca en a même changé mes habitudes de programmation et je programme le quart du temps en demandant la correction d'erreur.
Ex , t'ajoute un parametre dans l'appel d'une fonction, il te corrige en auto la declaration de la dite fonction. Tu ne declare pas ta variable locale, par inference de type, il le fait a ta place.
- test unitaire powa, 100% d'accord, et en plus programmer avec une optique de test oblige a travailler propre, c'est a dire bien nommer les methodes testées, bien découper son code. Souvent les mauvais programmeurs sont a la ramasse quand il s'agit de tester parce que la merde qu'ils ont faconné se voit au grand jour.
- revoie tes tests de perf, parce que c'est vraiment pas comparable. Ceci dit, les perfs on s'en moque un peu sauf pour du calcul scientifique.
- j'ai testé JRuby, et franchement c'est tres bien pour faire du ruby sans deployer Ruby. Pour la connection Java , ca a l'air trés fonctionnel mais pas attirant pour 2 sous.
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Jul (site web personnel) . Évalué à 2.
Si si plus de bug, mais avec de grandes différences dans les écarts types. On peut traduire comme ceci, les meilleures équipes n'ont pas forcément plus de bugs, par contre, le temps de résolution est mécaniquement plus long (particulièrement si on a un bug dans le coeur d'une classe de base) et le risque de bug généré par la correction de bug augmente avec l'intrication du code. (on considère qu'une correction de bug à une chance sur deux de généré un nouveau bug par effet de bord).
Il y a les données dans complete coding de Steve Mc Connell.
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Antoine . Évalué à 3.
Prétendre que Java a pour avantage d'être rapide à taper, c'est vraiment se moquer du monde.
La relative pauvreté de java en fait un langage simple a parser
Heu, je ne sais pas pour Ruby mais Python est un langage ultra-simple syntaxiquement. Certainement beaucoup plus que Java ou C# avec leur myriade de mots-clés, modificateurs à la noix, tournures diverses et variées...
Voici un graphe de la grammaire de Python :
http://flickr.com/photos/nicksieger/281055485/
Comparaison avec Ruby :
http://www.flickr.com/photos/nicksieger/280661836/
Et avec Java :
http://flickr.com/photos/nicksieger/280662707/
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Bungee Tux . Évalué à 1.
je passe mon temps a demander la correction ou la completion du code en cours.
donc oui tu programmes rapidement en java, c'est sur que tu use bcp les touches affectées pour les deux actions correction/completion.
Pour la grammaire, les graphes m'ont bluffé, c'est totalement objectif et ca permet réellement de juger des combinaisons de la grammaire.
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Bruno Michel (site web personnel) . Évalué à 2.
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par Sylvain Sauvage . Évalué à 2.
D’une part, une relation entre le nombre de mots clefs et la simplicité¹ d’un langage reste à démontrer. Et cette démonstration me semble compromise puisque l’on peut facilement trouver un contre-exemple : Brainfuck.
D’autre part, il y a mot clef et mot clef. Certains arguent de la simplicité¹ de leur langage préféré par le nombre de mots clefs tels qu’ils sont définis par la grammaire du dit langage, en oubliant les mots clefs de macros, constructions, structures ou fonctions très fréquentes. P.ex., en Common-Lisp, la fonction (macro en fait) loop utilise une multitude de mots clefs (for, step, do…). Pour maîtriser Common-Lisp, il vaut mieux connaître loop et ses principales constructions, or ce ne sont pas des mots clefs de la grammaire. Pour info, le Lisp a besoin de seulement neuf primitives ; tout le reste peut être écrit à partir de ces neuf-là, donc la grammaire est très petite en mots clefs.
Et ceci est aussi valable pour les principaux messages des langages comme Io ou Smalltalk : leur grammaire n’a pas beaucoup de terminaux (mots clefs) mais ne connaître qu’eux n’aide pas beaucoup à leur usage.
Ce qui m’amène à la simplicité (et donc au renvoi ¹ de ci-dessus) : compter le nombre de mots clefs ou regarder les graphes de « dépendance » (donnés dans un commentaire précédent), ça ne donne qu’une idée de la simplicité d’une grammaire pour un compilateur/interprète (et encore, ajouter des mots clefs peut simplifier une grammaire en la rendant LL(1) ou LALR(1), et je dis bien « une grammaire » : le susdit graphe dépend de la grammaire choisie et il n’y a pas qu’une grammaire par langage). En tout cas, cela ne donne aucune indication sur la simplicité d’un langage pour un humain.
[^] # Re: Langages ne sont plus comparables en tant que tel
Posté par hocwp (site web personnel) . Évalué à 2.
Ce qui est relativement simple. Par contre le Common Lisp ne sera pas qualifié de simple si on compte les 978 symbôles[*] (fonctions, macros ou variables) définis de bases et sans compter, comme tu le dis, les mots clé de la macro loop... Mais le point de départ est extremement simple.
[*] http://www.lisp.org/HyperSpec/FrontMatter/Symbol-Index.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.