Frederick Ros a écrit 127 commentaires

Evernote est aussi tres bien ... Il permet de prendre ses notes via le web, via un client (Windows ou OS/X mais possibilite d'utiliser wine), est accessible a travers les mobiles (l'appli iPhone est vraiment tres bien), fait de la reconnaissance de caracteres dans les photos jointes (pratique pour la recherche), est gratuit (mais on peut passer en mode Premium pour uploader + de notes)

Sans oublier, en ligne de commande, ri ...

> 15.times plutot que des for(truc = 1; i<=15; i++) et j'en passe.

Tu peux tj faire un (1..15).each {|i| ... } si vraiment tu en as envie ;)

> Je vais jouer vieux con, je reste au C++, je peux encore utiliser avec lui du code écrit il y a 15 ans (et c'est souvent utile, il y a 15 ans des pregrammeurs n'étaient pas idiots...)

Mouais .. qu'on ne me parle pas de la lisibilité du code C++ écrit il y a 15 ans ... ni des pseudo-codeurs C++, qui font soit du C compilé avec g++, soit une demonstration de tous les design patterns (généralement 2) qu'ils connaissent ...

Pour ce qui est de la pérénité, de mémoire, la première version de Ruby date de 1995 ...

... ensuite tout est une histoire de gout ...

Finalement, pourquoi les gens aiment t-il ruby ?
=> A cause de ruby on rails

Generalement les gens aiment Ruby pour Ruby .. Certes Rails a donne un coup de boost a Ruby (ou du moins a l'eclairage "mediatique"), mais nbon .. j'ai commence Ruby alors que Rails n'existait pas .. et j'ai aime Ruby pour sa syntaxe claire et concise ... entre autre


Pourquoi ruby on rails ?
=> Parce que ca sonne bien, avec du AJAX dedans, le site est joli et y a une demo avec textmate sous OSX en video.

Hum .. certes ils sont tres forts cote marketing ... mais c'est bien plus que cela ... Developper une appli avec Rails c'est vraiment amusant ... et c'est pour cela que les gens aiment Rails

Sinon ca a l'air tres pythoniens comme langage mais je goure peut etre =)


Pas d'insulte s'il te plait !! ;) :) ;) ;)

Un peu comme perl quoi ...

Y'a aussi RubyCocoa ... http://rubycocoa.sourceforge.net/doc/

>Et bizzarement dans tous ces projets tu retrouve rarement du Python ou du Ruby ;)

Normal .. ces 2 languages sont suffisamment concis pour ne pas prendre plusieurs centaines de milliers de ligne de code pour ton projet ;)

: ce sont des langages de script dynamique

NON. Ce sont des languages dynamiques.

> et du typage statique.

Sans rentrer dans votre debat, je ne suis pas forcement pour ... :) Viva el Duck Typing !

>Puis bon, si tes développeurs sont incompétents ce n'est malheureusement pas un typage statique contrôlé qui va résoudre tes problèmes ;)

Tu l'as dit .. des sous-equipes sur de petites parties, des unit-test obligatoires (mieux du TDD) et de la revue de code .... c'est quand meme mieux non ?

Chez les hebergeurs francais, je sais pas mais y'a:

http://textdrive.com/(...)
http://planetargon.com/(...)
et apparament le petit dernier:

http://www.dreamhost.com/(...)

tu peux aussi bidouiller sur freeshell.org ...

>Ce que je suis en train de te dire, c'est qu'on parlait de rails, et que toi tu dis "Si tu regardes des trucs comme BackPack (...), c'est assez sympa", moi je dis ouais c'est sympa, mais ça a rien à voir avec rails ...

Effectivement puisque tu le dis, ca n'a rien a voir avec Rails .. Ca a ete fait en shell.

TaskThis c'est pareil, c'est sympa, ça pourrait être fait en n'importe quoi, ça prouve en rien que rails est bien (ou non).

NON. La difference est dans le code que tu as a ecrire (entre autre). J'ai mentionne TaskThis car tu demandais un example (je ne vois d'ailleur pas pkoi tu en as besoin si tu connais deja:)

Evidemment tout peut-etre fait en n'importe quoi .. mais bon je pense que dans l'ensemble un taskThis sera plus simple a faire avec Rails qu'en Cobol .. mais je me trompe peut-etre et c'est vrai que ca ne montre pas que Rails est mieux que le Cobol pour ecrire un appli web.


Tout ce que je vois avec rails pour le moment c'est que c'est chiant à mettre en place,

Moi pour ce que je fais avec je vois pas en quoi c'est chiant .. mais encore une fois tu peux envoyer des patchs pour simplifier le process d'installation !

que ceux qui en parlent le plus sont ceux qui ont pas essayés en fond de faire un site complet avec, et que ceux qui l'utilisent le mieux font partis des développeurs rails (ou pas loin).

C'est un peu comme les gens qui denigrent au lieu d'essayer de faire avancer le schmillibilick en envoyant des patches quand ils sont de bonnes idees.

Et question perfs, ça a rien à voir.

Woa ... l'argument massue :)

L'Ajax n'est venu dans Rails que recemment .. On peut tres bien faire des sites sans Ajax ... C'est juste une feature (simple) a ajouter ...

Alors va voir TaskThis! (http://taskthis.darthapo.com/account/login):(...) c'est en gros l'exemple donne lors de l'introduction de Ajax dans Rails...

>J'apprécie et je teste les sites faits par les mecs de rails, mais ces sites ne sont bien que parce que les mecs qui les codent sont bons. Flickr est pas codé sous rail, ni google map...

C'est sur qu'un mec bidon meme avec la meilleure des technos va pondre une merde ... mais si tu te referes au niveau des codeurs pour juger une techno ben .. je comprends pas vraiment :(

Je vois pas bien le truc la ...
Typo est un outil fait avec Rails .. ce n'est pas Rails ...
Si tu regardes des trucs comme BackPack ou YubNub (http://www.yubnub.org/,(...) fait en 24 h lors du Rails Day), c'est assez sympa ...
De meme si tu recuperes certaines des applis faite en utilisant rails et que tu regardes le code source tu seras (peut-etre) surpris par la clarte et le peu de LOC necessaires ...

Le mieux pour s'en faire une idee c'est de developper qq chose avec .. pas d'utiliser un outil qui est base sur Rails :)

Mes .2 $

Et tu fais quoi des contributeurs .. Si chacun avait fait ce que Linus est en train de faire, on n'aurait certainement XXX OS libres non-finalises ...

Alors pourquoi ne pas l'utiliser ?

Je parlais du cas de l'opportunité ou non d'intégrer une équipe déjà en place.

C'est bien ce que je disais .... C'est plus dur d'integrer l'equipe de dev Linux que de passer direct sous Winblows.

Si windows correspondait à ses besoins à l'époque, on aurait effectivement pas de linux. Mais où aurait été le mal, si le produit correspondait à ses besoins ?

Il n'y a aucun mal.. mais si chaque contributeur Linux avait fait pareil, on en serait a XXX OS libres ..

Participer à un truc déjà existant, c'est trés dur : il faut déjà avoir le temps de se plonger dans le code existant; il faut avoir le temps de tisser des liens avec les développeurs actuels.

C'est vrai .. pourquoi developper pour le noyau. Autant acheter Winblows XP, au moins y'a pas besoin de regarder des sources pour essayer de comprendre/fixer un bug et par la-meme en faire profiter d'autres ,,,

D'ailleurs, je te rappelle que "répondre à ses propres besoins", c'est un peu la philosophie du logiciel libre ;-) Si t'es pas content, envoie un patch :-p Et si t'es vraiment pas content, développe un autre produit "concurrent".

De ce que j'ai vu, Monotone etait considere comme "trop lent" .. Je crois pas qu'il se soit donne la peine de poster un patch pour qu'il soit plus rapide et par la-meme aider la communaute des utilisateurs de Monotone (dont je ne fais pas partie).
Avec cette philosophie la, on aurait eu 10.000 OS libre au lieu d'avoir 10.000 personnes aidant a developper un OS.

Puis certes, comme le dit Linus, Monotone est lent. Mais je trouve plus que dommage, qu'au lieu d'investir un peu (tant en termes d'efforts de dev ou d'argent) sur l'evolution d'un SCM decentralisé existant qui serait utilisé par les devs de Linux, bah Linus choisit la voie du "je me fais ma sauce dans mon coin".

Je suis assez d'accord avec toi ... Le syndrome du "Not invented here" ?

Un truc marrant:

> The Zen of Python, by Tim Peters
> ...
> Although that way may not be obvious at first unless you're Dutch.

"It also makes sense if you grew up Pennsylvania Dutch [...]"

Bruce Eckle, commenting on the readability of a given Ruby example.

http://onthethought.blogspot.com/2005/01/thinking-in-ruby-not.html(...)

:)

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 !

C'est le blog de l'auteur "thinking in java" (et thinking in python) qui explique pourquoi il ne fera pas "un thinking in ruby" ...
http://onthethought.blogspot.com/2005/01/thinking-in-ruby-not.html((...))

On doit qvoir les memes sources ;) je l'ai lu aussi aujourd'hui ... et aussi certains autres commentaires sur la Ruby ML, ou un pythonneux est venu demander pourquoi tous les Rubyistes ne se mettaient pas a Pyhton ...
Et c'est vrai que les memes arguments reviennent .. et en premier lieu le 'One Way' ...

Je sais aussi pourquoi j'aime Ruby ;)

.(si on commence déjà à gambergé de la meilleure manière d'implémenter son simple if/then/else, on avance pas)

Justement .. on ne se pose pas la question: on ecrit ...

Tout ça uniquement pour rendre les programmes "rock solid" (erreurs de types trappées à la compile), aider les futurs compilateurs à générer du code natif ... bref, aider à faire pénétrer python encore et toujours dans le milieur des entreprises ....

Oui j'ai vu ca .. mais je ne suis pas encore convaincu du benefice reel d'un typage fort. En pratique (du moins en Ruby) les erreurs du a du 'trans-typing' sont extremement rares .. maintenant qu'il soit optionnel ...
Dans le camp Ruby on prend presque la direction opposee : le Duck Typing : 'If it walks like a duck, and talks like a Duck, then it's a Duck' .. qui est vraiment tres pratique ...

Vive python, vive ruby, vive [votre langage préféré] ! Vive cette diversité, et vive ce bouillon d'idées qui germent de tous les côtés de la toile grace à une floppée de petits gars qui pensent, qui discutent et qui agissent
Le monde informatique du futur sera vraiment plus qu'interessant ...

Tout a fait d'accord avec toi ..