reno a écrit 3886 commentaires

Tu as tord, j'aime bien le parachutisme aussi!

>>Un bon développeur fera toujours du bon code quelque soit le langage.<<

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..

Pourquoi il faut ajouter les __ dans la deuxième version en Python?

>>- Pas de support de l'Unicode, qui est pour moi _le_ plus gros problème de Ruby.<<

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..

Il y a principalement deux choses que je n'aimais pas avec OCaml:
- l'accent mis sur le coté fonctionnel: pour un langage soi-disant multi-paradigme, le manuel (soit dit en passant le manuel était en Français, c'est rare) mettait bien trop l'accent sur le coté fonctionnel a mon gout..

- la syntaxe, et apparemment je ne suis pas le seul a ne pas l'aimer car il y en a une autre qui existe et Microsoft pour faire F# en a pris encore une autre (qui a l'air pas mal du tout celle la)..


Donc ces obstacles m'ont rebuté pour apprendre le langage, mais je ne considère pas pour autant qu'OCaml soit un mauvais langage, juste pas interressant pour moi (par contre je considère Perl5 comme un mauvais langage)..

>Je me suis toujours dis que Ruby faisait double emploi avec python.

Je suis plutôt d'accord: quand je recherchais un nouveau langage (dégoutté de Perl), apres avoir tenter et rejeter Ocaml, j'ai été bien perplexe pour choisir entre Python et Ruby car je trouve ces langages très semblable..

Mais au final je préfère la syntaxe de Ruby a celle de Python, donc pour moi c'est Python qui fait double emploi avec Ruby pas le contraire..
:-)

>>"Quand au fait que les linuxiens feraient mieux de regarder comment marche leur système", ça relève malheureusement du troll bas de plafond, con, mesquin et gratuit.<<

Je ne suis pas d'accord: c'est bien connu que les developpeurs du kernel Linux signent des NDA pour les specs dont ils ont besoin pour les drivers..

C'est d'ailleurs un point de discorde entre les dev OpenBSD et Linux..

Donc pourquoi utiliser Linux et s'inquieter quand les dev Samba font la même chose que les dev du kernel Linux???

Ca fait très '2 poids, 2 mesure'..

est prévu d'être --> est prévue pour être

Je n'ai pas bien compris si la 1.9.0 est une version de developpement juste utile pour les developpeurs de Ruby (comme le kernel Linux 2.5.) ou si cette branche est prévu d'être utilisé par tout le monde..

Non, ça n'existe pas, pas parce qu'ils sont contre mais parce que personne ne l'a fait: c'est dans la FAQ..

Ca ne doit pas être simple d'ailleurs d'ajouter un 'modèle de dégât' pour les avions et une AI intéressantes..

>>Je vois en Perl6 une solution toute en un qui remplacera aussi bien Sh que Python, PHP ou Ruby.<<

Amusant ça, moi je vois en Ruby la raison pour laquelle pas mal de monde ne s'intéresse pas a Perl6..
Après tout quitte à réapprendre un langage (Perl6 est suffisamment différent de Perl5 pour que ce soit quasiment un réapprentissage), pourquoi ne pas en utiliser un plus propre et qui existe maintenant?

Comme quoi, midi, la porte, tout ça.. :-)

>Et vous, quel utilisation de perl faites-vous ?

Le moins possible!

Merci pour la présentation.

Elle est bien faite, le seul reproche que je lui ferai est qu'elle ne parle que des points forts de Ruby.
Lister les points faibles/limitations est, je pense, nécessaire aussi lors d'une introduction.

Pour Ruby: les performances, Unicode, le threading.

Pour RoR: marche mieux si on construit une application avec le schéma qui va bien pour RoR plutôt que si on réutilise un schéma existant (possible aussi mais l'intéret de RoR en est diminué a ce moment).

[ Non, ce n'est pas un troll contre Ruby, j'aime bien ce langage. ]

>>Par contre, suprenant de voir Postfix inclut à la place de Sendmail !

Ce qui est surprenant, c'est que ça aurait deja du etre fait depuis longtemps..

>>Erlang est peut-être un vieux langage mais il évolue toujours actuellement (la R12 est sortie il y a une semaine).<<

Sais-tu ce qu'apporte quoi la R12?

Il y a eu une version avant qui était "majeur": elle apportait le support du SMP a Erlang de manière transparente: avant il fallait le programmer pour utiliser plusieurs CPU, maintenant les processus peuvent être sur des CPUs different de maniere transparente (je crois).

Erlang est un vieux langage.. C'est pour ça que sa syntaxe est très "différente".

L'avantage de Erlang c'est sa 'scalabilité' (aucune idée comment traduire ça correctement en Français): avec Erlang on peut exploiter des muti-processeurs "efficacement" dans le sens ou N processeur peut impliquer N fois plus rapide en Erlang (ce qui est *très* interressant vu l'évolution actuelle des CPUs) mais attention:
- sur un mono-processeur Erlang est beaucoup plus lent que le C donc même si c'est une application "Erlang-friendly" il faudra avoir 2-3 CPU pour atteindre les mêmes perf que le C sur un seul CPU!
- toutes les applications ne fonctionnent pas bien en multi-processeurs: certains ont leurs performances qui restent faible même quand on ajoute des processeurs..

Tu serais plus crédible si tu justifiais tes assertions..

Les seules méthodes que je connais pour contourner un captcha sont:
- un OCR, mais ça ne doit pas marcher terrible.
- mettre en place un site web de sexe et transférer les captchas pour que des utilisateurs les resolvent a la place du spammeur: compliqué!
- "casser" le site web en contournant la sécurité: encore faut-il que ce soit possible: c'est fini le temps des mots de passe codé en dur dans les pages web..

Bref rien de fiable, c'est quoi la méthode magique pour contourner les captchas?

Les DRM sont fondamentalement fragile, mais a priori ce n'est pas le cas des captchas..

>Linux à peu près aussi facile à installer qu'un Windows

Ca dépend beaucoup du matériel.. De toute manière la facilitié d'installation compte surtout pour les particuliers et t'en connais beaucoup des particuliers qui veulent changer leur OS?


>Objectivement, il n'y a aucune raison pour que nous soyons encore dans cette situation,

Hein? La vente liée, le monopole de Microsoft sur les formats de fichier Office, Active Directory, les jeux, etc ça fait plein de raisons qui expliquent que les utilisateurs restent avec Microsoft.


>je ne vois pas fondamentalement ce qui pourrait nous en tirer

Des applications 'clef' nettement supérieure a celle de MS (comme Office) *et* la fin de la vente liée pourrait peut-être permettre de sortir du cercle vicieux..

<<Au moins en RISC, les instructions font 32 ou 64 bits, et puis c'est tout. Idem sur les VLIW. Bref, CISC reste un gros boulet qu'on se traîne.>>

Les MIPS et ARM ont tous les deux une variante de leur jeux d'instruction sur 16bit, ce qui leur permet d'avoir des densité de code équivalente a celle des x86.

Je ne connais pas de RISC du commerce avec des instructions sur 64bit, ça me parait énorme.

Pour la fin: le gain de jusqu'à 20% de performances quand on est passé de 8 à 16 registre pour lors de la transition x86 au x86-64 a bien montré que le x86 c'est de la m.., mais on n'est pas près de l'abandonner..
Et comme Intel a prévu de s'attaquer au marché de l'embarqué, les x86 pourraient bien prends des parts de marché aux ARM/MIPS sur ce terrain.

AMD a embauché un deuxième programmeur pour faire les specs, donc ça ira 100% plus vite..

Est-ce que c'est possible maintenant de retirer un coeur d'un cluster 'à chaud' sans perturber le cluster?

Je crois me souvenir qu'il s'agissait d'une limitation de la version 1.0 ..

BLOB executé ou?
Sur le chip du périphérique ou du CPU?

Ca on verra bien ce que le tribunal dira la dessus: je ne me risquerai pas a faire un pronostique: cf l'affaire Mobilix ou ils ont perdu en appel (ce qui de mon point de vue est une honte).

>Ouaip, j'ai un peu confondu. GPL v3 résoud le problème de la tivolisation/FreeBoxisation etc.

Tu confonds toujours.. La tivolisation et la FreeBoxisation sont deux moyens différents pour contourner la GPL:
- dans le premier cas, il s'agit d'utiliser la crypto pour t'empêcher de remplacer un logiciel sur un équipement que tu as acheté.
- dans le deuxième cas, c'est prétendre que le matériel est loué et non acheté donc que c'est une distribution interne à l'entreprise ce qui ne te donne pas le droit d'accéder aux sources.

La GPLv3 est bien contre la tivolisation, mais autant que je sache n'a rien de modifié concernant la FreeBoxisation.

L'AGPL par contre fonctionnerait bien contre la FreeBoxisation.

C'est pas l'histoire du link statique ou dynamique?