On fait souvent l'implication "POO => héritage", c'est faux. Je te conseille le chapitre d'introduction de Design Patterns à ce sujet. Et les suivants aussi :-).
> Au niveau des performances, un appel de méthode "virtual" (qui prend donc potentiellement en compte l'héritage) prend 0,75 fois le temps d'un appel C normal.
Tu veux dire qu'un appel à une méthode virtuelle prend moins de temps qu'un appel de fonction C ? :-)
Et sinon, ça n'est pas seulement un pb de perfs mais de taille mémoire. Une classe avec des méthodes virtuelles contient un pointeur vers une table de ces methodes virtuelles, ce qui casse la compatibilité avec C.
En C++, tu peux prendre une struct C, la dériver, y ajouter toutes les méthodes non virtuelles que tu veux, et passer cette classe à une fonction C qui prend normalement la struct comme argument et ça marchera. Si tu ajoutes une méthode virtuelle, ça ne marche plus.
> Ce que j'aimerai, c'est du concret : pas du commercial (du genre, avec Java on fait des softs commerciaux de plusieurs millions de lignes (deja entendu...)).
Essaie de maintenir une appli de plusieurs millions de lignes en Perl et ça va très vite devenir très concret pour toi :-).
(Enfin, à ma connaissance il n'existe pas d'applis d'une telle taille en Perl, et je ne suis pas sur qu'il en existe en Java non plus mais ça me semble déjà plus du domaine du possible. Disons 200 KLOC, ça existe surement en Java, et en Perl j'ose à peine y penser).
Je sais bien qu'il y a quand même quelques ressources sur ObjC, j'en ai fait il y a longtemps.
C'est très sympa comme langage, mais c'est mort. Compare avec ce que tu trouves pour Java, C++, C#, etc... Peut-être que MacOSX va le ressusciter, mais j'ai un gros doute.
> 1- J'écris un programme Java sur Linux, puis je le fais tourner sous Windows ou Solaris
> 2- J'écris le même programme Java sous Linux, puis j'essaie de la faire tourner sous Windows ou Solaris.
Je ne suis pas sur de bien comprendre ta question :-).
Si par hasard tu voulais dire "C++" ou "C" au lieu de Java sur l'item 2, ben oui, faire des GUI portables en C ou en C++ c'est la merde, faut une lib en plus, c'est exactement ce qu'on dit plus bas : pour faire un bon langage il faut une bonne grosse lib :-).
Tu montres juste que Java engloble plus de choses que C ou C++, rien a redire. Mais ça n'est pas de ça qu'il s'agit.
Recognizing that "one size doesn't fit all," Sun has regrouped its innovative JavaTM technologies into three editions: Micro (J2METM technology), Standard (J2SETM technology), and Enterprise (J2EETM technology). Each edition is a developer treasure chest of tools and supplies that can be used with a particular product:
Java virtual machines* that fit inside the range of consumer devices
a library of APIs that are specialized for each type of device
tools for deployment and device configuration
a profile, that is, a specification of the minimum set of APIs useful for a particular kind of consumer device (set-top, screenphone, wireless, car, and digital assistant) and a specification of the Java virtual machine functions required to support those APIs
Un autre "standard" qui fait la même chose est SVG, il est prévu une version "mini" pour les plateformes plus limitées graphiquement, et même "micro" pour les trucs vraiment petits genre téléphones portables.
Bien sur, Objective C tourne sur Ipaq et AS400 par exemple :-).
> et n'est pas mort (voir Cocoa pour MacOSX ou encore le projet GNUstep a www.gnustep.org
2 projets ? Mais c'est énorme! Et sur comp.lang.objective-c (le seul newsgroup sur le sujet) je trouve 23 posts en une semaine. C'est fou cette activité débordante.
Ah, mais surtout le mieux c'est sur Amazon : 2 bouquins sur Objective C :
J'ai passé l'age des provocations à 2Frs, merci. Mon post n'était pas un troll.
> Pas du tout, en tant qu'étudiant en informatique, j'ai encore pas mal de choses a apprendre et/ou a approfondir.
C'est déjà bien de le réaliser. Maintenant, pourquoi rejettes-tu d'emblée un langage comme C# si ce n'est parce qu'il vient de Microsoft, et que tu n'aimes pas Microsoft ?
Crois-tu vraiment qu'il soit dans leur interêt de faire un langage pourri ?
> Mais pour une question de gout et de principes (surtout),
AT&T a été un monopole au moins aussi dur que MS, sauf qu'eux le gouvernement US est parvenu à les briser. Mais encore maintenant ils sont loins d'être blancs comme neige. Pourtant tes principes ne t'empèchent pas d'apprendre et d'aimer C ou C++, non ?
Reste le gout, mais bon quand j'étais étudiant j'avais les mêmes réactions, et puis j'ai évolué :-).
> Ce qui signifie donc des machines embarquées ou les interfaces graphiques n'ont aucun sens.
L'embarqué était (est toujours, même), l'un des objectifs de Java, et actuellement son domaine de prédilection est les serveurs, où il n'y a pas de GUI non plus.
T'es pas obligé d'emporter toute la lib dans le programme...
> C'est pourquoi, mettre dans une bibliothèque standard des trucs comme swing, une api réseau ou les threads n'est pas une bonne chose
Si, et c'est pourquoi on cherche à l'ajouter à C++ maintenant. Voir une interview de Stroustrup sur le sujet :
"Sun Microsystems Inc.'s long-standing plans to submit its Java language for standardization via the International Standards Organization are dead, according to Alan Baratz, president of Sun's Java Software division."
Ça date de 1999. Dans un numéro de C++ Report (datant de 99 ou 2000, je ne sais plus), il y avait une triple interview de Ritchie, Stroustrup, et Gosling. A la question "considerez-vous que standardiser un langage soit important", Ritchie et Stroustrup répondaient "oui, c'est crucial", et Gosling : "ben on a essayé mais c'était un tel bordel politique qu'on a laissé tomber".
> le C est déjà ANSI (American National Standardization Institute) et est en cours de standardisation ISO
"The current C programming language standard ISO/IEC 9899 was adopted by ISO in 1999."
(il s'agit de la dernière version, la première date de 87 si ma mémoire est bonne).
> le C++... ben je ne me souviens pas qu'il fasse l'objet de la moindre standardisation...
Le standard C++ ISO a été discuté pendant plusieurs années, et voté en novembre 97. Et la boite pour laquelle je travaille est membre du comité.
Joli score :-).
Il y a quelques mois sur un autre sujet dans linuxfr, je me souviens d'un âne qui avait aligné exactement les mêmes imbécilités : C pas encore ISO, et C++ pas standardisé. On avait été 2 à lui répondre... C'est quand même pas toi, dis ?
> Pourquoi comparer de Java et du C++ ?
Je citais C++ et C uniquement pour le fait qu'il y a un standard pour ces deux langages, il ne s'agit pas de comparer
> Les applis C++ peuvent t'elles se lancer dans le navigateur du lambda ?
En général non, et on s'en fout, c'est pas fait pour. Et ça n'a rien à voir avec le sujet non plus :-).
> Par contre, je ne connais pas C# et je n'ai vraiment pas envie de connaitre... Si C# est pensé comme MS a pensé les MFC par exemple, quelle horreur ça doit etre.
Et puis c'est tellement plus confortable de ne pas remettre en question ses connaissances, hein ?
> Je ne sais d'ailleurs plus le prix absolument abérant [...]
MS n'est pas idiot : leurs outils de dev ne coutent jamais très cher, ça permet d'avoir plus de développeurs.
> Petite question en passant, est-ce que le C# possede un API aussi énorme que celle de java ?
Bien évidemment. L'une des grandes leçons de C++, c'est qu'un langage doit avoir d'entrée une lib standard bien foutue, sinon c'est le bordel parce que chacun fait la sienne.
> Bonne merde pour suivre les futurs changement "non documentés" de Microsoft ...
Microsoft a proposé un standard public pour C#, donc C# sera standardisé comme C ou C++ le sont actuellement (et comme Java ne le sera semble-t-il jamais :-).
Il te faut vraiment des arguments pour t'expliquer qu'il est normal de payer pour un service qui n'a aucune autre source de financement par ailleurs (ie pas de pubs) ?
Personnellement je trouve la réponse de McGovern assez satisfaisante, et celle de DiBona pas particulièrement agressive.
Peut-être est-il un peu enervé par les donneurs de leçons qui n'ont semble-t-il pas la moindre idée de ce que représente la gestion d'un site de la taille de sourceforge et qui les accusent de "conspirer" contre la communauté.
SForge a plein de défaut. La gestion des mailing lists (admin et archives) est complètement séparée du reste (heureusement qu'ils y travaillent, il serait temps), beaucoup de features sont trop compliquées à utiliser, et au lieu de regler ces problèmes ils se sont amuser à rajouter des "thèmes", ou autre features à la con comme le rating des développeurs. Et toutes les personnes qui ont essayé d'installer sforge chez eux disent que c'est un bordel monstre.
Mais au moins ça marche pas trop mal, et quand je demande au support de renommer un directory CVS ils le font dans les 24h.
Au fait, l'assignation de copyright que VA a demandé de signer à Loic est parfaitement standard pour autant que je sache. La FSF te fait signer la même si tu veux leur assigner ton copyright aussi (en tout cas j'ai signé un contrat avec exactement la même clause pour du code que j'avais contribué à GNUStep en 97).
A part ça, oui, il faut des alternatives, bien sur. Mais si on pouvait arrêter les théories de conspiration à 2 balles...
Ah, parce que tu fais un site web comme slashdot avec juste du "temps" toi ? Sans hardware, sans software, sans bande passante ? T'es trop fort toi :-).
Quoiqu'avec cette méthode, c'est sur que tu ne dois pas y passer beaucoup de temps non plus, donc tu t'y retrouves :-).
> Chouette! j'ai toujours rêvé de payer pour ne pas avoir de pubs !
Tu sais, les sites web qui vivent d'amour et d'eau fraiche, y en a pas des masses.
Le Net n'a jamais été gratuit, simplement ça n'étaient pas les usagers de base qui payaient. Maintenant on va leur demander de participer un peu et c'est plutôt mieux comme ça.
Mon projet est hebergé sous Source Forge, je n'aurai aucun problème à payer une facture (raisonnable) si ils me le demandaient. Je paye aussi pour mon site web, qui du coup n'a pas de pub, et c'est parfaitement normal.
Pour faire de l'OpenGL, je ne crois pas (du moins pas encore). Pour parser du XML, c'est en train d'arriver. Pour la machine à café, je m'en fous j'aime pas le café.
> C'est là dessus que je suis le plus interressé, si quelqu'un pouvait m'éclairer :-)
Le temps que tu tapes ta question, tu aurais déjà eu la réponse en visitant les liens mentionnés dans la news :-).
Ça dépend un peu de ce que tu appelles "gros programmes". Par rapport à un script de base (disons < 1kloc), "gros" c'est 10 ou 100 klocs. Je pense que Ruby ou Python peuvent arriver à ça sans trop de problèmes, mais pas Perl (enfin si, Perl peut surement et je suis sur qu'il y aura plein de zealots pour me citer des exemples, mais la maintenance sera toujours un cauchemard).
Par contre si tu parles de "gros" dans l'absolu (e.g. au dessus du million de lignes), là je doute qu'aucun langage de script n'y arrive...
> Si tu veux faire un programme qui sera utilisé régulièrement, alors à toi de l'écrire proprement.
Mais justement, là Ruby est clairement gagnant parce que l'effort à faire pour l'écrire proprement est bien moindre en Ruby qu'en Perl.
> Par contre, s'il s'agit d'écrire rapidement un script à l'usage éphemère, alors pourquoi avoir à suivre des règles strictes ?
Et là aussi Ruby gagne, parce que même pour les petits scripts jetables, il est plus efficace que Perl.
> Pour une fois, ce n'est pas toi qui doit t'adapter à la syntaxe du langage, mais le langage qui s'adapte à ta facon d'écrire...
Non, a quelques exceptions près, la syntaxe de Perl est une contrainte, pas une liberté. Et c'est justement ces quelques exceptions que Ruby a repris. La syntaxe de Ruby est aussi assez souple, mais "juste ce qu'il faut". Quiconque vient de C++, Perl ou Java peut l'assimiler en quelques heures.
OK, je reformule : dans tous les langages de script que je connais, tu n'est pas obligé de déclarer tes variables, contrairement à un langage comme C++ ou Java. Tu peux le faire, mais ça n'est pas une obligation.
Oui mais Perl t'encourage à coder comme un porc, (c'est la voie la plus facile, pour re-citer Star Wars :-), et surtout la syntaxe est intrinsèquement pénible à lire.
Il est plus facile de coder clean en Python ou Ruby qu'en Perl. C'est le gros avantage, et c'est essentiellement ça qui fait que le langage passe mieux à l'echelle.
[^] # Re: Erreurs de C++
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 2.
Il y a un vrai interêt, même si les interfaces suffisent 90% du temps. Un papier là dessus écrit par un copain :
http://www.beust.com/cedric/java-delegation.html(...)
On fait souvent l'implication "POO => héritage", c'est faux. Je te conseille le chapitre d'introduction de Design Patterns à ce sujet. Et les suivants aussi :-).
http://hillside.net/patterns/DPBook/DPBook.html(...)
[^] # Re: Erreurs de C++
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 1.
Tu veux dire qu'un appel à une méthode virtuelle prend moins de temps qu'un appel de fonction C ? :-)
Et sinon, ça n'est pas seulement un pb de perfs mais de taille mémoire. Une classe avec des méthodes virtuelles contient un pointeur vers une table de ces methodes virtuelles, ce qui casse la compatibilité avec C.
En C++, tu peux prendre une struct C, la dériver, y ajouter toutes les méthodes non virtuelles que tu veux, et passer cette classe à une fonction C qui prend normalement la struct comme argument et ça marchera. Si tu ajoutes une méthode virtuelle, ça ne marche plus.
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 3.
Essaie de maintenir une appli de plusieurs millions de lignes en Perl et ça va très vite devenir très concret pour toi :-).
(Enfin, à ma connaissance il n'existe pas d'applis d'une telle taille en Perl, et je ne suis pas sur qu'il en existe en Java non plus mais ça me semble déjà plus du domaine du possible. Disons 200 KLOC, ça existe surement en Java, et en Perl j'ose à peine y penser).
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 2.
Par contre, $1000 dans le budget moyen d'un projet en entreprise, c'est rien.
[^] # Re: Et l'objective C ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 2.
C'est très sympa comme langage, mais c'est mort. Compare avec ce que tu trouves pour Java, C++, C#, etc... Peut-être que MacOSX va le ressusciter, mais j'ai un gros doute.
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 2.
> 2- J'écris le même programme Java sous Linux, puis j'essaie de la faire tourner sous Windows ou Solaris.
Je ne suis pas sur de bien comprendre ta question :-).
Si par hasard tu voulais dire "C++" ou "C" au lieu de Java sur l'item 2, ben oui, faire des GUI portables en C ou en C++ c'est la merde, faut une lib en plus, c'est exactement ce qu'on dit plus bas : pour faire un bon langage il faut une bonne grosse lib :-).
Tu montres juste que Java engloble plus de choses que C ou C++, rien a redire. Mais ça n'est pas de ça qu'il s'agit.
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 2.
Il existe des définition un brin plus subtiles de "standard".
> Voilà mon avis, même si Stroustrup et Guillaume ne le partage pas.
Sun non plus ne le partage pas :
http://java.sun.com/j2me/(...)
Recognizing that "one size doesn't fit all," Sun has regrouped its innovative JavaTM technologies into three editions: Micro (J2METM technology), Standard (J2SETM technology), and Enterprise (J2EETM technology). Each edition is a developer treasure chest of tools and supplies that can be used with a particular product:
Java virtual machines* that fit inside the range of consumer devices
a library of APIs that are specialized for each type of device
tools for deployment and device configuration
a profile, that is, a specification of the minimum set of APIs useful for a particular kind of consumer device (set-top, screenphone, wireless, car, and digital assistant) and a specification of the Java virtual machine functions required to support those APIs
Un autre "standard" qui fait la même chose est SVG, il est prévu une version "mini" pour les plateformes plus limitées graphiquement, et même "micro" pour les trucs vraiment petits genre téléphones portables.
[^] # Re: Et l'objective C ?
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 0.
Bien sur, Objective C tourne sur Ipaq et AS400 par exemple :-).
> et n'est pas mort (voir Cocoa pour MacOSX ou encore le projet GNUstep a www.gnustep.org
2 projets ? Mais c'est énorme! Et sur comp.lang.objective-c (le seul newsgroup sur le sujet) je trouve 23 posts en une semaine. C'est fou cette activité débordante.
Ah, mais surtout le mieux c'est sur Amazon : 2 bouquins sur Objective C :
http://www.amazon.com/exec/obidos/ASIN/0201508281/qid=1006177949/sr(...)
http://www.amazon.com/exec/obidos/ASIN/0201632519/qid=1006177949/sr(...)
dont aucun n'est encore imprimé. C'est clair, ce langage pête la santé :-).
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche C# et Java, une étude comparée. Évalué à -2.
J'ai passé l'age des provocations à 2Frs, merci. Mon post n'était pas un troll.
> Pas du tout, en tant qu'étudiant en informatique, j'ai encore pas mal de choses a apprendre et/ou a approfondir.
C'est déjà bien de le réaliser. Maintenant, pourquoi rejettes-tu d'emblée un langage comme C# si ce n'est parce qu'il vient de Microsoft, et que tu n'aimes pas Microsoft ?
Crois-tu vraiment qu'il soit dans leur interêt de faire un langage pourri ?
> Mais pour une question de gout et de principes (surtout),
AT&T a été un monopole au moins aussi dur que MS, sauf qu'eux le gouvernement US est parvenu à les briser. Mais encore maintenant ils sont loins d'être blancs comme neige. Pourtant tes principes ne t'empèchent pas d'apprendre et d'aimer C ou C++, non ?
Reste le gout, mais bon quand j'étais étudiant j'avais les mêmes réactions, et puis j'ai évolué :-).
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 5.
L'embarqué était (est toujours, même), l'un des objectifs de Java, et actuellement son domaine de prédilection est les serveurs, où il n'y a pas de GUI non plus.
T'es pas obligé d'emporter toute la lib dans le programme...
> C'est pourquoi, mettre dans une bibliothèque standard des trucs comme swing, une api réseau ou les threads n'est pas une bonne chose
Si, et c'est pourquoi on cherche à l'ajouter à C++ maintenant. Voir une interview de Stroustrup sur le sujet :
http://www.linuxworld.com/linuxworld/lw-2001-02/lw-02-stroustrup.ht(...)
> Mais faire une généralité en disant que plus la bibliothèque standard est grosse et complète, mieux c'est, c'est faux.
Cite moi un exemple montrant le contraire. Pour autant que je puisse dire, c'est vrai.
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 8.
Ah, vraiment :
http://www.zdnet.com/zdnn/stories/news/0,4586,1014537,00.html(...)
"Sun Microsystems Inc.'s long-standing plans to submit its Java language for standardization via the International Standards Organization are dead, according to Alan Baratz, president of Sun's Java Software division."
Ça date de 1999. Dans un numéro de C++ Report (datant de 99 ou 2000, je ne sais plus), il y avait une triple interview de Ritchie, Stroustrup, et Gosling. A la question "considerez-vous que standardiser un langage soit important", Ritchie et Stroustrup répondaient "oui, c'est crucial", et Gosling : "ben on a essayé mais c'était un tel bordel politique qu'on a laissé tomber".
> le C est déjà ANSI (American National Standardization Institute) et est en cours de standardisation ISO
http://anubis.dkuug.dk/JTC1/SC22/WG14/(...)
"The current C programming language standard ISO/IEC 9899 was adopted by ISO in 1999."
(il s'agit de la dernière version, la première date de 87 si ma mémoire est bonne).
> le C++... ben je ne me souviens pas qu'il fasse l'objet de la moindre standardisation...
Ben tu dois vivre sous un rocher :
http://std.dkuug.dk/jtc1/sc22/wg21/(...)
http://www.research.att.com/~bs/iso_release.html(...)
Le standard C++ ISO a été discuté pendant plusieurs années, et voté en novembre 97. Et la boite pour laquelle je travaille est membre du comité.
Joli score :-).
Il y a quelques mois sur un autre sujet dans linuxfr, je me souviens d'un âne qui avait aligné exactement les mêmes imbécilités : C pas encore ISO, et C++ pas standardisé. On avait été 2 à lui répondre... C'est quand même pas toi, dis ?
> Pourquoi comparer de Java et du C++ ?
Je citais C++ et C uniquement pour le fait qu'il y a un standard pour ces deux langages, il ne s'agit pas de comparer
> Les applis C++ peuvent t'elles se lancer dans le navigateur du lambda ?
En général non, et on s'en fout, c'est pas fait pour. Et ça n'a rien à voir avec le sujet non plus :-).
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche C# et Java, une étude comparée. Évalué à -1.
Depuis qu'ils les font :-)
> Tu crois que parce qu'il l'a proposé lui-même il le respectera ?
Oui, c'est dans leur interêt. Si ils veulent que ce langage marche, il faut éviter qu'il soit "balkanisé".
http://www.ecma.ch/ecma1/MEMENTO/TC39.HTM(...)
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 2.
Et puis c'est tellement plus confortable de ne pas remettre en question ses connaissances, hein ?
> Je ne sais d'ailleurs plus le prix absolument abérant [...]
MS n'est pas idiot : leurs outils de dev ne coutent jamais très cher, ça permet d'avoir plus de développeurs.
> Petite question en passant, est-ce que le C# possede un API aussi énorme que celle de java ?
Bien évidemment. L'une des grandes leçons de C++, c'est qu'un langage doit avoir d'entrée une lib standard bien foutue, sinon c'est le bordel parce que chacun fait la sienne.
[^] # Re: Opinion
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche C# et Java, une étude comparée. Évalué à 0.
Microsoft a proposé un standard public pour C#, donc C# sera standardisé comme C ou C++ le sont actuellement (et comme Java ne le sera semble-t-il jamais :-).
[^] # Re: La dérive de VA Linux
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche La dérive de SourceForge. Évalué à 0.
Tu plaisantes là ?
[^] # Re: La dérive de VA Linux
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche La dérive de SourceForge. Évalué à -1.
[^] # Re: Des réponses d'OSDN et de SourceForge ...
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche La dérive de SourceForge. Évalué à 6.
Peut-être est-il un peu enervé par les donneurs de leçons qui n'ont semble-t-il pas la moindre idée de ce que représente la gestion d'un site de la taille de sourceforge et qui les accusent de "conspirer" contre la communauté.
SForge a plein de défaut. La gestion des mailing lists (admin et archives) est complètement séparée du reste (heureusement qu'ils y travaillent, il serait temps), beaucoup de features sont trop compliquées à utiliser, et au lieu de regler ces problèmes ils se sont amuser à rajouter des "thèmes", ou autre features à la con comme le rating des développeurs. Et toutes les personnes qui ont essayé d'installer sforge chez eux disent que c'est un bordel monstre.
Mais au moins ça marche pas trop mal, et quand je demande au support de renommer un directory CVS ils le font dans les 24h.
Au fait, l'assignation de copyright que VA a demandé de signer à Loic est parfaitement standard pour autant que je sache. La FSF te fait signer la même si tu veux leur assigner ton copyright aussi (en tout cas j'ai signé un contrat avec exactement la même clause pour du code que j'avais contribué à GNUStep en 97).
A part ça, oui, il faut des alternatives, bien sur. Mais si on pouvait arrêter les théories de conspiration à 2 balles...
[^] # Re: La dérive de VA Linux
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche La dérive de SourceForge. Évalué à 1.
Quoiqu'avec cette méthode, c'est sur que tu ne dois pas y passer beaucoup de temps non plus, donc tu t'y retrouves :-).
[^] # Re: La dérive de VA Linux
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche La dérive de SourceForge. Évalué à 3.
Tu sais, les sites web qui vivent d'amour et d'eau fraiche, y en a pas des masses.
Le Net n'a jamais été gratuit, simplement ça n'étaient pas les usagers de base qui payaient. Maintenant on va leur demander de participer un peu et c'est plutôt mieux comme ça.
Mon projet est hebergé sous Source Forge, je n'aurai aucun problème à payer une facture (raisonnable) si ils me le demandaient. Je paye aussi pour mon site web, qui du coup n'a pas de pub, et c'est parfaitement normal.
[^] # Re: c'est mieux quand y'a moins à faire
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Article sur Ruby. Évalué à 3.
Pour la partie qui t'interesse (networking) :
http://www.rubycentral.com/book/lib_network.html(...)
Pour faire de l'OpenGL, je ne crois pas (du moins pas encore). Pour parser du XML, c'est en train d'arriver. Pour la machine à café, je m'en fous j'aime pas le café.
> C'est là dessus que je suis le plus interressé, si quelqu'un pouvait m'éclairer :-)
Le temps que tu tapes ta question, tu aurais déjà eu la réponse en visitant les liens mentionnés dans la news :-).
[^] # Re: Juste pour dire quelque chose contre Ruby :-)
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Article sur Ruby. Évalué à 1.
Par contre si tu parles de "gros" dans l'absolu (e.g. au dessus du million de lignes), là je doute qu'aucun langage de script n'y arrive...
[^] # Re: Juste pour dire quelque chose contre Ruby :-)
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Article sur Ruby. Évalué à 1.
Mais justement, là Ruby est clairement gagnant parce que l'effort à faire pour l'écrire proprement est bien moindre en Ruby qu'en Perl.
> Par contre, s'il s'agit d'écrire rapidement un script à l'usage éphemère, alors pourquoi avoir à suivre des règles strictes ?
Et là aussi Ruby gagne, parce que même pour les petits scripts jetables, il est plus efficace que Perl.
> Pour une fois, ce n'est pas toi qui doit t'adapter à la syntaxe du langage, mais le langage qui s'adapte à ta facon d'écrire...
Non, a quelques exceptions près, la syntaxe de Perl est une contrainte, pas une liberté. Et c'est justement ces quelques exceptions que Ruby a repris. La syntaxe de Ruby est aussi assez souple, mais "juste ce qu'il faut". Quiconque vient de C++, Perl ou Java peut l'assimiler en quelques heures.
Essaie-le, tu verra bien.
[^] # Re: Juste pour dire quelque chose contre Ruby :-)
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Article sur Ruby. Évalué à 0.
[^] # Re: Juste pour dire quelque chose contre Ruby :-)
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Article sur Ruby. Évalué à 3.
Il est plus facile de coder clean en Python ou Ruby qu'en Perl. C'est le gros avantage, et c'est essentiellement ça qui fait que le langage passe mieux à l'echelle.
[^] # Re: Ruby Rulez !
Posté par Guillaume Laurent (site web personnel) . En réponse à la dépêche Article sur Ruby. Évalué à 6.
http://www.rubygarden.org/(...)