Articles précédents : Logiciel
- [50] Sortie de Gambas 1.0
- [98] Gimp 2.2.0 (et 2.2.1)
- [13] Compilations de logiciels libres sous Windows : faites-les vous-même!
- [38] Sortie de Linux 2.6.10 pour Noël
- [20] MPlayer 1.0pre6: "X-mas present" dans les bacs
- [17] Blender 2.36
- [22] SFLPhone : Un nouveau téléphone IP sur votre bureau
- [9] CHRONOMIUM GPL passe un cap avec la version 0.9
- [187] Des petits jeux pour les fêtes
- [80] GTK+ 2.6 est disponible
Liens connexes
- Site officiel de Ruby (913 hits)
- Ruby-Wiki (272 hits)
- Red Handed (194 hits)
- Principaux changements (248 hits)
- L'API core (209 hits)
- L'API de la bibliothèque standard (245 hits)
Dépêche modérée par
Dépêche éditée par
Longtemps attendue, mais retardée pour cause de manque de temps, la nouvelle version de Ruby corrige quelques bugs, et voit sa collection de classes "standards" augmenter (notamment l'ajout de RSS::Parser, SOAP4R, Net::HTTPS, l'extension de Ruby/Tk, le support des vhosts par WEBRick, ainsi que l'amélioration de Ri et RDoc).
À noter au passage, le fantastique livre de Dave Thomas sur Ruby. Ce livre en est à sa seconde édition, la première étant diffusée librement.
![[en]](../../../images/en.png)
Site officiel de Ruby (913 hits)-
Ruby-Wiki (272 hits)
-
Red Handed (194 hits)
-
Principaux changements (248 hits)
-
L'API core (209 hits)
-
L'API de la bibliothèque standard (245 hits)
> Lire la dépêche (148 commentaires, moyenne: 1,8).
livre libre
où peut-on se procurer le livre de D. Thomas ?
-
[^]Re: livre libre
Posté par Frederick Ros (page perso, ) le 04/01/2005 à 19:43. (lien). Évalué à 1.Sur le site indique, dans la version papier ou PDF. Sinon sur Amazon ou le Monde En Tic
-
[^]Re: livre libre
Posté par TazForEver () le 04/01/2005 à 19:49. (lien). Évalué à 2.ah d'accord, je pensais que la première version était également disponible gratuitement. Je ne suis pas un connaisseur de Ruby, mais les extraits PDF ont l'air sympa.
-
[^]Re: livre libre
Posté par Frederick Ros (page perso, ) le 04/01/2005 à 20:18. (lien). Évalué à 2.Effectivement la premiere version existe en HTML, et est meme downloadable (pour les utilisateurs de Gentoo elle se trouve meme dans Portage)
Pour la qualite du bouquin, ben quand on voit la qualite des autres livres de D. Thomas, on comprend ;)
-
-
-
[^]Re: livre libre
Posté par Pascal Terjan (Jabber id, page perso, ) le 04/01/2005 à 20:07. (lien). Évalué à 5.La version HTML de la première version se trouve sur http://www.rubycentral.com/book/(...)
-
[^]Re: livre libre
Posté par Alex () le 05/01/2005 à 13:03. (lien). Évalué à 1.C'est d'aileurs bien dommage que la seconde édition ne soit pas librement dispo... un des problèmes de ruby étant a mon gout le manque de doc...
-
[^]Re: livre libre
Posté par Frederick Ros (page perso, ) le 05/01/2005 à 13:33. (lien). Évalué à 1.Oui .. mais ecrire des livres est ce qui fait vivre Dave Thomas .. et vu le nombre de pages de la 2nde version il a du y mettre le temps ...
Tu peux aussi essayer : le Why (Poignant) Guide : http://poignantguide.net/ruby/(...) , pas encore complet mais ca avance ...-
[^]Re: livre libre
Posté par Laurent Sansonetti (page perso, ) le 06/01/2005 à 10:14. (lien). Évalué à 1.BTW, la version 2 devrait se liberer, meme si il n'y a pas encore de date prevue.
Le chapitre sur les gems est dispo:
http://www.pragmaticprogrammer.com/titles/ruby/gems.pdf(...)
Mais sinon le livre vaut vraiment l'achat. Bonne typographie, facile a naviguer, et il documente toute la stdlib. Un must-read!-
[^]Re: livre libre
Posté par Frederick Ros (page perso, ) le 06/01/2005 à 11:05. (lien). Évalué à 1.Elle se liberera quand la version 3 arrivera ;)
-
-
-
-
Qu'est-ce que Ruby ?
La nouvelle est intéressante mais il manque un détail, donc comme on n'est jamais mieux servi que par soi même :
Ruby is the interpreted scripting language for quick and easy object-oriented programming. It has many features to process text files and to do system management tasks (as in Perl). It is simple, straight-forward, extensible, and portable.
Oh, I need to mention, it's totally free, which means not only free of charge, but also freedom to use, copy, modify, and distribute it.
En gros c'est un langage de programmation orienté objet interprété portable et libre (licences GPL et Ruby). Donc Ruby désigne le langage et l'interpréteur. Il est développé au Japon.
Il y a un article sur Ruby dans Wikipédia : http://fr.wikipedia.org/wiki/Ruby(...)
Chez Framasoft : http://www.framasoft.net/article2923.html(...)
Le guide utilisateur en français : http://perso.wanadoo.fr/alain.feler/(...)
Cela n'a rien à voir avec l'annotation Ruby de XHTML 1.1 du W3C : http://www.yoyodesign.org/doc/w3c/ruby/(...)
---
Touchez pas au clavier j'ai une gastro.
-
[^]projets en Ruby ?
Posté par baud123 (Jabber id, page perso, ) le 05/01/2005 à 01:13. (lien). Évalué à 3.et les projets sont hébergés sur http://rubyforge.org(...) qui est bien actif
il s'y trouve par exemple un gestionnaire de livres, sous Gnome (tous vos bouquins via leur ISBN avec saisie automatique des données titre, auteur, édition, page de garde à partir de sites en ligne) http://rubyforge.org/projects/alexandria/(...)-
[^]Re: projets en Ruby ?
Posté par patrick_g (page perso, ) le 05/01/2005 à 09:07. (lien). Évalué à 1.Génial ce soft !
l'emmerde c'est que 80% de ma bibliothèque c'est des livres anciens (19ieme ou même 18ieme siècle) et que je peux me brosser pour avoir des numéros ISBN....c'est l'inconvénient de la bibliophilie !
tu connais pas une autre solution ?-
[^]Re: projets en Ruby ?
Posté par baud123 (Jabber id, page perso, ) le 06/01/2005 à 00:18. (lien). Évalué à 2.pour l'instant la lecture de code barre est passée avant la saisie manuelle de *toutes* les données (nan nan je rigole pas...)
les n° EAN sont gérés aussi, désolé ça t'aide pas non plus :-(
Plus sérieusement, je viens de vérifier, la saisie manuelle des données est possible dans la version dont je dispose (la 0.4.0)
Si tu as des bibliothèques en ligne qui proposent une interface comme Amazon, Proxis and Barnes and Noble tu peux la suggérer sur la ML de dév d'alexandria : ils essaieront sans doute de le prendre en compte si c'est documenté : alexandria-list at rubyforge dot org http://rubyforge.org/mailman/listinfo/alexandria-list(...)-
[^]Re: projets en Ruby ?
Posté par Pascal Terjan (Jabber id, page perso, ) le 06/01/2005 à 00:47. (lien). Évalué à 2.ils essaieront sans doute de le prendre en compte si c'est documenté Et même si c'est utile et mal documenté (pour Proxis j'ai juste maté les sources des pages web). Le problème est beaucoup plus fondamental :
def yaml(book) File.join(self.path, book.isbn + EXT[:book]) endL'ISBN est considéré comme la clé unique et les livres sont stockés en temps que <ISBN>.yaml donc pour gérer des livres sans ISBN il faudrait un changement important (trouver ou définir un autre identifiant...) :-(-
[^]Re: projets en Ruby ?
Posté par Frederick Ros (page perso, ) le 06/01/2005 à 08:04. (lien). Évalué à 1.Et un efois que c'est fait definir une sous-classe de ISBN qui repond au message isbn .. meme si c'est pas vraiment l'ISBN qui est renvoye .. Duck Typing ;)
-
[^]Re: projets en Ruby ?
Posté par Laurent Sansonetti (page perso, ) le 06/01/2005 à 10:05. (lien). Évalué à 1.Va falloir fixer cela :-) Un changement du modele de donnees n'est pas si problematique (il a d'ailleurs change entre 0.3.x et 0.4.x).
-
-
-
-
-
[^]Re: Qu'est-ce que Ruby ?
Posté par Frederick Ros (page perso, ) le 05/01/2005 à 07:34. (lien). Évalué à 3.Tu as raison. Desole c'etait ma premiere news, je ferais mieux pour la seconde ;)
Différence avec Python ?
Quelqu'un connait-il suffisament les deux langages pour être capable de faire la comparaison ?
D'après ce que je sais Python est aussi orienté objet et les API ont l'air bien complètes ? Quel est donc l'avantage de Ruby sur Python ?
-
[^]Re: Différence avec Python ?
Posté par Pascal Terjan (Jabber id, page perso, ) le 05/01/2005 à 12:57. (lien). Évalué à 1.C'est cool à utiliser :-) Sinon, je trouve en particulier que la syntaxe de Ruby reflete plus l'esprit. Par exemple :
Python : string.split(s,'","') Ruby: s.split(',')On voit mieux en Ruby qu'on appelle une methode de l'objet surtout quand on enchaine :Python: string.join(string.split(s),"|") Ruby: s.split().join('|')-
[^]Re: Différence avec Python ?
Posté par Ramso (page perso, ) le 05/01/2005 à 13:11. (lien). Évalué à 6.T'as pas fait de Python depuis combien d'années ?! Ta syntaxe pour Ruby est exactement identique en Python. Faudra trouver autre chose !
> Python : string.split(s,'","')
T'aurais pu faire plus compliqué encore pour valoriser Ruby...--
Groar !-
[^]Re: Différence avec Python ?
Posté par Pascal Terjan (Jabber id, page perso, ) le 05/01/2005 à 13:27. (lien). Évalué à 0.Je n'ai jamais vraiment fait de python parce que justement je n'aimais pas la syntaxe.
Pour ce qui est de ces 2 exemple, j'ai cherché un tutorial python sur google et j'ai copié 2 des exemples... Si on peut avoir des trucs lisibles en python c'est bien, mais pourquoi est-ce si peu utilisé alors ?
-
[^]Re: Différence avec Python ?
Posté par Pascal Terjan (Jabber id, page perso, ) le 05/01/2005 à 13:35. (lien). Évalué à 2.Bon OK, il n'y a pas de date sur http://freebooks.by.ru/view/RedHatLinux6Unleashed/rhl6u350.htm(...) mais ca date de RH6 donc c'est pas tout jeune en effet /o\
-
-
[^]Re: Différence avec Python ?
Posté par manatlan (Jabber id, page perso, ) le 05/01/2005 à 13:21. (lien). Évalué à 2.je m'insurge ...
Je ne vois pas en quoi on voit un "esprit refleté dans ruby", quand on écrit mal du python comme ça ....
en python, on peut écrire aussi :
s.split(",") ## idem qu'en ruby ##
et
"|".join( s.split(",") ) ## qui est même plus parlant qu'en ruby je trouve (*) ##
* : on voit bien que le retour de ça, sera du "string"-
[^]Re: Différence avec Python ?
Posté par Pascal Terjan (Jabber id, page perso, ) le 05/01/2005 à 13:28. (lien). Évalué à 3."esprit refleté dans ruby"
J'ai oublié le mot objet :/
quand on écrit mal du python comme ça
Ce python n'est pas de moi, c'est un des premiers exempels que j'ai trouvé sur python...
on voit bien que le retour de ça, sera du "string"
ah ? tu le vois ou ?
"plop".length, on voit bien aussi que le retour sera une string ?
-
[^]Re: Différence avec Python ?
Posté par Frederick Ros (page perso, ) le 05/01/2005 à 13:42. (lien). Évalué à 1."|".join( s.split(",") ) ## qui est même plus parlant qu'en ruby je trouve (*) ##
* : on voit bien que le retour de ça, sera du "string"
Super parlant en effet... Comme je l'ai dit dans un precedent commentaire, je comprends pas que l'operateur join appartienne a la classe String ...
En Ruby (je sais plus pour le Python), on parle de message, pas de methodes. Donc si je lis ton code avec un esprit de Rubyiste, je lis :
Envoie le message join a l'objet "l" ... Pas Zarb ca ?-
[^]Re: Différence avec Python ?
Posté par Volnai () le 05/01/2005 à 14:13. (lien). Évalué à 2.on parle de message, pas de methodes.
Tiens donc, on se rapprocherais donc de l'objet façon Objective C ? C'est quoi le vrai objet : avec des methodes, ou avec des messages ?-
[^]Re: Différence avec Python ?
Posté par Frederick Ros (page perso, ) le 05/01/2005 à 15:14. (lien). Évalué à 1.Ce serait plutot des messages a la Smalltalk ... dont est fortement inspire Ruby.
-
[^]Re: Différence avec Python ?
Posté par applex () le 05/01/2005 à 16:18. (lien). Évalué à 1.Ce qui est la même chose.... Objective C a repris le système de message de Smalltalk. C'est blanc bonnet et bonnet blanc.
-
[^]Re: Différence avec Python ?
Posté par Frederick Ros (page perso, ) le 05/01/2005 à 16:21. (lien). Évalué à 1.Ben non.. Smalltalk etant la avant :)
-
[^]Re: Différence avec Python ?
Posté par applex () le 05/01/2005 à 16:36. (lien). Évalué à 0.C'est bien ce que j'écris en disant que objC "a repris".
Et pourquoi "ben non?"
Dire "Ruby utilise la notion de message comme objectiveC" et tout aussi bon que dire "Ruby utiliser la notion de message de smalltalk" :)-
[^]Re: Différence avec Python ?
Posté par Frederick Ros (page perso, ) le 05/01/2005 à 16:44. (lien). Évalué à 1.Oui .. je suis d'accord avec toi, ne te fache pas ;)
Mon point etait que Smalltalk etant anterieur a ObjC, et ObjC ayant repris la notion de message de Smalltalk, il me semblait plus precis de dire que c'etait des messages a la Smalltalk ;)
-
-
-
-
-
-
-
[^]Re: Différence avec Python ?
Posté par Éric (Jabber id, page perso, ) le 05/01/2005 à 15:57. (lien). Évalué à 4.> "|".join( s.split(",") ) ## qui est même plus parlant qu'en ruby je
> trouve (*) ##
ah ?
marrant, naturellement le join je le ferai sur un tableau moi. Je joint "les éléments du tableau" "avec" "|". En Objet ça donne "les elements du tableau".join( "|" ) et pas le contraire.
En POO toujours, quand on opère deux transfo successives sur un même objet, on peut généralement les chainer : s.split(',').join('|')
C'est en voyant que ça ne marche pas qu'on peut facilement se rendre compte qu'il y a une couille dans l'ordre des paramètres.
C'est du détail mais il ne faut pas aller dire non plus que c'est "mieux" pour autant. Si j'ai bien compris si c'est différent en python c'est plus historique (appartenance au module string avec une chaine comme premier paramètre => passage en méthode de l'objet string)
> * : on voit bien que le retour de ça, sera du "string"
où ? pourquoi ? je ne suis pas d'accord. Je ne vois pas en quoi mettre "|".join(list) ou list.join("|") me donne une quelconque indication sur le type de la valeur de retour. Sauf à croire qu'une méthode qui s'applique sur une chaine ne peut retourner qu'une chaine.-
[^]Re: Différence avec Python ?
Posté par Amand Tihon (page perso, ) le 05/01/2005 à 18:15. (lien). Évalué à 2.marrant, naturellement le join je le ferai sur un tableau moi. Je joint "les éléments du tableau" "avec" "|".
Oui, je reconnais que c'est un des bouts déroutants de Python. Mais en fait, les deux sont logiques.
Avec "|".join(t), je demande au caractère "|" de faire la jointure entre les éléments de t.
J'envoie à l'objet "|" le message "sert de glue à" "mon tableau t".
Pour l'histoire du type de retour, je suis bien sûr d'accord avec la majorité :)
-
-
-
[^]Re: Différence avec Python ?
Posté par Misc (page perso, ) le 05/01/2005 à 13:26. (lien). Évalué à 3.Euh, sous python :
misc@skittles:~$ python
Python 2.3.4 (#2, Dec 3 2004, 13:53:17)
[GCC 3.3.5 (Debian 1:3.3.5-2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> s="oui non"
>>> s.split(' ')
['oui', 'non']
>>> ','.join(b)
'oui,non'
>>> ','.join(s.split(' '))
'oui,non'
bon, ok, l'ordre du join est moins naturel, il y a peut être une bonne raison.-
[^]Re: Différence avec Python ?
Posté par Frederick Ros (page perso, ) le 05/01/2005 à 13:36. (lien). Évalué à 1.:TROLL ON: Rajoute a la va vite ? :TROLL OFF:
Je vois pas en quoi l'operateur join devrait s'appliquer a une chaine ...
-
-
[^]Re: Différence avec Python ?
Posté par applex () le 05/01/2005 à 16:26. (lien). Évalué à 1.Comme il est dit pas mal de fois en réponse à ton post, la syntaxe que tu donnes pour Python est quelque peu dépassée :)
Mais il est clair que tu ne pouvais pas le savoir vu que tu ne l'utilises pas ce langage (et c'est dommage de donner son avis sur un sujet que l'on ne connait pas).
Le choix d'un langage (comme de tout outil de développement) est une histoire de goût et dépend des besoins également.
A chacun d'essayer pour se faire une idée et ne pas choisir en fonctions des autres.
Et j'ai l'impression que ce flux ce transforme en troll (ou bien le concours de la plus grosse entre Python et Ruby)... Pour continuer dans la foulée, on n'a qu'à parler de Perl que certains idolâtre (même si je pense que ces derniers ont des problèmes psy :-) )-
[^]Re: Différence avec Python ?
Posté par Arthur Accroc () le 09/01/2005 à 03:24. (lien). Évalué à 1.Pour continuer dans la foulée, on n'a qu'à parler de Perl que certains idolâtre
Ben quoi ? Perl, ça peut être le meilleur choix, tout dépend pour quoi faire.
Pour l'administration système, en particulier :
- fonctions de manipulation de fichiers directement intégrées au langage;
- pareil pour les fonctions de traitement (au sens traitement automatisé) de texte (expressions rationnelles, ensemble de possibilités équivalentes à celles d'awk, etc.);
(et les fichiers de configuration, de logs, etc. sont pratiquement tous des fichiers texte... à part sous Windows);
- des fonctions intégrées proches du système;
- une base de modules (http://www.cpan.org/(...)) contenant, entre autres, tout ce dont on peut rêver pour l'administration système (j'ai déjà eu besoin de trucs très pointus);
- possibilité de faire des unilignes (essayez donc en Python !) plus courts et plus puissants qu'avec uniquement le Shell (et les unilignes, c'est bien pratique pour faire rapidement et de manière automatisée un traitement lourd et/ou complexe sur des fichiers; voir http://www-106.ibm.com/developerworks/linux/library/l-p101/(...) et http://www-106.ibm.com/developerworks/linux/library/l-p102.html?ca=(...));
- possibilité assez facile d'interface aussi bien texte, que graphique ou CGI (pratique pour réutiliser du code d'un script d'administration pour une interface qu'on fournit aux utilisateurs);
- disponible sur les principales plateformes et souvent déjà installé sur les systèmes de type Unix (on est parfois amené à intervenir sur des systèmes qu'on a pas installé soi-même)...--
« 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: Différence avec Python ?
Posté par Frederick Ros (page perso, ) le 09/01/2005 à 10:53. (lien). Évalué à 2.Je suis d'accord avec toi sur le fait que Perl est parfois tres utile. Neammoins sur le long terme il devient tres difficile de mantenir un gros programme Perl....
Pour ce qui est des autres points, je pense que Python (et Ruby) commence largement concurrencer Perl. Ne connaissant pas suffisamment Python (et ne voulant pas dire de betises) je ne parlerai que de Ruby (mais IMHO c'est pareil pour Python):
- Les fonctions de manipulations de fichiers et/ou de traitements sont integrees (et souvent multi-plateforme d'origine: par exemple pour concatener plusieurs composant d'un path, tu peux faire a la Perl une concatenation de chaines, ou utiliser le File.join pour avoir les delimiteurs de la plateforme: / ou \ par exemple
- Les modules de bases sont de plus en plus repandus/developpes.. Tu serais etonne de voir ce que l'on trouve sur RAA/RubyForge. Pour les installer : utiliser Ruby Gems est le plus simple ..
- Les unilignes existent aussi ..
- L'interface est souvent facilite par le fait que tu essaies de faire un design propre ..; La sortie 'ecran' n'etant qu'une facon de publier
- Seul le dernier point peche: pour le moment Ruby n'est pas installe partout ..; mais ca va venir ;) (qund j'ai commence le Perl il fallait l'installer soit meme ou demander une install ...)
J'ajouterais que de nombreuses lib sont integrees dans la distrib standard de Ruby. L'autre jour j'ai ainsi eu a reformater de long doc XML (formattes sur une seule tres tres longue ligne) : je n'ai pas eu a utiliser de module externe pour pouvoir parser du XML, et le programme terminal m'a pris 2 ou 3 lignes ..
Tu peux faire des trucs marrants juste avec la distrib d'origine:
http://redhanded.hobix.com/inspect/mp3EncodingFromAGreatDistance.ht(...)-
[^]Re: Différence avec Python ?
Posté par Arthur Accroc () le 10/01/2005 à 19:58. (lien). Évalué à 1.Neammoins sur le long terme il devient tres difficile de mantenir un gros programme Perl....
Quand on l'a programmé soi-même et pour peu qu'on ait un style propre et cohérent, on peut encore s'en sortir assez bien.
Évidemment, ceux qui passent derrière peuvent avoir plus de mal, mais bon, si c'est parce qu'on s'est fait viré de son boulot, on ne considère peut-être plus ça comme un inconvénient. ;-)
Bon, j'admet volontiers que si je voulais développer un projet de grande ampleur, j'envisagerais Ruby ou Python (et j'aurais du mal à choisir lequel...).
mais IMHO c'est pareil pour Python
Pas pour les unilignes : des unilignes dans un langage qui définit les blocs par l'indentation, même si ce choix ne me paraît pas mauvais par ailleurs, ça pose tout-de-suite un problème conceptuel...
En fait, un des buts avoués du concepteur de Ruby était de faire un langage qu'on puisse utiliser en lieu et place de Perl, alors que ce n'est pas un objectif de Python.
Ça explique la validité de tes arguments portant sur le langage (la question de la large disponibilité ou pas, quant à elle, ne dépend pas du langage lui-même...).
Tu peux faire des trucs marrants juste avec la distrib d'origine:
Je n'en doute pas. J'ai essayé Ruby en faisant un petit truc et je l'ai trouvé globalement génial... mais d'un autre côté, il y a quelques détails qui me gênent bien :
* L'absence de destructeurs : un langage objet dans destructeurs, c'est un peu comme un langage objet sans héritage multiple. Je suis habitué à utiliser les destructeurs pour enregistrer l'état, finalliser des traitements, etc. et ça me gêne bien qu'il n'y en ait pas. La construction la plus proche que j'ai trouvée consiste à prévoir des constructeurs acceptant en paramètre une closure définissant le traitement à effectuer et assurant eux-mêmes après celui-ci les éventuelles finalisations ou enregistrements, mais ça ne me plaît pas... D'un autre côté, Perl passant lui aussi au garbage collector avec la prochaine version 6, je crains aussi un peu ce qui pourra lui arriver de ce côté-là...
* Les end : c'est verbeux et puis, alors que l'indentation permet tout-de-suite avec Python de vérifier que les blocs sont correctement délimités, et que pour Perl ou le C/C++ n'importe quel éditeur un peu potable surlignera pour cela les paires d'accolades qui vont ensemble, la même vérification impliquera pour Python un éditeur avec un mode spécifique assez sophistiqué.--
« 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: Différence avec Python ?
Posté par Frederick Ros (page perso, ) le 11/01/2005 à 08:08. (lien). Évalué à 1.Quand on l'a programmé soi-même et pour peu qu'on ait un style propre et cohérent, on peut encore s'en sortir assez bien.
Évidemment, ceux qui passent derrière peuvent avoir plus de mal, mais bon, si c'est parce qu'on s'est fait viré de son boulot, on ne considère peut-être plus ça comme un inconvénient. ;-)
Bon, j'admet volontiers que si je voulais développer un projet de grande ampleur, j'envisagerais Ruby ou Python (et j'aurais du mal à choisir lequel...).
Bof .. je fais gaffe a mon style en Perl, mais j'ai vraiment des pbs a reprendre un de mes programmes quelques temps apres .. .alors quand il s'agit de celui d'un dev qui s'en foutait un peu ...
* L'absence de destructeurs : un langage objet dans destructeurs, c'est un peu comme un langage objet sans héritage multiple. Je suis habitué à utiliser les destructeurs pour enregistrer l'état, finalliser des traitements, etc. et ça me gêne bien qu'il n'y en ait pas. La construction la plus proche que j'ai trouvée consiste à prévoir des constructeurs acceptant en paramètre une closure définissant le traitement à effectuer et assurant eux-mêmes après celui-ci les éventuelles finalisations ou enregistrements, mais ça ne me plaît pas... D'un autre côté, Perl passant lui aussi au garbage collector avec la prochaine version 6, je crains aussi un peu ce qui pourra lui arriver de ce côté-là...
Si tu as des finalisations le plus propre est sans doute de prendre l'approche block, un peu comme le File.open ...
* Les end : c'est verbeux et puis, alors que l'indentation permet tout-de-suite avec Python de vérifier que les blocs sont correctement délimités, et que pour Perl ou le C/C++ n'importe quel éditeur un peu potable surlignera pour cela les paires d'accolades qui vont ensemble, la même vérification impliquera pour Python un éditeur avec un mode spécifique assez sophistiqué.
Ben je trouve pas ca vraiment tres verbeux : tu as 2 caracteres de plus qu'avec une accolade !-
[^]Re: Différence avec Python ?
Posté par Arthur Accroc () le 17/01/2005 à 18:38. (lien). Évalué à 1.Si tu as des finalisations le plus propre est sans doute de prendre l'approche block, un peu comme le File.open ...
Oui, c'est ce que je voulais dire.
Cela dit, dans ce cas, cela oblige à être conscient de la nécessité de finalisation au niveau de l'utilisation de la classe, contrairement au principe du destructeur. C'est moins souple.
Par exemple, si après changement d'implémentation, une classe qui n'avait besoin d'aucune finalisation en a maintenant besoin, ça peut impliquer de modifier toutes ses utilisations !
Ben je trouve pas ca vraiment tres verbeux : tu as 2 caracteres de plus qu'avec une accolade !
C'est juste que je préfère laisser les lettres aux choses plus significatives, mais ce sont surtout les contraintes pour la vérification qui me dérangent.
Cela dit, ce n'est pas ce point, mais le premier, qui m'a arrêté net dans mon élan vers Ruby...--
« 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: Différence avec Python ?
Posté par Frederick Ros (page perso, ) le 05/01/2005 à 13:38. (lien). Évalué à 1.Pour faire simple, en premier, je dirais que le mieux est d'essayer les deux et de garder celui qui te plait. J'ai essaye Python, il ne me convenait pas. Je n'aime pas le "delimitage" de blocs par des espaces, je n'aime pas a avoir a rajouter self au methode de ma classe, et je n'aimais pas les __ a tout va.
Les justifications de ces 2 problemes que j'ai trouvee ne m'ont pas convaincu du tout.
Ensuite tout est question de gout.-
[^]Re: Différence avec Python ?
Posté par oxman (page perso, ) le 05/01/2005 à 14:20. (lien). Évalué à 3.Ruby
class Rectangle include Comparable attr_reader :width, :height def initialize(w, h) @width, @height = w, h end def <=>(o) [@width, @height] <=> [o.width, o.height] end end class Square < Rectangle def initialize(side) @width = @height = side end def <=>(o) if o.type == Square @width <=> o.width else o <=> self end end endPythonclass Rectangle: def width(self): return self.__width def height(self): return self.__height def __init__(self, w, h): self._width, self.__height = w, h def __cmp__(self, o): return cmp( [self._width, self.__height], [o.width(), o.height()]) class Square(Rectangle): def __init__(self, side): self._width = self.__height = side def __cmp__(self, o): if isinstance(o, Square): return cmp(self.__width, o.width()) else: return o.__cmp__(self)Merci à Lucas pour l'exemple ;-)-
[^]Re: Différence avec Python ?
Posté par Volnai () le 05/01/2005 à 14:25. (lien). Évalué à 0.Mon avis perso a moi aprés ces deux exemples : beurk ca craint python
-
[^]Re: Différence avec Python ?
Posté par LupusMic (page perso, ) le 05/01/2005 à 15:22. (lien). Évalué à 2.Mais encore ? Peux-tu argumenter ?
-
[^]Re: Différence avec Python ?
Posté par Volnai () le 05/01/2005 à 15:38. (lien). Évalué à 4.Oui je peut, mais ca me parait tellement flagrant...
Si je devait choisir un language à apprendre, et qu'on me presentait ces 2 exemples, je ne choisirais pas python. C'est illisible (par rapport à ruby s'entends). Tout ces __ c'est d'un laid, ca pollue l'affichage.sans parler des "self" (presque 1 par ligne de code en moyenne !). C'est dommage tout ça , d'autant plus que le fait de forcer à avoir une indentation propre est une bonne idée pour la lisibilité, mais la c'est gaché.
Et effectivement, mais çà c'est une question goût (alors que personne n'osera dire que l'exemple python est plus lisible que le ruby), je trouve plus clair les appel de methodes (ou envoie de messages) dans ruby.
Je ne jugeait pas là les qualité intrinsèques aux langages. Sur ce point je suis persuadé qu'ils se valent, et qu'ils valent perl.-
[^]Re: Différence avec Python ?
Posté par applex () le 05/01/2005 à 16:42. (lien). Évalué à 3.L'avantage des "__" comme pour __init__ ou __cmp__ permet de rapidement savoir si cette fonction est une fonction de "base" (faudrait trouver un autre terme je pense) de classe.
Perso, je ne trouve pas cela illisible, c'est un repère.
C'est un peu comme ceux qui déclarent les variables d'instance en précédant leur nom avec "m_" ou "m" ou bien "__".-
[^]Re: Différence avec Python ?
Posté par Volnai () le 05/01/2005 à 16:56. (lien). Évalué à 2.Je ne suis pas convaincu. Effectivement, il peut, j'imagine, parfois être utile d'ajouter un prefixe pour certain "type" de variable. Mais là il y a plus de 30 fois le caractère "_" dans l'exemple !. Est-ce qu'on pourrait les enlever en gardant le même sens au programme ? Si j'ai bien compris ca sert à definir des variables/methodes privées (comme le private de Java) ?
Bref, pour mieux dire le fond ma pensé; on met régulierement en avant la "propreté" de python par rapport à perl (facile) ou même Java (ca se discute). L'impression que j'ai ici, c'est que face à Ruby il n'y a pas photo à ce niveau là (je ne juge pas le reste). Un peu comme il n'y a pas photo entre la lisibilité d'un programme objet en C++ et le même en Objective C.-
[^]Re: Différence avec Python ?
Posté par LupusMic (page perso, ) le 05/01/2005 à 20:18. (lien). Évalué à 2.Si j'ai bien compris ca sert à definir des variables/methodes privées (comme le private de Java) ?
Absolument pas. Ce sont des mots clés réservés de Python, qui sont utilisés pour certains comportements standards.
Un peut comme __get(), __set() en PHP5.-
[^]Re: Différence avec Python ?
Posté par Volnai () le 05/01/2005 à 22:55. (lien). Évalué à 1.d'accord tres bien, donc je persiste: python est moins bon que ruby en terme de lisibilité, puisque 1 self par ligne et 30 caractères _ sont necessaire pour faire un programme tout simple comme celui présenté.
-
[^]Re: Différence avec Python ?
Posté par Éric (Jabber id, page perso, ) le 05/01/2005 à 23:24. (lien). Évalué à 3.En même temps le ruby a plus de "end" que le python de "self" ;)
Je ne crois pas qu'on puisse résumer la lisibilité à des nombres d'occurences ou de caractères. Des fois rajouter des choses en les mettant explicitement peut être plus clair/lisible.-
[^]Re: Différence avec Python ?
Posté par Frederick Ros (page perso, ) le 06/01/2005 à 08:07. (lien). Évalué à 3.Si c'est pour le self que tu dis ca, je suis pas vraiment d'accord ... C'est l'argument de justification que j'ai vu mais ca fait un peu .. pense apres ...
-
[^]Re: Différence avec Python ?
Posté par Volnai () le 06/01/2005 à 10:05. (lien). Évalué à 3.En même temps le ruby a plus de "end" que le python de "self"
Dans cet exemple c'est faux, compte avant d'affirmer ça.
Alors oui, compter le nombre de caractères n'est pas une "méthode qui tue" pour juger un programme, je te l'accorde. Mais en même temps, si je dit juste que "python c'est moche", on me demande de justifier, alors j'essaye de prendre une mesure rationnelle de ce qui le rend moche (tout ca c'est par rapport à ruby hein).
Je me demande alors pourquoi j'ai cette impression de "gros bordel" quand je lis le code Python, et que je ne l'ai pas quand je lis le code Ruby. Bon bah la reponse est clair pour moi : l'affichage est beaucoup plus polué en Python qu"en Ruby. Et j'utilise le mot "polué" parceque tout ces self et autres _ n'apportent, a mon sens, rien à la compréhension du code; la preuve, le code Ruby n'en a pas et je le comprends aussi bien (alors que c'est probablement le premier programme ruby que je lis). Et puis passer self en parametre dans les définitions de méthodes, tu trouves ça justifiable/compréhensible ?-
[^]Re: Différence avec Python ?
Posté par Sébastien Bonnefoy (page perso, ) le 06/01/2005 à 10:16. (lien). Évalué à 1.Je pense qu'il y a aussi beaucoup une habitude de lecture.
Le fait de ne pas avoir de délimiteur de fin de bloc et de n'avoir que l'indentation est assez inhabituel pour qui ne fait pas de python, et c'est une bonne raison de le trouver moche. On trouve en général moche ce qu'on a pas l'habitude de voir. Je ne pense pas que ca vienne uniquement des décorateurs.-
[^]Re: Différence avec Python ?
Posté par Volnai () le 06/01/2005 à 10:25. (lien). Évalué à 2.Je ne parle pas Python courrament (ssshppfffffffsssshh), mais j'en ai déjà lu et compris avant, j'ai meme fait quelque programmes (pas violent non plus). Par contre je n'avait jamais lu de Ruby, donc là il ne s'agit définitivement pas d'habitude. Le fait d'avoir une bonne indentation, c'est une bonne idée, mais ca n'est pas perturbant, tout le monde (...) indente correctement son code, dans tout les languages (surtout en whitespace d'ailleurs, c'est encore plus important qu'en python : http://compsoc.dur.ac.uk/whitespace/(...) )
-
[^]Re: Différence avec Python ?
Posté par manatlan (Jabber id, page perso, ) le 06/01/2005 à 12:10. (lien). Évalué à 3.j'ai lu les 2 codes (et tous les trolls) ...
et franchement le code python m'a tout de suite parlé ...
le code ruby : franchement bof ... j'ai du m'aider du code python pour comprendre celui de ruby !
C vraiment une question d'habitudes ...
si tu viens de perl/bash ... le ruby te parlera mieux, c évident
si tu viens de tous les autres (excepté les eiffels,smalltalk, objc ...) ... le python te parlera plus ...
(je pense que plus de dev sur terre viennent du monde c/pascal/cobol/basic que du monde perl/bash)
et même si t'es pas développeur du tout, le python te parlera plus (c là son avantage sur sa syntaxe)
maintenant, il est vrai que je connais bien python, et très peu (voire pas du tout) perl/ruby/bash, ma vision est certainement un peu biaisé ...
et j'aime tellement le python, que quand je fais autre chose (c#/php/javascript/xslt principalement), je deviens fou juste à l'idée de devoir mettre des crochets partout ... alors que mon code sera toujours indenté correctement ...
alors, si je devais mettre des "end" comme en vb un peu partout, ça me plairait pas du tout (je hais vb)... et trouverai également que ça pollue énormément le code ...
quand au "__" de python, ça "pollue" ou "améliore la lisibilité" autant que les $ et @ de ruby ... question de goût (le géniteur de ruby , je crois, regrette d'avoir pris c décisions du début)
le cas du self : tu peux l'appeler "S" ou "_" au lieu de self, tu gagneras 3 caracs ... (par convention de programmation, self c mieux, evidemment)
maintenant, quand à l'argument ruby est full OO, alors que c venu après sur python .... bof aussi ...
car le full OO, t'obliges à programmer en OO uniquement ! et ça je sais pas si c'est un avantage ... (en python, t'as le choix)
encore un truc, je suis persuadé que je m'éclaterai plus en OO avec ruby avec python, c même certain ... mais je trouve que le code ruby est rempli de hiéroglyphes qui ne me parlent pas du tout au premier abord ... et ne me donnent pas envi ...
maintenant, tout ça est subjectif ... chacun ses gouts et ses couleurs (heureusement)
moi je choisi pas le langage en fonction de ses qualités intrasecs, mais en fonction de ce qui va m'apporter ...
et en python, au niveau libs, c bien simple, tu peux tout faire dans tous les domaines ...
au niveau ouverture, tu peux faire des classes java, tout comme des classes dot.net ....
et bientôt (avec starkiller, le compilo), on devrait même pouvoir générer des "executable", et venir concurrencer le C/exe
que demander de plus ? non ?-
[^]Re: Différence avec Python ?
Posté par Volnai () le 06/01/2005 à 13:01. (lien). Évalué à 2.Allez, je me répéte : c'est le premier code Ruby que je vois, alors que j'ai déjà un peu (trés peu, juste asser pour pouvoir le lire justement) toucher au Python, le seul language que j'ai pratiquer régulierement est le java, dont la syntaxe est plus proche du Python que de Ruby, donc l'argument sur l'habitude ne tient pas. Attention, je ne dit pas que le Python est incompréhensible (je fait aussi du perl un peu...), mais juste que le code est moins clair/espacé/fait_plus_mal_aux_yeux que celui de Ruby.
A mon avis, quelqu'un qui n'est "pas developpeur du tout" come tu le dis, il ne comprendra rien à aucun des deux codes.
Les quelques "end" te deplaisent ? un petit "end" sur un ligne ne me gene pas, en tout cas moins que de devoir mettre un self à chaque ligne, et en plus dans le prototype d'une méthode ! Serieusement, c'est comme ca qu'on fait en python ? Si oui, je ne comprends pas comment on peut defendre ca, en tout cas j'ai jamais eu à faire des constructeur avec "this" en paramétre en Java (d'ailleurs le this de java ne me plait pas plus que le self de ptyhon, mais j'ai l'impression qu'il est un peu moins présent). Franchement, si on est obliger de donner 2 parametres au constructeur d'une classe Square, ca me fait bien rigoler...J'imagine qu'il y à une bonne raison que je ne connais pas ?
quand au "__" de python, ça "pollue" ou "améliore la lisibilité" autant que les $ et @ de ruby
Non, apprends à compter, ou arrête la mauvaise fois, il y en a infiniment moins en ruby.
car le full OO, t'obliges à programmer en OO uniquement !
Et cette restriction te permet d'avoir un code plus structuré, contrairement à un langage "fourre tout" qui te permet de tout faire (perl etant l'exemple ultime). Et quand tu decide de programmer objet, autant prendre un "vrai" langage objet, et ne pas essayer de faire du procedural avec.
Si tu choisi un vraiment langage en fonction de son API, jette python et met toi à java ou .net. Ou perl.
-
[^]Re: Différence avec Python ?
Posté par pifou () le 06/01/2005 à 13:21. (lien). Évalué à 5.et franchement le code python m'a tout de suite parlé ...
C'est pas mal ça de dire que tu comprends mieux le code Python en disant 5 lignes plus tard que tu connais très bien Python :). De même je comprends beaucoup mieux l'anglais que l'allemand que je n'ai jamais appris :).
si tu viens de perl/bash ... le ruby te parlera mieux, c évident
Tu ne dois vraiment pas connaître Perl et Bash pour dire que Ruby ressemble à ces langages ! Mise à part les variables spéciales ($*) et les expressions régulières intégrées dans Ruby, il n'y a aucun point commun.
Après effectivement, pour des gens ayant appris à coder en C/C++ le Python sera surement plus lisible. Par contre le pense que Ruby est bien plus lisible pour des personnes ayant programmés en Java/SmallTalk/Eiffel que des personnes ayant fait du Perl/Bash.
(je pense que plus de dev sur terre viennent du monde c/pascal/cobol/basic que du monde perl/bash)
C'est à vérifier, car actuellement il me semble que dans les formations en informatique (sauf industrielle) on insiste plus sur les technologies objets (Java/C#/J2EE/.Net/C++ ...) que sur les langages procéduraux de type C/Pascal/Cobol/Basic qui sont bien sur toujours abordés pour des raisons historiques et techniques. Ça n'enlève rien à la puissance et l'utilité de ces langages.
et même si t'es pas développeur du tout, le python te parlera plus (c là son avantage sur sa syntaxe)
Pour la lisibilité du code pour un non développeur, je te trouve bien présomptueux, je ne me risquerais pas à dire quel langage serait le mieux. Tout dépend des bases que les personnes ont. Si tu apprends à quelqu'un à penser en procédural, il sera attiré par la syntaxe Python, en revanche si tu lui apprends à penser Objet, il sera surement attiré par Ruby.
maintenant, quand à l'argument ruby est full OO, alors que c venu après sur python .... bof aussi ... car le full OO, t'obliges à programmer en OO uniquement ! et ça je sais pas si c'est un avantage ... (en python, t'as le choix)
En Ruby aussi tu as le choix mais pour ce qui de programmer en 'full OO', personnelement je trouve que c'est un véritable avantage, ça te force à bien structurer ton programme. J'ai longtemps écrit des programmes en Perl qui marchait pas mal, par contre au niveau maintenabilité du code c'était ingérable. Je ne parle même pas de mes essais pour faire du code objet en Perl (quelle horreur, j'attends Perl6 pour voir si ça s'arrange de ce coté là). J'ai commencé à réécrire des programmes Perl en Ruby et effectivement même si c'est possible de faire une transcription bête et méchante (sans notion OO), j'ai très rapidement séparé mes bouts de code dans différentes classes. À la fin, je me retrouve avec un code moins long et beaucoup mieux organisé.
le cas du self : tu peux l'appeler "S" ou "_" au lieu de self, tu gagneras 3 caracs ... (par convention de programmation, self c mieux, evidemment)
J'aime bien les gens qui défendent mordicus les faiblesses/erreurs de conception d'un langage comme des 'features', que ce soit en Java (héritage simple), Perl (références), Python (le self dans les paramètres des messages). Pour ce qui est du 'self', je suis d'accord que c'est plus lisible de le laisser quand on fait appel à une variable, ça permet d'un coup d'oeil de savoir si une variable est locale ou appartient à l'instance de la classe. Mais de là à laisser le 'self' comme premier paramètre d'une méthode, c'est un peu gros :).
mais je trouve que le code ruby est rempli de hiéroglyphes qui ne me parlent pas du tout au premier abord ... et ne me donnent pas envi ...
Pour les 'hiéroglyphes', j'aimerais bien des exemples !
maintenant, tout ça est subjectif ... chacun ses gouts et ses couleurs (heureusement)
Ah, je suis enfin d'accord avec toi :). Mais je me suis permis de te répondre car je trouvais ton post un peu trop trollesque.
moi je choisi pas le langage en fonction de ses qualités intrasecs, mais en fonction de ce qui va m'apporter ...
Ah, pour moi les qualités intrasecs d'un langage jouent beaucoup sur ce qu'il va m'apporter. Le pouvoir d'expression d'un langage est pour moi très important, j'ai horreur de passer 2 heures pour trouver une façon d'avoir une fonctionnalité non incluses dans un langage (genre surcharges des classes de bases, modification à l'exécution de code des classes ...).
et en python, au niveau libs, c bien simple, tu peux tout faire dans tous les domaines ...
Tu serais surpris de voir le nombre de libs disponibles en Ruby, même si ces dernières sont actuellement dispatchées et manque de suivies (vive RubyGems).
au niveau ouverture, tu peux faire des classes java, tout comme des classes dot.net ....
C'est aussi possible pour Java en Ruby en utilisant JRuby http://jruby.sourceforge.net/(...) .
que demander de plus ? non ?
Personnelement, je demanderais à Python de devenir vraiment objet, d'inclure les itérateurs à la manière de SmallTalk ... il semblerait que les dernières version de Python répondent à certaines de ces attentes ... hélas j'ai depuis longtemps trouvé un langage réalisant déjà cela : Ruby.
Bref, Python et Ruby, ça n'est pas pareil, et c'est un peu idiot de les comparer même s'ils ont la même cible. Tu préféres Python, je préfére Ruby, chacun à ces raisons, mais j'ai au moins l'avantage d'avoir essayé pas mal des langages de script (je fais aussi du Python de temps en temps) avant de donner mon avis.-
[^]Re: Différence avec Python ?
Posté par manatlan (Jabber id, page perso, ) le 06/01/2005 à 21:01. (lien). Évalué à 2.> 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 ...-
[^]Re: Différence avec Python ?
Posté par pifou () le 06/01/2005 à 22:07. (lien). Évalué à 2.Ouais, je suis pas trop convaincu (on s'en serait douté :), dans un langage objet il me semble logique de considérer qu'une méthode est de base d'instance, le cas des méthodes statiques étant moins courant (sauf librairie spéciale, style File, Dir, Math ...). Je trouve plus parlante la syntaxe de Ruby pour différencier les deux :
class Toto def Toto.coincoin # méthode de classe end def plop #méthode d'instance end end
De plus, dans Python le fait de laisser le choix au programmeur de choisir le nom de la référence sur l'instance courante ne peux poser que des problèmes de maintenabilité (genre il doit bien y avoir des gars qui mettent 'this' (pour les fans de Java/C#/C++/Php) au lieu de 'self', voir 'current' (pour les fans de Eiffel), 'plop' (pour les moules) ...). Du coup je me demandais comment on faisait en Python pour accéder à la méthode définie dans la super-classe (mot clé 'super' en Ruby/Java/SmallTalk) ? en cherchant vite fait sur google je suis tombé sur cette page http://merd.sourceforge.net/pixel/language-study/syntax-across-lang(...) (assez marrante ma fois) qui m'apprend que ça ressemble à ça : super(Class, self).meth(args), j'ai connu plus simple comme syntaxe (tu peux remarquer l'effort que je fais pour lancer un nouveau troll :).
-
-
[^]Re: Différence avec Python ?
Posté par manatlan (Jabber id, page perso, ) le 06/01/2005 à 21:34. (lien). Évalué à 3.> 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++ ...
bon je retourne dans mon ".rb"-
[^]Re: Différence avec Python ?
Posté par Alex () le 06/01/2005 à 21:53. (lien). Évalué à 2.l = list.collect {|i| i*2 if i > 10} (pour éviter tout nouveau troll sur la syntaxe on peut mettre un retour a la ligne et un end a la place des accolades)
sinon je te laccorde le code python me parait également plus compréhensible sur une première lecture.
Mais bon je ne pense pas que tous ces petits éxemples permetent de se faire vraiment une idée sur le langage-
[^]Re: Différence avec Python ?
Posté par pifou () le 06/01/2005 à 23:19. (lien). Évalué à 2.Ouais, pour la lisibilité, je pense qu'à ce niveau la c'est une question d'habitude, personnelement, le collect me parait plus parlant ayant déjà fait du SmallTalk (qui comme son nom l'indique devait être du PetitParlé). Mais pour respecter l'esprit SmallTalk j'aurais plutôt écrit le code suivant même si c'est un peu moins optimisé (on peut remplacer 'select' par 'find_all' si on veut):
puts (0..20).to_a.select{|i| i>10}.collect {|i| i*2}
Ça fait plus PetitParlé donc logiquement plus lisible : j'ai un Range de 0 à 20 que je transforme en tableau (to_a) dans lequel je cherche tous les éléments supérieur à 10 (select) sur lesquels j'applique (collect) l'opération multiplier par 2. L'avantage de cette façon de faire c'est qu'on enlève les 'nil' qu'on retrouve dans ton code (un collect retourne toujours un tableau de même taille qu'à l'entrée).
Pour en revenir au post au dessus de manatlan pour les @ et $, c'est une façon comme une autre de mettre en valeur les variables globales et les variables d'instance. Ça vaut bien le self, et en plus ça a l'avantage de différencier l'accès d'une variable d'instance d'une méthode ayant le même nom (genre si tu as mis un attr_reader sur ta variable toto, le self.toto appel la méthode et le @toto fait référence à l'objet, dans le fond ça ne change rien sauf si tu commences à avoir des attributs dérivés).
Pour l'histoire des '!' et '?', je trouve ça très clair, les méthodes finissant par '!' indique que tu modifies directement l'objet sur lequel tu appelles la méthode au lieu de renvoyer un nouvel objet modifié. Pour le '?' ça te permet d'un seul coup d'oeil de savoir que la méthode retourne un booléen, et je trouve que quand on lis 'toto.nil?' on se dit tout de suite (car on a l'habitude de prononcer les phrases finissant par '?' d'une façon intérogative) qu'on demande juste si toto vaut 'nil'.
-
-
-
-
[^]Re: Différence avec Python ?
Posté par Frederick Ros (page perso, ) le 06/01/2005 à 14:03. (lien). Évalué à 1.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)
Euh .. je viens du monde C, pur et dur, et franchement j'ai jamais ete foutu de lire correctement et sans me prendre la tete ne serait-ce qu'un petit bout de Python ... Ce qui n'a pas ete le cas .../
IMHO c'est pas une question d'habitude .. Plus d'esthetisme personnel .
alors, si je devais mettre des "end" comme en vb un peu partout, ça me plairait pas du tout (je hais vb)... et trouverai également que ça pollue énormément le code ...
Ben pour moi c'est juste l'inverse .. L'idee que si jamais un gard se met a mettre des tabs, qui n'ont pas le meme nombre de characteres chez lui que chez moi, et que c'est ca qui va m'indiquer la logique me fait froid dans le dos
le cas du self : tu peux l'appeler "S" ou "_" au lieu de self, tu gagneras 3 caracs ... (par convention de programmation, self c mieux, evidemment)
Que tu l'appelles self, S ou machin ne change rien. Il ne sert a rien... sauf a ressembler a une approche object codee en C...
car le full OO, t'obliges à programmer en OO uniquement ! et ça je sais pas si c'est un avantage ... (en python, t'as le choix)
En Ruby aussi .. mais meme si tu definis ce qui te semble etre une fonction, c'est en fait une methode de la classe Object...
A savoir aussi : less class que tu definis sont des instances de la classe Class :)
encore un truc, je suis persuadé que je m'éclaterai plus en OO avec ruby avec python, c même certain ... mais je trouve que le code ruby est rempli de hiéroglyphes qui ne me parlent pas du tout au premier abord ... et ne me donnent pas envi ...
Quels hiéroglyphes ? Le @ ? Il n'apparait que raremement et vaut largement les __ de Python !-
[^]Re: Différence avec Python ?
Posté par manatlan (Jabber id, page perso, ) le 06/01/2005 à 19:25. (lien). Évalué à 3.... sleeper, volnai, volnai ...
ça troll, ça troll ...
vous avez repris mes phrases les plus secs ;-), et ressorti l'argumentation habituelle ...
Alors, continuons dans le troll un peu ...
le "full oo", c'est un peu le graal tant promis, et au final on se rends compte que ça ne réponds pas tout à fait au côté maintenance, lisibilité ... tout ce qu'avais fait miroité l'arrivé de l' OO ...
preuve en est, qu'on en est à l'AOP, pour s'adapter un peu mieux aux besoins réels ...
J'ai rien contre le tout objet ... mais quel programmeur a déjà réussi à faire un très beau model objet ... en tenant compte de la lisibilité, de la maintenabilité, des temps de réponses, et des ressources utilisés ?
pour réunir tous ces critères, en programmant full oo, c'est quand même balaise ...(generalement y a des compromis à faire ... non ?)
VOus trouverez plein d'urls sur le net qui vous expliqueront que le "full oo" est à éviter dans bien des cas ... ;-) (je vais me faire tuer là ;-)
J'adore l'objet, et comme je l'ai déjà dit, je pense très certainement que je m'éclaterai bien plus avec ruby qu'avec python ... c certain !
Chacun des gouts évidemment ... il est evident que le python possède une construction objet postérieure (le python est même plus vieux que le java !) ... Le guido, ses potes et les PEP ont quand même réussi à en faire qqchose de vraiment bien, et bien réfléchi (le mec de ruby ne cache d'ailleurs pas qu'il s'est très largement inspiré de python, et donc que ruby ne serait pas ce qu'il est sans python)
finissons les trolls ...
qu'est ce qui compte après tout ?, et je me répète encore, c'est ce que tu vas pouvoir faire avec ...
et en python, les libs il y en a pour tous les gouts et tous les domaines (TOUS) ...
je sais qu'en ruby il y en a aussi ...
pour tout dire, j'avais testé le python il y a 2 ans, et j'avais abandonné ...(je faisais du code avec tk, et ça ne me plaisait pas)
l'année d'après, il fallait que je trouve un langage de script multi plateforme, et capable de faire du gui, traiter des images, etc ...
et j'hésitais entre ruby et python ... j'ai finallement choisi python, (avec wxpython et pil pour commencer)
la syntaxe de ruby ne me convenait pas trop, et les libs (bien qu'il existait un ersatz de wxruby) étaient mal documentées, etc ...
du google avec python, et je trouvais tout ce dont j'avais besoin ...
après je suis allé plus loin avec python (du reseau avec twisted, du jeu avec pygame, du web avec mod_python/cherrypy, du dev de gui ultra simple avec pythoncard, et même des chutes d'objets avec vpython : très fun) ...(je projette d'essayer soya3d, moteur 3d en python)
(je ne parle même pas de toutes les petites libs qu'on trouve ici et là pour extraire/remettre les données du palm, extraire les tags de la soupe html, les sqlobject/xmlobject, extraire les exif ... etc ... (pk il y en a pour tous les gouts/besoins))
bref, rien ne me manque ... tout est dispo ...
certes ruby est jeune, et pas assez connu (et c dommage), par conséquent moins de libs (je doute qu'il existe un equivalent de twisted, vpython, peut être un pygame-ruby (apparemment rubl mais c tout jeune) ?
ruby a beau être plus objet, et "plus beau syntaxiquement" (attention subjectivité), tu finiras par plus coder pour piloter sdl, qu'un prog en pygame ... et je crois que c pareil dans tous les domaines ... (là je vais me faire incendier) ...
maintenant, arrêtons les trolls totalement ... chacun sa croix !
chacun son choix ! et vive la liberté de choix qu'on a !
et pour affuter mes arguments la prochaine fois, je vous promet de me mettre à ruby ...(vous me verrez dans les forums ruby)-
[^]Re: Différence avec Python ?
Posté par Frederick Ros (page perso, ) le 06/01/2005 à 19:47. (lien). Évalué à 2.... sleeper, volnai, volnai ...
ça troll, ça troll ...
Nope. Je reponds juste avec mes arguments. Comme je l'ai dit c'est avant tout une histoire de gouts....
le "full oo", c'est un peu le graal tant promis, et au final on se rends compte que ça ne réponds pas tout à fait au côté maintenance, lisibilité ...
Je suis pas forcement pour le tout OO dans mon design (d'ailleurs je ne fais de l'objet que pour m'amuser... dans mon boulot, je fais un edsign oriente objet et j'implemente en C). Par contre ca me plait qu'un langage dit "a objet" soit coherent... Si tout n'est pas objet je ne trouve pas ca coherent...
ruby a beau être plus objet, et "plus beau syntaxiquement" (attention subjectivité), tu finiras par plus coder pour piloter sdl, qu'un prog en pygame ... et je crois que c pareil dans tous les domaines ... (là je vais me faire incendier) ...
Avant d'avoir ces extensions, Pyhton ne les avait pas ;)
Ce qui me plait avec Ruby c'est aussi sa communaute, et le fait que ca bouge pas mal ... Il suffit de regarder le bruit que commence a faire Ruby on Rails (www.rubyonrails.com) chez les dev d'appli web, et de voir que pas mal de dev Java commence a trouver tout cela interessant (http://www.vanderburg.org/Blog(...) et http://howardlewisship.com/blog/2005/01/playing-with-ruby.html(...) par exemple) ...-
[^]Re: Différence avec Python ?
Posté par manatlan (Jabber id, page perso, ) le 06/01/2005 à 20:07. (lien). Évalué à 2.> 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 ;-)-
[^]Re: Différence avec Python ?
Posté par Frederick Ros (page perso, ) le 06/01/2005 à 22:06. (lien). Évalué à 1.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 ...
Ben non ce n'est pas le seul ... La seule difference c'est la productivite obtenue ... Regarde a nouveau la video de 10 minutes sur comment faire un blog (c'est juste un exemple) ...
Si Rails n'etait pas aussi novateur penses-tu que la communaute Java se mettrait a essayer d'implementer un 'Java on Rails' ?
sinon on trouve aussi des urls de java addict qui sont interessés par des frameworks web pour python ;-)
Sans doute mais ces edrnieres semaines, c'est surtout des gens qui se tournent vers le couple Ruby / Ruby on Rails ;)-
[^]Re: Différence avec Python ?
Posté par manatlan (Jabber id, page perso, ) le 06/01/2005 à 23:11. (lien). Évalué à 2.je suis allé voir ...
Pas mal effectivement ... mais rien de bien épatant ...
C'est vraiment un framework avec beaucoup d'objets à hériter ... et qui a pas l'air très rigide ...
(Un gars sous VS.net avec les assistants pour l'asp.net devrait réussir à faire un peu prêt la même chose dans les mêmes temps (sauf l'installe de dot.net / vs.net qui est énorme ;-), et genera un code pourri, ça je l'accorde aussi ;-)
Et j'ai vraiment l'impression que ça a les mêmes travers que "l'asp.net" ... à savoir, tant que tu suis le droit chemin (imposé ici par la conception objet), tu t'en sortiras ... mais dès que tu veux sortir un peu des sentiers battus : c'est un peu la galère ...
(mais bon, c'est le propre des frameworks qqpart)
C'est toujours le même problème récurrent avec ces "produits tout fait" ...
maintenant il est évident que je préfèrerai faire du rubyOnNails que de l'asp.net, pour 1001 raisons !!!!
maintenant, pour revenir sur le sujet "python différences"
le binding des urls page/params sur les class/méthodes/arguments, tu l'as déjà dans pas mal de framework python (et autres) ... cherrypy2 serai mon choix (car il impose très peu de choses)
le binding sur la bdd, je le ferai avec SQLObject ...
on arrive déjà à qqchose qui ressemblerait pas mal ...
comme j'expliquais avant, et comme je l'ai vu sur la video, les templates de RoN ne sont pas fait pour des graphistes (vu le code ruby que j'ai vu dedans, ça fait peur ... ça s'adresse clairement aux informaticiens) ...
je choisirai le moteur de template cheetah/python (pour avoir un beau balisage qui ne perturbera pas le graphiste dans son dev)
je monte qques classes pour encapsuler sqlobject/cheetah dans cherrypy (et qques balises pour controller les )... et """j'ai quasiment la même chose ... en plus souple""" (en étant le dev du binz je le connaitrai bien, il sera multibdd, avec des templates puissants, et pourra tourner indifféremment sous apache/iis ... en cgi, comme en mod_python ... ou alors avec le httpserver embedded de python)
Là où rubyOnNail fait très très très fort ! C'est la vidéo ! Il est évident que ça peut en jetter pas mal (surtout pour des devs web java ;-), php ou asp.net)
La communication sur un truc comme ça, c'est déjà 80% de fait !!! Et ça, c énorme !!!! Je comprends maintenant pourquoi on en parle temps !
Là où dans python, on se bat avec une 30aine de framework, qui communique "mal" sur leurs features ! ça fait mal !
EN tout cas ! bravo ! excellente vidéo qui présente bien la puissance du produit ! et la simplicité d'utilisation et d'installation !-
[^]Re: Différence avec Python ?
Posté par Frederick Ros (page perso, ) le 07/01/2005 à 08:50. (lien). Évalué à 1.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 ;-)
Je suis pas sur que .NET puisse faire aussi simple ... Un des grands avantages de Ruby (et sans doute de Python je pense) dans ce cas est la generation a la volee des classes, ainsi que l'ajout de methodes par objet. ... Avec Ruby On Rails pas la peine de redemarrer ton appli, les changements fait dans le code sont pris a la volee...
Et j'ai vraiment l'impression que ça a les mêmes travers que "l'asp.net" ... à savoir, tant que tu suis le droit chemin (imposé ici par la conception objet), tu t'en sortiras ... mais dès que tu veux sortir un peu des sentiers battus : c'est un peu la galère ...
(mais bon, c'est le propre des frameworks qqpart)
Je pense pas que l'on soit aussi coince .. Il y a qq conventions a respecter (mais apparamment d'apres ce que j'ai lu de certains utilisateurs ca n'est pas 100% obligatoires ... et ces memes utilisateurs apres etre sortis des chemins battus se sont remis a suivre la convention trouvant qu'elle avait un sens ..)
le binding sur la bdd, je le ferai avec SQLObject ...
Ben la tu choisis ... Par defaut ce sont les bindings SQLRuby, mais tu peux aussi utiliser Postgres, Oracle, SQL Lite ...
comme j'expliquais avant, et comme je l'ai vu sur la video, les templates de RoN ne sont pas fait pour des graphistes (vu le code ruby que j'ai vu dedans, ça fait peur ... ça s'adresse clairement aux informaticiens) ...
Ben c'est du rhtml .. Comparable a du JSP ou autre "embedded" ...
(en étant le dev du binz je le connaitrai bien, il sera multibdd, avec des templates puissants, et pourra tourner indifféremment sous apache/iis ... en cgi, comme en mod_python ... ou alors avec le httpserver embedded de python)
L'interet c'est que justement d'autres devs le trouvent facile : http://43things.com/entries/view/562(...)
Mais si c'est aussi facile en Python pourquoi ne pas le faire ?
Là où rubyOnNail fait très très très fort ! C'est la vidéo ! Il est évident que ça peut en jetter pas mal (surtout pour des devs web java ;-), php ou asp.net)
La communication sur un truc comme ça, c'est déjà 80% de fait !!! Et ça, c énorme !!!! Je comprends maintenant pourquoi on en parle temps !
La ou son auteur fait fort c'est aussi sur le temps qu'il passe dessus .... Il est extremement reactif et tres productif-
[^]Re: Différence avec Python ?
Posté par manatlan (Jabber id, page perso, ) le 07/01/2005 à 08:59. (lien). Évalué à 2.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 ...-
[^]Re: Différence avec Python ?
Posté par Frederick Ros (page perso, ) le 07/01/2005 à 09:11. (lien). Évalué à 1.Y'a aussi ce genre de choses en Ruby .. et d'autres assez marrante au niveau de l'ecriture comme : http://onestepback.org/index.cgi/Tech/Ruby/BuilderObjects.rdoc(...)
-
-
[^]Re: Différence avec Python ?
Posté par manatlan (Jabber id, page perso, ) le 07/01/2005 à 09:05. (lien). Évalué à 2.> 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 ...
-
[^]Re: Différence avec Python ?
Posté par manatlan (Jabber id, page perso, ) le 07/01/2005 à 20:07. (lien). Évalué à 2.au sujet de ruby on rails
il y a des pythoneux qui wiki'ise ici : http://wiki.rubyonrails.com/rails/show/PythonOnRails(...)
et qui cherche à monter l'idem en python ...
et il se baserait sur cheetah+sqlobject ... (c'était aussi mon avis ;-)
Et il y a aussi un rubien qui dit qu'ils ne devraient pas se lancer là dedans, et laisser une chance à ruby d'avoir sa killerapp ;-)
Mais les rubistes, ne vous inquietez pas trop ... la vidéo python ne verra jamais le jour ;-)
-
-
-
-
-
-
[^]Re: Différence avec Python ?
Posté par pifou () le 06/01/2005 à 19:58. (lien). Évalué à 1.Réponse rapide sur le "full OO", il faut être un peu stupide pour croire qu'un langage/framework/notion puisse être la solution idéale à tous les problèmes ... comme dans la vie réelle il n'existe pas de solution miracle. L'avantage avec l'objet c'est que ça a permis de faire évoluer le pouvoir d'expression de pas mal de langage informatique, de faire évoluer les mentalités des informaticiens, d'ajouter une couche d'abstration supplémentaire par rapport au langage machine.
J'ai commencé l'informatique en apprenant l'UML et Java (et Perl) (en 1998 il me semble), mais déjà à l'époque on voyait les limitations de ces langages mais c'était déjà mieux que le bon codage pourri qui était encore de mise dans pas mal de boite d'informatique (méthodologie, structuration, maintenabilité ? on ne construit pas des voitures ici on fait du code !). Le problème, c'est que le premier langage objet à rentré dans l'industrie c'était Java et qui 7 plus tard commence à combler les manques qu'il pouvait avoir par rapport à des langages comme SmallTalk (début des années 80). Évidemment, Sun & co on fait de la pub sur la force de Java sur la notion de réutilisabilité, de maintenabilité, d'intéropérabilité qu'apportait leur langage ... mais c'était avant tout de la pub !
Le problème de l'informatique c'est la synergie des entreprises toujours frileuses à changer de technologie, finalement je défend Java car il a permis de faire évoluer les entreprises. Si tu veux découvrir la prochaine révolution niveau notion de programmation fait un petit tour sur les sites des laboratoires de recherche en génie logiciel, pour ma part la programmation orienté aspect ne me convainc pas plus que ça.
Enfin, pour ce qui est des librairies, j'ai eu exactement la même reflexion que toi, sauf qu'à mon époque c'était Perl qui détendait le maximum de fonctionnalités. Après mettre cassé la tête pour faire de l'objet sur ce langage, je suis passé à Ruby. Et vu l'évolution de ce langage, je pense que le retard par rapport à Python sera vite comblé. On est actuellement à la phase adaptation des librairies natives comme SDL, OpenGL ... arrivera ensuite les librairies plus haut niveau (comme pygame). Entre temps, l'interpréteur Ruby aura gagné en rapidité (utilisation de Parrot ?) et pourra enfin concurencer ses cousins interprétés :).
Bon, je m'arrete la, j'ai un peu pris plus de temps que j'avais prévu au début :)-
[^]Re: Différence avec Python ?
Posté par manatlan (Jabber id, page perso, ) le 06/01/2005 à 20:51. (lien). Évalué à 2.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 ...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.