Guillaume Laurent a écrit 1148 commentaires

C'est dingue, toutes les personnes qui connaissent Ruby disent ça !!!

Non, c'est normal : Ruby est le meilleur langage de script actuellement. :-) Toutes les personnes à qui je l'ai montré le trouvent bien aussi.

Et pourtant c'est vraiment pas très répendu comme langage.

C'est en train de prendre de l'ampleur.

Il faudrait en parler plus sur tous les sites genre linuxfr.

Ou ré-écrire daCode en Ruby.

Je sais pas... le pb avec les étudiants c'est qu'ils ne savent rien, et même ça ils ne le savent pas. Donc quand tu le leur dis, ils ne te croient pas, et, justement, te prennent pour un vieux con.

Dans le cas de l'étudiant Linuxien, c'est pire, parce qu'il est le plus souvent shooté à l'idéalisme made in RMS, et il arrive non pas avec des nouvelles technos à la mode, mais avec des traditions et une idéologie. Y a qu'a voir les réactions sur la news récente à propos de Miguel et .Net, c'est un exemple parmi plein d'autres. Si tu leur dit "cet outil là marche mieux", il va immanquablement te répondre "oui mais sous Unix/Linux on fait comme ça depuis des années et ça marche".

Et autant faire bouger quelqu'un qui suit une mode est relativement facile, autant sortir quelqu'un de ses traditions est quasi impossible.

- Tu veux pas utiliser un IDE ?

- Nan, j'ai pas besoin, xterm+vi+make ça marche

- Et le temps que tu perds à chercher les fichiers dans l'arborescence, à faire des find | xargs grep pour trouver les definitions de fonctions ?

- M'en fous j'vais m'faire mes scripts et puis ctags roulaize.

J'en parle d'autant mieux que j'ai été comme ça (enfin, pas loin). Et j'utilise toujours pas d'IDE au bureau, mais c'est parce qu'il n'y en a pas qui tienne vraiment bien la route sous Linux :-).

Après c'est vrai, ils peuvent apporter des idées nouvelles, et les vieux cons aussi ont leurs habitudes bien ancrées dont il est bon de les faire bouger. Donc globablement, je dirais que les étudiants c'est bien, mais faut y aller avec des pincettes.

Enfin, on est d'accord là dessus je crois :-).

C'est le formatage d'argument avec cout qui est vraiment pas terrible..

C'est le moins que l'on puisse dire. D'un coté c'est pratique pour les trucs simples (genre string + entier + string) parce que tu n'as pas à te soucier du typage, tu enfiles juste les '<<'. Mais dès que tu veux parametrer un peu l'affichage (genre des entiers en hexa ou une certaine précision sur les floats), ça devient très très moche.

De toute maniére je préfére le code ruby

Ah, toi aussi ? C'est définitivement le meilleur langage de script que je connaisse :-).

Oui mais là justement on parlait de porter du code C (j'aurais du préciser).

Alors là j'ai fait un new, bon dans ce cas là il faut faire un free

Il faut faire un delete, malheureux ! :-)

C'est vrai, mais si c'est pour faire du C en C++, autant faire du C

Oui bien sur, mais il y a aussi des fois ou tu as vraiment besoin d'une simple fonction stand-alone, etc... C'est bien de pouvoir "débrayer" certaines choses.

L'inverse est encore plus vrai, déjà vu du code OO en C [...]

A qui le dis-tu (j'ai bossé 3 ans sur Gtk-- :-). Plus jamais ça.

Gtk, Qt, etc, pour le GUI.

Qt c'est du C++ (oui, y a les bindings C, mais pour utiliser ça directement faut vraiment être maso). Plus précisément, c'est une toolkit C++, donc un produit "en plus", et c'est eux qui se sont frappé pour toi tous les problèmes de portabilité.

D'un autre coté, si tu prend tes yeux et que tu les posent sur mon post, tu verra ecrit "aussi simple a porter". A porter je lis moi. pas a ecrire.

Ah. Parce que tu arrives à porter du code sans écrire du code supplémentaire, ni modifier le code existant. T'es 'achement doué toi :-).

<i>Avec 64Mo, ce dont je dispose au boulot<i>

Ouhlà, je comprends ta douleur. Pour une machine de développement, c'est beaucoup trop petit.

actuellement, je n'ai vu aucune application raisonablement stable...

Konq est entièrement basé sur des composants et ne crashe pas une fois par jour chez moi (je dirais 1 fois par semaine max, très tolérable par rapport à Netscape4 :-).

les connaissance requises pour manipuler ce genre de concept sont nettement au delà de celles qu'il faut pour faire les même choses sans cette approche

Pas d'accord, elles sont moindres je trouve. Si tu veux connaitre toute la mécanique à fond oui, mais rien ne t'y oblige. Je ne crois pas qu'un programmeur puisse actuellement appréhender une appli complète. Est-ce que tu sais exactement ce qui se passe quand tu fais un malloc() ? Quand tu appelles une fonction (l'empilement/dépilement des arguments, etc...) ? Quand tu ouvres un fichier sur le disque ? Moi pas. Il est normal de "déleguer" certaines choses.

et dans les petits projets l'approche objet elle même n'est pas forcément rentable

Si, c'est quasiment toujours rentable. Faire de l'objet ne signifie pas deriver des classes dans tous les sens, justement il y a un thread la dessus dans la news sur C# et Gosling :

http://linuxfr.org/2002/02/05/6980,0,0,0,0.php3(...)

Ce qui me gène dans vos posts (P. Fremy et toi), c'est que j'ai l'impression que vous présentez l'approche composant/réutilisation un peu comme on a présenté l'objet, les bases de données objet ou le micro noyau: c'est LA manière de faire

Non, je ne dis pas (ni Philippe je pense) que les composants sont LA façon de faire. C'est juste un outil de plus, qui, lorsqu'il est utilisé à bon escient, marche très bien et est très puissant. C'est hélas vrai qu'il y a eu pour toutes les nouvelles techno des gens qui ont confondu "outil qui aide" et "outil qui doit être utilisé".

Je voulais dire par là que tu vas plus facilement te "lacher" en créant pleins d'objets dans tous les sens sans te demander s'il n'y a pas de manières plus optimales pour arriver au même résultat.

C'est vrai, tant que tu ne te soucies pas des perfs :-). Mais ça n'est pas la seule raison. Si tu fais du C++, tu dois régulièrement de faire chier avec des problèmes d'appartenance (quel objet doit effacer tel autre, etc...), qui exigent un maximum de rigueur pour être résolus. Contrairement à ce qu'on dit souvent, il n'y a pas de manière systématique de les gérer en C++, et un GC aide énormément pour ça. Je préfère dire que ça te permet de gagner du temps sur des problèmes souvent très complexes, plutôt que "ça te permet de te lacher".

C'est ce que je voulais dire, C++ t'apporte des mécanismes qui force ta conception

C'est juste le mot "force" sur lequel je ne suis pas d'accord. C++ ne force rien, il t'offre une possibilité. Java te force à faire de l'OO, pas C++.

Ils manquaient juste un peu d'expérience pour savoir quand est ce qu'il fallait appliquer le "manuel du parfait petit programmeur objet qui fait plein d'héritage car les héritages c'est jolis, les héritages c'est bon, mangez en" et quand est ce qu'il fallait dire "STOP". :-)

Alors nous sommes tout à fait d'accord.

Mais je suis le premier à écouter un étudiant tout frais moulu quand il propose des idées, car il n'a pas d'idée préconçue

On doit pas connaitre les mêmes étudiants :-). Enfin, je suis un peu contaminé par ce que je lis sur DLFP :-).

En dehors des surcharges pour des applications numériques, je ne trouve pas que l'opérateur overloading soit trés propre

Et pour une classe string ou array par ex ? Avoir le '[]' ça t'aide pas ? Ou les "+" et "+=" pour concatener des strings ?


cout toto << " " << titi << " " << tata;
est moins lisible | agréable à relire
à mon sens que
printf("%s %f.02 %c",toto,titi,tata); ou System.our.println(toto+" "+titi.toString()+" "+tata.toString());


Oui mais note que le printf() est moin safe, parce qu'il n'y a pas de vérification sur le nombre ou le types des arguments passés après le string de controle (gcc -Wall aide un peu, mais en général non). Et le 2eme exemple que tu donnes utilise l'operateur overloading aussi, dans un certain sens :-).

Develloper ca en C aurait ete aussi simple a porter

Vas-y, fais-moi voir un programme en C avec une GUI, tournant sur Unix et Windows, et dont le code soit "aussi simple" que du Java.

Bien d'accord avec Guillaume.

Miracle. Mais descend plus bas, y a un autre thread ou on est pas d'accord. :-)

Et de plus, pour rappel, l'héritage multiple n'existe pas en Java, sauf pour les interfaces. Alors comment faire une application "ou les héritages étaient sur-multipliés" ?

Il parlait bien sur d'héritage successif, pas multiple. A qui dérive de B qui dérive de C qui dérive de... etc...

Pour info, dans Rosegarden (rosegarden.sf.net) on a bientot 60kloc, des templates, de l'héritage multiple, mais l'arbre d'héritage n'est pas très profond, 3 ou 4 niveaux maximum je pense, et 90% des classes ne sont pas dérivées, seules certaines classes de base le sont.

C'est beau de voir un professionnel qui donne une opinion posée, basée sur l'expérience et les faits.

Je présume que tu as lu les raisons que Gosling donne pour vouloir l'ajouter à Java, et qu'elles t'ont semblées complètement stupides.

Et comme tu dis que "tu" t'en passe sans regret, il est clair que ça doit être le cas pour absolument tous les autres programmeurs de la planète.

voir les bouquins qui causent de codage propre, ils jettent tous cette technique moyenageuse du C++

Lesquels ? Et, sachant que des bouquins fondamentaux de C++ (Stroustrup, Austern, Koenig) citent l'operator overloading comme une technique importante, permettant de clarifier le code, devons-nous conclure que ces auteurs sont, comme Gosling, des imbéciles ?

et qui en aucun cas ne permet de tenir des propos généralisants comme "le libre contre le propriétaire n'est pas une motivation première"

A tout hasard : je bosse pour le libre depuis 96. Je peux t'affirmer que c'est vrai pour moi et la majorité des développeurs avec qui j'ai pu travailler.

Globalement, les petits jeunes sont "extrémistes" (normal, c'est de leur âge et on es tous passés par là - y a qu'a voir ici), les plus agés sont un peu plus raisonnables.

Tout à fait d'accord :-).

(et je confirme aussi, je ne suis plus étudiant depuis longtemps :-)

Ben il faut bien reconnaitre que cette question-là est quand même un peu fondée. Java sur le client, pour le moment c'est pas extraordinaire. C'est encore pire du coté Linux où on a pratiquement pas d'implémentation décente (en gros, Java marche bien mieux sous Windows).

mais si tu fais un héritage de 5éme niveau sur des classes que tu n'as pas codé

Ah ok, je vois ce que tu veux dire. Oui, c'est un pb, mais tu ne peux pas vraiment comparer ça avec un simple malloc() C, c'est pas vraiment la même chose.

Java permet de coder de manière largement plus crade car c'est le "garbage collector" qui s'occupe de ce problème pour toi

C'est pas crade, bien au contraire c'est beaucoup plus pratique et élégant.

Pour moi C++ doit être vu comme du C avec l'avantage de faire un découpage plus propre de l'application, car tu es obligé d'être plus propre dans ta conception

Non, tu n'es pas "obligé", tu peux être plus propre. Être aussi propre en C réclame une discipline quasi-impossible à soutenir, parce que tu vas faire le boulot du compilateur. En C++, tu peux plus facilement être propre parce que le compilateur t'apporte les outils pour ça.

L'héritage a plusieurs niveaux et multiple du C++, ça existe, mais c'est la première source d'emmerde garantie.

Oui, mais l'héritage n'est pas une chose anodine, c'est un outil qu'il faut utiliser à bon escient.

Dans ce cas là, je ne trouve pas que l'objet simplifie la programmation, je dirais plutôt au contraire

Tu confonds la programmation objet et l'héritage. Ça n'a rien à voir. L'héritage est juste l'un des outils qui aident à faire de l'objet, il y en a pleins d'autres. Je te conseille de lire le chapitre d'introduction du Design Patterns.

Cela signifie que, comme d'habitude, on aura droit à de bon gros bug qui font planter le système...

Tu en as en Java aussi. Une JVM peut parfaitement planter, ton code peut jeter une exception et ne pas la traiter. Et tu n'es pas "obligé" d'utiliser "unsafe".

Citez moi un truc intéressant qu'un langage fait et qu'on peut pas faire en Java :-)

L'operator overloading. D'ailleurs Gosling avait fait une proposition pour l'ajouter à Java :

http://java.sun.com/people/jag/FP.html#overloading(...)

Enfin, il y a des "extensions" non-officielles de Java qui supportent ça je crois, mais bon, c'est quand même mieux quand c'est en standard dans le langage.

Ou pour citer des trucs un peu plus "gros" :

http://bea.com/products/index.shtml(...)

http://www.ilog.com/products/jviews/(...)

http://industry.java.sun.com/(...)

Bref, Conrad, sors un peu :-).

Je parie qu'on a la même chose avec QT sans les parties OLE-like de KDE.

Tu "paries", où tu "sais" ?

- en programmation: c'est décrit en détail dans mes autres posts.

Si tes posts pouvaient décrire en détails tes compétences réelles en programmation, ça donnerait un peu plus de poids à tes arguments.

Tout ce qu'on peut voir chez toi pour l'instant, c'est un gros préjugé : "les composants c'est pas bien". Ajouté au fait que tu ne sais clairement pas de quoi il s'agit (cf. ton premier post où tu ne fais pas la distinction avec des sockets).

sans avoir des mécanismes new du C++ qui ne font pas toujours ce que tu pense

Si un 'new' C++ ne fait pas ce que tu penses, c'est soit un bug dans ton code, soit que tu ne devrais pas coder en C++ (soit les deux :-).

Sur le papier, Java aussi ça a l'air parfait. Et puis en pratique, il y a les défauts qu'on connait.

Lesquels ?

Et puis, comme autre plateforme, il faut voir que .NET apporte autant d'inconvénients que d'avantages par rapport à Java, dont l'implémentation est moins douteuse, meme si le début a été laborieux.

Donc, en résumé : .Net ça peut être bien mais ça peut aussi pas l'être, et si ça l'est pas alors il vaut mieux ne pas l'utiliser. Et il vaudra mieux utiliser des solutions qui marchent, ou Java, même si c'est pleins de défauts que tout le monde connait.

Y a rien à redire, je suis d'accord :-).

C'est sûr qu'avec des arguments tels celui-ci, le débat va pas voler bien haut.

C'est pas un argument, mais une constatation. Entre le scoring systématiquement négatif des posts de pbg et les "arguments" qu'on lui oppose, ça me semble assez clair.

Ton post, à part cracher sur ceux qui n'ont pas la même vision des choses que toi

Quelle "vision" ? Je n'en ai aucune, j'ai juste eu une petite presentation sur .Net à ma boite il y a quelque temps, je ne sais pas exactement ce que ça peut faire. J'ai juste une impression globalement positive du truc, C# à l'air d'être un bon langage, pour le reste je ne sais pas. Ce sur quoi je crache, ce sont les réactions bornées de la plupart des gens ici. "Open Source, Closed Mind".

Sûrement pas. Certains chez nous utilisent Vim, d'autres notepad, certains emacs

Tu as bien lu le "à part l'éditeur" ?

Tu considère peut-etre que tu es très supérieur à nous pour avoir le même environnement que tes collègues ?

Non, avoir le même environnement que ses collègues est une obligation, au moins pour le build et la gestion des sources, c'est évident. Les scripts qui génèrent nos Makefiles et tous le système de build font quelques milliers de lignes et sont maintenus depuis des années. Je ne vais pas les refaire pour le plaisir, et si je veux que mon code soit compilé avec celui de tout le monde, il est normal que je m'intègre. Et ça a toujours été comme ça dans toutes les boites où j'ai travaillé.

Les défenseurs de .NET parlent généralités, les attaquants lui opposent des FAITS

Non, je n'ai vu passer aucun "fait", juste des poncifs. Je n'ai vu personne dire "je code sous .Net, voilà ce que je sais".

Quand tu lances un développement, tu ne peux pas savoir à l'avance toutes les taches qu'il sera bon d'automatiser. Ca se fait petit à petit en utilisant les outils que les autres ont déjà mis en place pour se simplifier la vie.

OK, là je suis d'accord.

Tu me trouves où j'ai dit ça ou tu arrêtes de me prendre pour un con.

Je ne parlais pas pour toi en particulier, mais de la majorité des réponses ici. Par contre je reconnais m'être trompé à ton sujet, je te fais donc mes excuses.

Toi, quand tu ne veux pas comprendre quelque chose, tu es champion

C'est rien à coté de ceux qui lui répondent.

je t'explique qu'avec les outils de développement[...]

Tu n'expliques rien du tout, tu affirmes sans savoir, en ressortant des clichés. Je serais très étonné que tu ais la moindre expérience de développement en entreprise, particulièrement quand tu sors des anneries comme celles-ci :

Grace à Microsoft, les décideurs anticipent rapidement sur la vitesse de développement de leur personnel: c'est la même vitesse dès les premiers jours, alors qu'avec les outils libres, chacun se met en place ses outils, ses scripts/Makefiles et après quelques jours (bien souvent, ça se met en place en cours de développement) la productivité est bien meilleure.

Quand tu développes en équipe, tout le monde utilise les mêmes outils (à part l'éditeur). Personne ne se fait ses propres makefiles dans son coin, il y a toujours un framework existant sur lequel tu te bases, avec en général un cout non nul sur la productivité.

Bon, encore une fois, tu n'es là que pour pourrir le débat

Non, il avance des arguments valables, que vous niez à toute force en croyant savoir de quoi vous parlez. On est plusieurs au boulot à lire ce thread, tous Linuxiens confirmés je précise (depuis 94 pour les plus anciens), et on se bidonne en voyant les réponses de certains. Preuve que les neuneux ne sont pas forcément tous sous Windows.

Il n'y a pas de débat, vous ne voulez pas débattre. Vous voulez simplement qu'on vous dise ce que vous avez envie d'entendre, que MS c'est mal, que .Net c'est de la merde, que Miguel est un enfoiré, etc... Vous ne voulez surtout pas qu'on remette en cause vos petites convictions de rebelles à 2cents. C'est à cause de gens comme vous que Linux a tant de mal à s'imposer. On a jamais fait avancer les choses avec une paire d'oeillères sur la tête.

les sockets et les IPC System V ce n'est pas standard ? Il suffit de spécifier le protocole de communication. Je ne vois pas la différence avec la spécif d'un composant.

Est-ce que tu vois la différence entre la commande 'cat' et un parser ?