« Que plus d'europeens gagnent leur vie, mais cela au detriment d'autres gens, non ca ne m'interesse pas. »
Tu oublies qui, en premier lieu, est l'agresseur.
« De meme, la delocalisation en Inde ca ne me gene pas plus que ca, ca aide a ameliorer le niveau de vie en Inde, le jour ou ils seront au meme stade que nous, leurs couts seront les memes que les notres. On va peut-etre en chier pendant qqe annees, mais c'est pas grave, on survivra certainement bien mieux que ceux qui vivent en Inde en ce moment.»
En effet les pauvres des États Unis souhaitent de tout coeur à l'Inde de rejoindre leur prestigieux niveau de vie et les joies de l'esclavagisme (prisons, aide sociale contre travail, etc.)
Le moins que l'on puisse dire, c'est que ce « on » qui va en chier, et ce « on » qui survivra bien quand même, ne sont manifestement pas les mêmes personnes.
« Serait-ce une retraite honteuse ? Tu ne réponds toujours pas sur le fond : pourquoi final ne permettrait il pas de faire proprement cette histoire de contrat ? Qu'est-ce qui n'est pas propre dans ma construction (oui, je sais, elle est limitée par l'absence d'héritage multiple) ? »
Parce qu'on peut ne pas vouloir l'ensemble de ce qu'apporte final. Parce qu'en C++ on n'a pas pour objectif d'être un intégriste de l'objet et on utilise le paradigme qui va bien en fonction de la situation. final interdit toute redéfinition, je n'en veux pas, point barre, ce n'est pas difficile à comprendre, c'est une restriction trop forte.
Faire des contrats de cette manière c'est utile, et pas forcément parce qu'il y a un besoin objet derrière. Un point de vue obtus ne concevant qu'objet ne peut pas le comprendre.
Tu vois l'importance des inconvénients comme tu veux, tu n'as pas voulu du premier je t'en ai donné un autre. Pour moi le problème de l'héritage multiple est moins important, parce qu'en pratique quand il y a des contrats, la classe n'implémente pas 36 interfaces différentes. En pratique. Les avantages et inconvénients que toi tu vois ne sont pas forcément partagés par le reste du monde. Ca a l'air très difficile à comprendre.
« Donne moi un seul exemple dans lequel l'hérésie du C++ [snip conneries]»
Ce n'est pas une hérésie parce que C++ n'a pas la prétention (contrairement à Java) d'être exclusivement orienté objet. Ça ne te plait pas dans une approche objet, ne l'utilise pas dans une approche objet. Je ne m'en sers pas dans une approche purement objet, ce n'est pas pour ça que je compte m'en passer ailleurs.
Merci pour cet exposé extrémiste « Seul l'objet existe ». Sur ce, *plonk*.
« Tu en trouveras sûrement d'autres, mais je ne vois toujours pas en quoi avoir des fonctions virtuelles par défaut pose un problème sur cet exemple. Et je maintiens qu'il n'y pas de différences importantes entre final/virtual. Ce que tu as mentionné plus haut (le fait qu'on puisse redéfinir une fonction même si elle n'est pas marquée virtual en C++) est une différence factuelle, mais elle permet de telles horreurs sémantiques en C++ que tout programmeur qui se respecte devrait l'oublier. »
Eh bien si pour toi l'approximation final = non-virtual te convient, ne prend pas cet argument comme inconvénient, que veux-tu que je te dise. Je donnais un exemple à une personne, au cours de la discussion on a parlé de 2 autres aspects encore plus genants dans le meme idiome, si ce sont les seuls qui te paraissent pertinents ne tient compte que de ceux là.
Ailleurs quelqu'un me disait à propos de cette liste qu'aucun exemple ne correspondait à son utilisation. Eh bien tant mieux, dans ce cas il ne rencontre pas ces inconvénients. Si je fais une liste d'inconvénients, je n'ai pas la prétention de dire que ce sont des inconvénients pour tout le monde et dans toutes les situations ! Il fallait juste des exemples, ou plutot des contre-exemples histoire de dire que ça existe. Suivant la manière dont on programme, certains paraitront pertinents, d'autres pas du tout.
Attention je ne dis pas que C++ amène forcément à faire des choses propres, hein, loin de là ! Mais il existe des trucs propres qu'on souhaiterait faire, qui sont possibles en C++ et pas en Java. La contrepartie c'est la possibilité de faire aussi des choses pas propres, mais ce n'est qu'une possibilité. Faut prendre tout ça en compte avant de choisir.
Mais je trouve qu'il y a quand même une différence entre permettre des choses pas propres (bien des aspects de C++, mais si on les connait on les évite), et les rendre obligatoires (emploi d'Object au lieu de templates).
« C'est sûrement moins efficace, mais ridicule, je dois dire que je ne comprends pas pourquoi, d'autant que la STL est très complexe à cause de la gestion mémoire. Et puis bon, les templates c'est dans java 1.5 qui est déjà disponible en version beta... »
Pas ridicule alors, mais « pas très propre ». J'espère l'arrivée des templates changera tout ça, ça devrait être assez sympathique après :)
« Pourrais-tu détailler pourquoi ? »
Juste le fait que final n'est pas l'exact opposé de virtual. C++ n'empêche pas de "redéfinir" une fonction non virtuelle dans une sous-classe. Elle ne sera pas prise dans une recherche dynamique, mais elle peut exister.
« Pour ton exemple, ca n'a aucun rapport avec final, »
Ca tombe bien, c'est toi qui a commencé à parle de final, comme solution au problème que j'évoquais. Ce que je disais en premier lieu : « les fonctions automatiquement virtuelles : impossible de faire de la vérif de pré/post condition derrière l'interface ».
« Pour le reste, je ne comprends rien à ton charabia »
Un expert comme toi n'a sans doute pas besoin de ce qu'il y a entre parenthèses. Contente toi de ce qu'il y a devant : le final de Java n'est pas l'exact contraire de l'absence de virtual en C++. J'avais dit « final n'est pas acceptable quand on veut du non-virtual uniquement », tu as l'air de ne pas vouloir comprendre. Je ne dis pas qu'un final ne peut jamais faire l'affaire, mais qu'il peut être jugé inacceptable.
« Et maintenant que tu te rends compte que tu t'es lourdement trompé, tu oublies tes délires sur final/virtual pour revenir à un élément sur lequel tu as partiellement raison. C'est affligeant. »
Non, je ne me suis pas lourdement trompé, j'ai parlé d'un exemple à quelqu'un qui en demandait. IL était à mon avis suffisamment explicite, tu as jugé que non, tu as demandé des détails et tu les as eus. Je n'y suis pas revenu dans ce post pour te rappeler quel était le véritable objet du fil. J'y ai par contre répondu plus bas en faisant une seconde réponse. Mais ça ne vient que de ta difficulté à comprendre cet idiome pourtant courant, Le problème je l'ai résumé correctement dès le premier post : Java ne propose pas de fonctions non-virtuelles (final c'est autre chose, ça ramène plus que ça) ce qui pose problème pour mettre de la vérification de pré/post conditions dans une interface.
« Je n'ai jamais dit que Java était formidable et bien meilleur que C++ »
Et ? Je n'ai pas dit le contraire, mais figure toi que tu n'es pas le seul participant à ce fil. J'ai répondu, en premier lieu, à quelqu'un qui voulait des exemples de faiblesse de Java, donc je te rappelle que c'est ça le sujet, malgré tes remarques pointilleuses (et surtout sans intérêt, puisque j'avais donné le point essentiel de la critique dès le début).
« Ceci étant, explique moi en quoi ceci démontre la différence entre le final de Java et le virtual de C++ et on verra qui est le plus de mauvaise foi. »
final n'est pas acceptable quand on veut du non-virtual uniquement (donc permettre ce que final n'autorise pas : des fonctions avec le nom en question). Et s'il n'y a pas de final, il n'y a pas de fonctions non-virtuelles, donc la vérification du contrat peut être modifiée par le client, ce qui est un léger problème.
Bien essayé mais c'est toi qui détourne le sujet : la question est, et a toujours été les « manques » de Java, ou ses limitations, qui empêchent de faire des idiomes qui ne sont pas réputés pour être sales. Les contrats, c'est un des meilleurs exemples. Et il y en a d'autres, moins importants, qu'on peut contourner. C'est la question initiale, et tes posts ne servant qu'à détourner de ce sujet, je m'en cogne pas mal. Merci bien pour la causette.
« Oui, oui, bien sûr. Puisque je te dis que c'est la même techno que celle de GJ (ce sont les mêmes auteurs) qui est testé littéralement depuis des années ! »
Ben oui, mais c'est pas encore dans le-java-d'aujourd'hui. Si c'est parfait dès Java 1.5 c'est très bien, J'espère qu'ils n'hésiteront pas à aller vers d'autres bonnes évolutions comme ça.
« Quel est le rapport avec final/virtual ? »
C'est un autre exemple, et j'en ai donné encore un autre dans le post suivant, j'ai donné ceux là parce qu'ils sont plus clairs. Je ne vais pas perdre de temps à en prendre d'autres, moins évidents à décrire : c'est juste qu'il existe des cas comme ça où une chose propre peut se faire en C++ et pas en Java. Et si on y tient ça fait un gros plus pour choisir C++.
« La technologie qui permet les foncteurs existe de façon nettemment plus puissante en Java. L'implémentation proprement dite existe sous forme d'une bibliothèque open source »
Ca fait partie de Java 1.4 ou pas ? Comme je le disais c'est leur conjonction avec d'autres choses qui est appréciable en C++. Il faut déjà attendre les templates, puis si un truc comme ça est intégré (ça n'a pas l'air de l'etre) ce sera très bien. Ca va dans le bon sens, Java répare ses erreurs, mais quelle lenteur de réactivité...
« Note bien que je n'ai pas dit que c'était un mauvais idiome, juste qu'il était incompatible avec les langages à GC. »
Si ça te fait plaisir, oublions celui-là, on m'avait demandé une liste, j'ai donné une liste, d'autres points comme les templates, les contrats sont les vrais problèmes. Celui-ci reste du détail, c'est juste que l'idiome est foireux, mais on peut le contourner en effet.
Comme je m'attends à une bonne dose de mauvaise foi, je complète :
« Je vais même te donner un exemple plus plus simple que je ne pensais au départ : une classe qui implémente proprement plusieurs interfaces. C'est possible en C++, c'est impossible en Java (on ne peut le faire que pour une interface). Proprement, bien sûr, c'est à dire que l'interface inclue le code de vérification pré/post condition. »
Pour résumer simplement, plutot que d'entrer dans chaque détail : C++ a ce qu'il faut pour faire des contrats. L'approche Java des fonctions virtuelles pose problème, entre autres par l'absence de fonctions virtuelles privées.
Bien sûr la solution encore plus propre c'était d'intégrer les contrats au langage, c'est même ce que Gosling aurait souhaité. Mais au final ça n'y est pas, et il n'y a pas de solution pour faire les choses proprement.
« Java 1.5 est disponible en version beta, tu peux tester. La plupart des concepts derrière l'implémentation actuelle datent de gj, une extension de Java qui a au moins 5 ou 6 ans et qui est une technologie très éprouvée. C'est du concret. »
Une version beta ce n'est pas du concret. Quand ce sera stable, ce sera un bon point. Pour l'instant on peut seulement dire : « cet inconvénient sérieux disparaîtra, à plus ou moins long terme ». J'attends le jour où ce sera dans les java libres, d'ici là ça ne vaut rien.
« Oui, oui, bien sûr. Donne un exemple et on va voir. »
Je vais même te donner un exemple plus plus simple que je ne pensais au départ : une classe qui implémente proprement plusieurs interfaces. C'est possible en C++, c'est impossible en Java (on ne peut le faire que pour une interface). Proprement, bien sûr, c'est à dire que l'interface inclue le code de vérification pré/post condition.
« Classes anonymes et interface. Tu connais bien Java, ça fait peur. Tu n'a pas pratiqué depuis la version 1.1 ? »
Et toi tu ferais pas mal de lire (ou plus dur : réfléchir) avant de répondre. Tiens lis donc ma remarque initiale pour voir à quel point tu réponds à coté.
« En Java et en général dans les langages avec GC, tu ne peux pas utiliser cet idiome, donc tu programmes proprement avec un autre idiome. »
C'est bete, des langages utilisent cet idiome. Celui que tu présente s'appelle plutot « bidouille pour compenser une faiblesse ».
« Mais j'oubliais que Java ne sert qu'à faire du web, idiot que je suis. »
Non il ne sert pas qu'à ça, il est idéal pour ça. Il est idéal pour l'enseignement. Au cas par cas, on trouve souvent plus adapté, mais il peut très bien s'en sortir. L'inconvénient est surtout qu'il est frustrant car il ne permet pas de faire des choses propres, à cause de restrictions idiotes.
« Oui, c'est vrai java n'a qu'un mode d'allocation des objets. Alors qu'en C++, même si tu as décidé de n'utiliser que de l'allocation automatique et des smart pointeurs et des références, tu finis par utiliser des librairies qui veulent des pointeurs, des référence ou autre. »
Une bibliothèque qui fonctionne de manière trop différente de ton programme, tu commences par l'encapsuler, non ? Enfin, la plupart du temps ça ne me paraît pas nécessaire.
« Le passage par référence est soit disant la version la plus clean mais quand tu lis le code appelant, tu ne sais pas si c'est un passage par valeur ou référence. »
Ton code appelant a de grosses lacunes en documentation... mais en général const dit ce qu'il en est.
« Si tu fais un programme un peu évolué, tu utilises la STL et tu finis par plus savoir quoi mettre dans tes containers, ref ou pointeur. »
On ne peut pas mettre de ref dans la STL. La STL est orientée valeur, c'est donc de la copie d'objets. Si tu as une sémantique d'identité, tu prends des pointeurs. Éventuellement des pointeurs automatiques de boost.
« En plus dans tes classes, t'es obligé d'utiliser des pointeurs si tu dois préciser des paramètres calculés au constructeur. »
Là je ne vois pas, la liste d'initialisation doit suffire. Ou alors les calculs sont après le constructeur.
« Pour la généricité, c'est p-e propre intellectuellement parlant mais suivant le compilateur, c'est une procédure différente a chaque fois pour compiler. Pour le coté portable de la chose, c'est presque à éviter. »
C'est dans le standard, et c'est bien implanté dans pas mal de compilateurs. Je crois que question portabilité Java est mal placé (dans la pratique, je sais qu'en théorie c'est censé etre le top).
« Le must en Java, que c++ n'a pas du moins difficilement, c'est quand un programme plante en java, il t'écrit la pile des appels de facon compréhensive dans la console. »
« Java 1.5 propose des templates bien plus intéressants et propres que ceux du C++. »
Il y a une incohérence dans ta phrase : un verbe au présent. Quand ce sera du concret, j'enlèverai ce manque, mais pas avant.
« Qu'est-ce que c'est que ce délire ? Tu as déjà entendu parler de final qui permet de faire exactement la même chose que l'absence de virtual en C++ ? Et quel est le rapport avec les pré et post conditions ? »
final et non-virtual c'est pas la même chose. Ah, ça y ressemble de loin, dans le détail non.
Et si tu ne vois pas le rapport avec les pré/post conditions vérifiées dans une interface, ton commentaire suivant sur « comprendre la conception objet » est assez comique.
« De quoi parle tu, des foncteurs de caml ? »
Non des foncteurs de C++. Mais là j'ai dit que je n'étais pas sûr de l'absence d'équivalent. Si tu en vois...
« C'est sûr, quand on ne comprend rien à la conception objet, c'est très utile. »
Ca fait partie de la conception objet, et ça ne pose strictement aucun problème en conception. C'est dans la réalisation qu'il y a problème. Ce n'est pas une raison valable pour l'interdire. Et ça reste à utiliser à bon escient, mais c'est comme tout.
« Il n'y a pas de destructeurs, mais des finalizers dont le but n'est absolument pas le même. De toute manière, si tu as besoin des finalizers, c'est certainement que tu devrais programmer ton appli autrement. »
Oui en faisant un destructeur (c'est le terme générique) que l'on est obligé d'appeler manuellement avant de supprimer la dernière référence. Super propre.
Ta réponse résume le problème de Java : des choix ont été faits, arbitrairement, faites selon cette méthode, pas la votre. C'est pas la meilleure ? Tant pis, c'est celle de Java. Le résultat c'est que Java n'est pas assez généraliste, et que du coup on trouve des langages plus adaptés, pour la plupart des problèmes. A part les applications web, et quelques autres niches. C'est dommage pour ce langage qui a pas mal de qualités, par ailleurs.
« Ben tous tes exemples soit disant disqualifiants, je ne m'en sers pas. Donc en fait je m'en fous :) »
Eh, je ne dis pas que Java est inutile !
Si tu ne te sers pas de ces choses là, pas de problème. Ce que je dis simplement, c'est que si on en a besoin, Java se retrouve disqualifié. Personnellement sur un gros projet, je préfère avoir des interfaces propres, incluant les pré/post conditions, et Java ne le permet pas. Il me faut aussi des templates, il n'y en a pas pour l'instant.
« Et puis il faut apprendre pendant combien de temps le C++ avant d'arriver à trouver une utilité à ces concepts ? 10 ans avant d'écrire un code propre ? »
Il faut plus de temps que pour Java. Java est facile à apprendre, mais pas forcément facile à utiliser. Il faut aussi du temps. Après ça dépend du temps que tu y passes, si tu vas lire les bons bouquins. Donc oui, plus de temps pour C++ (mais *tout* n'est pas indispensable au début) mais quand on le connaît bien, c'est très payant.
« C'est très couteux finalement. Dans de rares cas ça doit valoir le coût, mais sur la majorité des projets je ne crois pas. »
Certes, mais on ne réapprend pas à chaque début de projet, hein. Et rien n'interdit de connaître plusieurs langages, etc.
« Par contre, j'ai bcp de mal à dire templates==généricité. »
Je n'ai rien contre ce que tu dis ensuite, mais je ne vois pas en quoi ça joue... Je trouve qu'il manque ce type de polymorphisme à Java, et l'appréciant en C++, ça me semble un vrai manque. Ca me parait vraiment une bonne chose que ça arrive en Java. Pour tout ce qui est conteneurs, ce que propose Java est quand même ridicule par rapport à la STL à cause de ça, non ?
« Euh, c'est pas un peu le but de final ? »
« final » peut être une solution mais pas toujours, ce n'est pas exactement la même chose.
Maintenant pour ce qui est de la valeur par défaut, personnellement ça ne me dérange pas, mais en effet si je devais en choisir un, je choisirais plutôt comme Java : virtuel par défaut. Et on préciserait les choses avec un mot clé nonvirtual. Mais je parlais surtout de l'existence, pas de valeur par défaut.
Bah, une question de goût. J'ai pour habitude de considérer les fonctions non virtuelles et de ne les rendre virtuelles que quand c'est nécessaire. Mais c'est juste une question d'habitude.
« Mais on en revient tjs à une question de goût vis à vis des langages. La majorité apporte de bonnes choses et trainent qq casseroles. Le tout, c'est de choisir celui qui en trainent le moins pour le projet en cours. »
Tout à fait, je préfère le C++ en général mais parfois je trouverais Java plus adapté. Et C++ est un langage qu'il faut vraiment bien connaître, c'est pas du "C avec classes", il est complexe et ça peut aussi être un inconvénient sérieux.
Quand C++ ne s'impose pas, j'ai l'impression que des langages comme Python sont souvent préférables à Java. Je n'en suis pas sûr, parce que je connais surtout Java et beaucoup moins les langages comme Python, mais j'ai l'impression que ce qui me ferait délaisser C++ dans un projet irait plutot dans le sens de Python (ou similaire) que de Java. Il faudra que je me mette sérieusement à Python pour me faire un avis.
C'est le cas de C++, tu trouveras quelques mots de Stroustrup à ce propos. Évidemment comme toujours, C++ ne l'impose pas, la norme est simplement compatible, des compilateurs pourraient le faire.
Ceci dit, il ne faut pas négliger l'utilisation d'une bibliothèque dédiée, qui propose ses services d'allocation. Et là pas besoin que le langage soit conçu pour tourner avec un GC.
« Va falloir m'expliquer là. Parce que dans un langage à objet, il est quand même bien d'avoir un objet de base qui permette d'avoir un contenant universel. »
J'aurais dû préciser. Je n'en vois pas le besoin mais pourquoi pas. Par contre, quand c'est la seule solution pour remplacer des templates, c'est très crade. Mais des cas où c'est utile, oui je veux bien croire, ça doit exister... quoique ça paraît étrange sur un schéma de conception.
« Quel est le rapport entre les templates et la classe Object ??? Les templates vont amener une certaine généricité (je ne suis pas encore assez au courant pour savoir si elle pourra être contrainte) mais si c'est à la C++, je préfère me tirer une baste tout de suite. :p »
La syntaxe sera pourtant inspirée de celle de C++. Qu'est-ce qui ne te convient pas ? Moi ça me paraît plutot aberrant qu'un langage qui se veut assez généraliste n'en propose pas.
« Ca doit faire maintenant 7 ans que je me paluche du C++ et du Java dans mon taf et, franchement, mon avis est moins tranché que le tien entre Java et C++. Et j'en ai suffisament soupé des limites de C++ pour avoir un doute quant au terme "meilleur" investissement. »
Je vois surtout des limites dans Java. D'ailleurs, c'est ce qu'on reproche à C++ : ne pas en mettre assez (de limites). Ce n'est pas une mauvaise chose de mettre des limites, mais je trouve que Java les a mal placées.
« En tous cas, concernant les concepts objet, ces deux-là sont loin derrière Eiffel à mon humble avis. ;) »
On est d'accord. Mais au moins C++ n'a pas la prétention d'être un langage tout-objet, juste de supporter un minimum de POO (ce qu'il fait mieux que Java: fonctions non virtuelles, héritage multiple, etc.)
« Je pense que si c'etait aussi nul que tout le monde veut bien le dire au dessus, les banques, les assurances, les impots ne lui ferait pas confiance. (Les impots sont memes en train de passer sous jboss, tomcat, linux ... bref bcp de libre) »
Il faut faire la distinction entre les différents reproches qui sont faits. Entre autres, la fiabilité d'une part, le langage d'autre part.
« Je suis totalement ok sur l'amoncellement d'ajouts pour faire plaisir aux programmeurs. »
Ce n'est pas « pour faire plaisir », c'est pour être utile.
« Et non, ca ne disqualifie pas java, il faut juste penser la conception correctement. »
Rien à voir. La conception est aussi importante dans les deux cas.
« J'aimerai bien un example disqualifiant comme tu dis ... »
Les plus évidents:
- l'absence de templates, on ne peut s'en sortir que de manière crade (classe Object).
- les fonctions automatiquement virtuelles : impossible de faire de la vérif de pré/post condition derrière l'interface, qui est l'endroit où les faire (ça ne doit pas être laissé à la classe qui implémente).
- l'absence des foncteurs (si ma mémoire est bonne) - c'est vrai que sans templates, sans conteneurs en sémantique de valeur etc. c'est moins utile, mais l'ensemble permet de faire des choses efficaces et propres
- tout ce qui incite à ne faire que de la sémantique d'identité
- dans une moindre mesure : pas de surcharge d'opérateurs, pas d'héritage multiple (oui ça sert à faire des choses propres)
- les destructeurs dont l'appel n'est pas garanti
« Personnellement, pour avoir commencer l'objet en c++, et avoir continuer en java, je produis plus rapidement un code de meilleure qualité en java, et c'est ca le plus important au final. »
Qu'est-ce qui te permets de dire qu'il est de meilleure qualité, si tu as arrêté le C++ en cours de route ? Et tu parles toujours des aspects objets, ou d'autre chose ?
« Je trouve qu'il est plus facile de relire du mauvais code java que du bon code c++ »
Ça ce n'est qu'une question d'habitude. J'ai aussi fait des deux, et je fais surtout du C++ maintenant, je trouve Java moins lisible. La SL est sûrement plus ardue à appréhender, mais plus lisible une fois qu'on s'y est investi.
« Mais c'est tellement plus juste que ce soit les développeurs qui choisissent leur licence. »
Faut relativiser ça quand même : le libre copyleft et le libre non-copyleft sont les deux grands types de licences libres. Dès qu'on introduit de nouvelles licences on augmente les risques d'incompatibilité et le temps passé en problèmes de licence. Donc si on voit vraiment quelque chose de gênant, il faut envisager de faire sa licence, mais il ne faut pas le faire pour le moindre détail... enfin le développeur fait ce qu'il veut, mais ça paraît vraiment réduire l'intérêt de mettre le logiciel en libre.
« C++ n'est qu'un amoncellement d'ajouts pour permettre au programmeur toutes les dernières folies. »
Permettre des choses que Java ne permet pas toujours, et qui le disqualifie.
« Un jour peut être finiront t'il par nettoyer une bonne fois pour toutes la gestion des pointeur »
Très souvent on peut s'en passer, encore faut-il le faire.
« l'allocation dynamique et autre qui finissent par couter très cher en temps de développement sur une appli ou on chercher tous les bugs. »
Là c'est le comble ! Java ne fait que de l'allocation dynamique ! Au moins C++ permet de faire de l'allocation automatique. Et si c'est un ramasse-miettes qui te manque, eh bien il suffit d'en mettre un.
« On va me dire que c'est au programmeur de coder proprement, de ne pas mélanger le C et le C++. Mais c'est justement là toute la différence entre un langage propre et un langage qui n'est qu'une rustine pour éviter aux gens pleins d'inertie d'apprendre une nouvelle syntaxe. »
Il suffit de connaître son langage, et il n'y a pas besoin de connaître C pour connaître le C++. Et vu la syntaxe de C++, il est clair que le but n'est pas de faciliter la transitions aux développeurs C.
« Java est plus proche du but que C++ avec ces objets Integer, etc. et il possède au moins l'avantage d'avoir un objet de base Object, ce qui manque cruellement en C++ (pff). Et je parle même pas des templates en C++ sur lesquels je m'arrache les cheveux juste pour une pseudo généricité. »
Ah, la classe Object, un des trucs les plus dégueulasses jamais réalisés. Heureusement Java reconnaît son erreur et va admettre des templates dans la prochaine version. Faire du générique sans support, c'est quand même aussi crade que de l'objet sans support du langage (comme de l'objet en C)
« En bref, tous les langages ont leurs défauts et il serait bien d'arrêter dire Java, c'est nul, C++, c'est de la balle. »
Ce n'est pas aussi simple. Le problème c'est que Java a trop de limitations (volontaires) censées simplifier, mais qui *manquent* vraiment. Java m'a longtemps paru meilleur, mais finalement C++ est un meilleur investissement. Par contre, il est clair qu'il faut très bien le connaître, et que son apprentissage est nettement plus long.
[^] # Re: Linux dans le Magazine "Capital" du mois de Mars 2004
Posté par #3588 . En réponse à la dépêche Linux dans le Magazine "Capital" du mois de Mars 2004. Évalué à 3.
Tu oublies qui, en premier lieu, est l'agresseur.
« De meme, la delocalisation en Inde ca ne me gene pas plus que ca, ca aide a ameliorer le niveau de vie en Inde, le jour ou ils seront au meme stade que nous, leurs couts seront les memes que les notres. On va peut-etre en chier pendant qqe annees, mais c'est pas grave, on survivra certainement bien mieux que ceux qui vivent en Inde en ce moment.»
En effet les pauvres des États Unis souhaitent de tout coeur à l'Inde de rejoindre leur prestigieux niveau de vie et les joies de l'esclavagisme (prisons, aide sociale contre travail, etc.)
Le moins que l'on puisse dire, c'est que ce « on » qui va en chier, et ce « on » qui survivra bien quand même, ne sont manifestement pas les mêmes personnes.
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.
Parce qu'on peut ne pas vouloir l'ensemble de ce qu'apporte final. Parce qu'en C++ on n'a pas pour objectif d'être un intégriste de l'objet et on utilise le paradigme qui va bien en fonction de la situation. final interdit toute redéfinition, je n'en veux pas, point barre, ce n'est pas difficile à comprendre, c'est une restriction trop forte.
Faire des contrats de cette manière c'est utile, et pas forcément parce qu'il y a un besoin objet derrière. Un point de vue obtus ne concevant qu'objet ne peut pas le comprendre.
Tu vois l'importance des inconvénients comme tu veux, tu n'as pas voulu du premier je t'en ai donné un autre. Pour moi le problème de l'héritage multiple est moins important, parce qu'en pratique quand il y a des contrats, la classe n'implémente pas 36 interfaces différentes. En pratique. Les avantages et inconvénients que toi tu vois ne sont pas forcément partagés par le reste du monde. Ca a l'air très difficile à comprendre.
« Donne moi un seul exemple dans lequel l'hérésie du C++ [snip conneries]»
Ce n'est pas une hérésie parce que C++ n'a pas la prétention (contrairement à Java) d'être exclusivement orienté objet. Ça ne te plait pas dans une approche objet, ne l'utilise pas dans une approche objet. Je ne m'en sers pas dans une approche purement objet, ce n'est pas pour ça que je compte m'en passer ailleurs.
Merci pour cet exposé extrémiste « Seul l'objet existe ». Sur ce, *plonk*.
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 0.
Eh bien si pour toi l'approximation final = non-virtual te convient, ne prend pas cet argument comme inconvénient, que veux-tu que je te dise. Je donnais un exemple à une personne, au cours de la discussion on a parlé de 2 autres aspects encore plus genants dans le meme idiome, si ce sont les seuls qui te paraissent pertinents ne tient compte que de ceux là.
Ailleurs quelqu'un me disait à propos de cette liste qu'aucun exemple ne correspondait à son utilisation. Eh bien tant mieux, dans ce cas il ne rencontre pas ces inconvénients. Si je fais une liste d'inconvénients, je n'ai pas la prétention de dire que ce sont des inconvénients pour tout le monde et dans toutes les situations ! Il fallait juste des exemples, ou plutot des contre-exemples histoire de dire que ça existe. Suivant la manière dont on programme, certains paraitront pertinents, d'autres pas du tout.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 0.
Mais je trouve qu'il y a quand même une différence entre permettre des choses pas propres (bien des aspects de C++, mais si on les connait on les évite), et les rendre obligatoires (emploi d'Object au lieu de templates).
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.
Pas ridicule alors, mais « pas très propre ». J'espère l'arrivée des templates changera tout ça, ça devrait être assez sympathique après :)
« Pourrais-tu détailler pourquoi ? »
Juste le fait que final n'est pas l'exact opposé de virtual. C++ n'empêche pas de "redéfinir" une fonction non virtuelle dans une sous-classe. Elle ne sera pas prise dans une recherche dynamique, mais elle peut exister.
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.
Ca tombe bien, c'est toi qui a commencé à parle de final, comme solution au problème que j'évoquais. Ce que je disais en premier lieu : « les fonctions automatiquement virtuelles : impossible de faire de la vérif de pré/post condition derrière l'interface ».
« Pour le reste, je ne comprends rien à ton charabia »
Un expert comme toi n'a sans doute pas besoin de ce qu'il y a entre parenthèses. Contente toi de ce qu'il y a devant : le final de Java n'est pas l'exact contraire de l'absence de virtual en C++. J'avais dit « final n'est pas acceptable quand on veut du non-virtual uniquement », tu as l'air de ne pas vouloir comprendre. Je ne dis pas qu'un final ne peut jamais faire l'affaire, mais qu'il peut être jugé inacceptable.
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -2.
Non, je ne me suis pas lourdement trompé, j'ai parlé d'un exemple à quelqu'un qui en demandait. IL était à mon avis suffisamment explicite, tu as jugé que non, tu as demandé des détails et tu les as eus. Je n'y suis pas revenu dans ce post pour te rappeler quel était le véritable objet du fil. J'y ai par contre répondu plus bas en faisant une seconde réponse. Mais ça ne vient que de ta difficulté à comprendre cet idiome pourtant courant, Le problème je l'ai résumé correctement dès le premier post : Java ne propose pas de fonctions non-virtuelles (final c'est autre chose, ça ramène plus que ça) ce qui pose problème pour mettre de la vérification de pré/post conditions dans une interface.
« Je n'ai jamais dit que Java était formidable et bien meilleur que C++ »
Et ? Je n'ai pas dit le contraire, mais figure toi que tu n'es pas le seul participant à ce fil. J'ai répondu, en premier lieu, à quelqu'un qui voulait des exemples de faiblesse de Java, donc je te rappelle que c'est ça le sujet, malgré tes remarques pointilleuses (et surtout sans intérêt, puisque j'avais donné le point essentiel de la critique dès le début).
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.
« Ceci étant, explique moi en quoi ceci démontre la différence entre le final de Java et le virtual de C++ et on verra qui est le plus de mauvaise foi. »
final n'est pas acceptable quand on veut du non-virtual uniquement (donc permettre ce que final n'autorise pas : des fonctions avec le nom en question). Et s'il n'y a pas de final, il n'y a pas de fonctions non-virtuelles, donc la vérification du contrat peut être modifiée par le client, ce qui est un léger problème.
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -3.
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.
Ben oui, mais c'est pas encore dans le-java-d'aujourd'hui. Si c'est parfait dès Java 1.5 c'est très bien, J'espère qu'ils n'hésiteront pas à aller vers d'autres bonnes évolutions comme ça.
« Quel est le rapport avec final/virtual ? »
C'est un autre exemple, et j'en ai donné encore un autre dans le post suivant, j'ai donné ceux là parce qu'ils sont plus clairs. Je ne vais pas perdre de temps à en prendre d'autres, moins évidents à décrire : c'est juste qu'il existe des cas comme ça où une chose propre peut se faire en C++ et pas en Java. Et si on y tient ça fait un gros plus pour choisir C++.
« La technologie qui permet les foncteurs existe de façon nettemment plus puissante en Java. L'implémentation proprement dite existe sous forme d'une bibliothèque open source »
Ca fait partie de Java 1.4 ou pas ? Comme je le disais c'est leur conjonction avec d'autres choses qui est appréciable en C++. Il faut déjà attendre les templates, puis si un truc comme ça est intégré (ça n'a pas l'air de l'etre) ce sera très bien. Ca va dans le bon sens, Java répare ses erreurs, mais quelle lenteur de réactivité...
« Note bien que je n'ai pas dit que c'était un mauvais idiome, juste qu'il était incompatible avec les langages à GC. »
Si ça te fait plaisir, oublions celui-là, on m'avait demandé une liste, j'ai donné une liste, d'autres points comme les templates, les contrats sont les vrais problèmes. Celui-ci reste du détail, c'est juste que l'idiome est foireux, mais on peut le contourner en effet.
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.
« Je vais même te donner un exemple plus plus simple que je ne pensais au départ : une classe qui implémente proprement plusieurs interfaces. C'est possible en C++, c'est impossible en Java (on ne peut le faire que pour une interface). Proprement, bien sûr, c'est à dire que l'interface inclue le code de vérification pré/post condition. »
Pour résumer simplement, plutot que d'entrer dans chaque détail : C++ a ce qu'il faut pour faire des contrats. L'approche Java des fonctions virtuelles pose problème, entre autres par l'absence de fonctions virtuelles privées.
Bien sûr la solution encore plus propre c'était d'intégrer les contrats au langage, c'est même ce que Gosling aurait souhaité. Mais au final ça n'y est pas, et il n'y a pas de solution pour faire les choses proprement.
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.
Une version beta ce n'est pas du concret. Quand ce sera stable, ce sera un bon point. Pour l'instant on peut seulement dire : « cet inconvénient sérieux disparaîtra, à plus ou moins long terme ». J'attends le jour où ce sera dans les java libres, d'ici là ça ne vaut rien.
« Oui, oui, bien sûr. Donne un exemple et on va voir. »
Je vais même te donner un exemple plus plus simple que je ne pensais au départ : une classe qui implémente proprement plusieurs interfaces. C'est possible en C++, c'est impossible en Java (on ne peut le faire que pour une interface). Proprement, bien sûr, c'est à dire que l'interface inclue le code de vérification pré/post condition.
« Classes anonymes et interface. Tu connais bien Java, ça fait peur. Tu n'a pas pratiqué depuis la version 1.1 ? »
Et toi tu ferais pas mal de lire (ou plus dur : réfléchir) avant de répondre. Tiens lis donc ma remarque initiale pour voir à quel point tu réponds à coté.
« En Java et en général dans les langages avec GC, tu ne peux pas utiliser cet idiome, donc tu programmes proprement avec un autre idiome. »
C'est bete, des langages utilisent cet idiome. Celui que tu présente s'appelle plutot « bidouille pour compenser une faiblesse ».
« Mais j'oubliais que Java ne sert qu'à faire du web, idiot que je suis. »
Non il ne sert pas qu'à ça, il est idéal pour ça. Il est idéal pour l'enseignement. Au cas par cas, on trouve souvent plus adapté, mais il peut très bien s'en sortir. L'inconvénient est surtout qu'il est frustrant car il ne permet pas de faire des choses propres, à cause de restrictions idiotes.
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 0.
Une bibliothèque qui fonctionne de manière trop différente de ton programme, tu commences par l'encapsuler, non ? Enfin, la plupart du temps ça ne me paraît pas nécessaire.
« Le passage par référence est soit disant la version la plus clean mais quand tu lis le code appelant, tu ne sais pas si c'est un passage par valeur ou référence. »
Ton code appelant a de grosses lacunes en documentation... mais en général const dit ce qu'il en est.
« Si tu fais un programme un peu évolué, tu utilises la STL et tu finis par plus savoir quoi mettre dans tes containers, ref ou pointeur. »
On ne peut pas mettre de ref dans la STL. La STL est orientée valeur, c'est donc de la copie d'objets. Si tu as une sémantique d'identité, tu prends des pointeurs. Éventuellement des pointeurs automatiques de boost.
« En plus dans tes classes, t'es obligé d'utiliser des pointeurs si tu dois préciser des paramètres calculés au constructeur. »
Là je ne vois pas, la liste d'initialisation doit suffire. Ou alors les calculs sont après le constructeur.
« Pour la généricité, c'est p-e propre intellectuellement parlant mais suivant le compilateur, c'est une procédure différente a chaque fois pour compiler. Pour le coté portable de la chose, c'est presque à éviter. »
C'est dans le standard, et c'est bien implanté dans pas mal de compilateurs. Je crois que question portabilité Java est mal placé (dans la pratique, je sais qu'en théorie c'est censé etre le top).
« Le must en Java, que c++ n'a pas du moins difficilement, c'est quand un programme plante en java, il t'écrit la pile des appels de facon compréhensive dans la console. »
Oui, là rien à redire.
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 0.
Il y a une incohérence dans ta phrase : un verbe au présent. Quand ce sera du concret, j'enlèverai ce manque, mais pas avant.
« Qu'est-ce que c'est que ce délire ? Tu as déjà entendu parler de final qui permet de faire exactement la même chose que l'absence de virtual en C++ ? Et quel est le rapport avec les pré et post conditions ? »
final et non-virtual c'est pas la même chose. Ah, ça y ressemble de loin, dans le détail non.
Et si tu ne vois pas le rapport avec les pré/post conditions vérifiées dans une interface, ton commentaire suivant sur « comprendre la conception objet » est assez comique.
« De quoi parle tu, des foncteurs de caml ? »
Non des foncteurs de C++. Mais là j'ai dit que je n'étais pas sûr de l'absence d'équivalent. Si tu en vois...
« C'est sûr, quand on ne comprend rien à la conception objet, c'est très utile. »
Ca fait partie de la conception objet, et ça ne pose strictement aucun problème en conception. C'est dans la réalisation qu'il y a problème. Ce n'est pas une raison valable pour l'interdire. Et ça reste à utiliser à bon escient, mais c'est comme tout.
« Il n'y a pas de destructeurs, mais des finalizers dont le but n'est absolument pas le même. De toute manière, si tu as besoin des finalizers, c'est certainement que tu devrais programmer ton appli autrement. »
Oui en faisant un destructeur (c'est le terme générique) que l'on est obligé d'appeler manuellement avant de supprimer la dernière référence. Super propre.
Ta réponse résume le problème de Java : des choix ont été faits, arbitrairement, faites selon cette méthode, pas la votre. C'est pas la meilleure ? Tant pis, c'est celle de Java. Le résultat c'est que Java n'est pas assez généraliste, et que du coup on trouve des langages plus adaptés, pour la plupart des problèmes. A part les applications web, et quelques autres niches. C'est dommage pour ce langage qui a pas mal de qualités, par ailleurs.
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.
Eh, je ne dis pas que Java est inutile !
Si tu ne te sers pas de ces choses là, pas de problème. Ce que je dis simplement, c'est que si on en a besoin, Java se retrouve disqualifié. Personnellement sur un gros projet, je préfère avoir des interfaces propres, incluant les pré/post conditions, et Java ne le permet pas. Il me faut aussi des templates, il n'y en a pas pour l'instant.
« Et puis il faut apprendre pendant combien de temps le C++ avant d'arriver à trouver une utilité à ces concepts ? 10 ans avant d'écrire un code propre ? »
Il faut plus de temps que pour Java. Java est facile à apprendre, mais pas forcément facile à utiliser. Il faut aussi du temps. Après ça dépend du temps que tu y passes, si tu vas lire les bons bouquins. Donc oui, plus de temps pour C++ (mais *tout* n'est pas indispensable au début) mais quand on le connaît bien, c'est très payant.
« C'est très couteux finalement. Dans de rares cas ça doit valoir le coût, mais sur la majorité des projets je ne crois pas. »
Certes, mais on ne réapprend pas à chaque début de projet, hein. Et rien n'interdit de connaître plusieurs langages, etc.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 0.
Je n'ai rien contre ce que tu dis ensuite, mais je ne vois pas en quoi ça joue... Je trouve qu'il manque ce type de polymorphisme à Java, et l'appréciant en C++, ça me semble un vrai manque. Ca me parait vraiment une bonne chose que ça arrive en Java. Pour tout ce qui est conteneurs, ce que propose Java est quand même ridicule par rapport à la STL à cause de ça, non ?
« Euh, c'est pas un peu le but de final ? »
« final » peut être une solution mais pas toujours, ce n'est pas exactement la même chose.
Maintenant pour ce qui est de la valeur par défaut, personnellement ça ne me dérange pas, mais en effet si je devais en choisir un, je choisirais plutôt comme Java : virtuel par défaut. Et on préciserait les choses avec un mot clé nonvirtual. Mais je parlais surtout de l'existence, pas de valeur par défaut.
Bah, une question de goût. J'ai pour habitude de considérer les fonctions non virtuelles et de ne les rendre virtuelles que quand c'est nécessaire. Mais c'est juste une question d'habitude.
« Mais on en revient tjs à une question de goût vis à vis des langages. La majorité apporte de bonnes choses et trainent qq casseroles. Le tout, c'est de choisir celui qui en trainent le moins pour le projet en cours. »
Tout à fait, je préfère le C++ en général mais parfois je trouverais Java plus adapté. Et C++ est un langage qu'il faut vraiment bien connaître, c'est pas du "C avec classes", il est complexe et ça peut aussi être un inconvénient sérieux.
Quand C++ ne s'impose pas, j'ai l'impression que des langages comme Python sont souvent préférables à Java. Je n'en suis pas sûr, parce que je connais surtout Java et beaucoup moins les langages comme Python, mais j'ai l'impression que ce qui me ferait délaisser C++ dans un projet irait plutot dans le sens de Python (ou similaire) que de Java. Il faudra que je me mette sérieusement à Python pour me faire un avis.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 0.
Ceci dit, il ne faut pas négliger l'utilisation d'une bibliothèque dédiée, qui propose ses services d'allocation. Et là pas besoin que le langage soit conçu pour tourner avec un GC.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.
J'aurais dû préciser. Je n'en vois pas le besoin mais pourquoi pas. Par contre, quand c'est la seule solution pour remplacer des templates, c'est très crade. Mais des cas où c'est utile, oui je veux bien croire, ça doit exister... quoique ça paraît étrange sur un schéma de conception.
« Quel est le rapport entre les templates et la classe Object ??? Les templates vont amener une certaine généricité (je ne suis pas encore assez au courant pour savoir si elle pourra être contrainte) mais si c'est à la C++, je préfère me tirer une baste tout de suite. :p »
La syntaxe sera pourtant inspirée de celle de C++. Qu'est-ce qui ne te convient pas ? Moi ça me paraît plutot aberrant qu'un langage qui se veut assez généraliste n'en propose pas.
« Ca doit faire maintenant 7 ans que je me paluche du C++ et du Java dans mon taf et, franchement, mon avis est moins tranché que le tien entre Java et C++. Et j'en ai suffisament soupé des limites de C++ pour avoir un doute quant au terme "meilleur" investissement. »
Je vois surtout des limites dans Java. D'ailleurs, c'est ce qu'on reproche à C++ : ne pas en mettre assez (de limites). Ce n'est pas une mauvaise chose de mettre des limites, mais je trouve que Java les a mal placées.
« En tous cas, concernant les concepts objet, ces deux-là sont loin derrière Eiffel à mon humble avis. ;) »
On est d'accord. Mais au moins C++ n'a pas la prétention d'être un langage tout-objet, juste de supporter un minimum de POO (ce qu'il fait mieux que Java: fonctions non virtuelles, héritage multiple, etc.)
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 0.
Il faut faire la distinction entre les différents reproches qui sont faits. Entre autres, la fiabilité d'une part, le langage d'autre part.
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.
Ce n'est pas « pour faire plaisir », c'est pour être utile.
« Et non, ca ne disqualifie pas java, il faut juste penser la conception correctement. »
Rien à voir. La conception est aussi importante dans les deux cas.
« J'aimerai bien un example disqualifiant comme tu dis ... »
Les plus évidents:
- l'absence de templates, on ne peut s'en sortir que de manière crade (classe Object).
- les fonctions automatiquement virtuelles : impossible de faire de la vérif de pré/post condition derrière l'interface, qui est l'endroit où les faire (ça ne doit pas être laissé à la classe qui implémente).
- l'absence des foncteurs (si ma mémoire est bonne) - c'est vrai que sans templates, sans conteneurs en sémantique de valeur etc. c'est moins utile, mais l'ensemble permet de faire des choses efficaces et propres
- tout ce qui incite à ne faire que de la sémantique d'identité
- dans une moindre mesure : pas de surcharge d'opérateurs, pas d'héritage multiple (oui ça sert à faire des choses propres)
- les destructeurs dont l'appel n'est pas garanti
« Personnellement, pour avoir commencer l'objet en c++, et avoir continuer en java, je produis plus rapidement un code de meilleure qualité en java, et c'est ca le plus important au final. »
Qu'est-ce qui te permets de dire qu'il est de meilleure qualité, si tu as arrêté le C++ en cours de route ? Et tu parles toujours des aspects objets, ou d'autre chose ?
« Je trouve qu'il est plus facile de relire du mauvais code java que du bon code c++ »
Ça ce n'est qu'une question d'habitude. J'ai aussi fait des deux, et je fais surtout du C++ maintenant, je trouve Java moins lisible. La SL est sûrement plus ardue à appréhender, mais plus lisible une fois qu'on s'y est investi.
[^] # Re: Theo de Raadt décide le fork de Apache
Posté par #3588 . En réponse à la dépêche Theo de Raadt décide le fork de Apache. Évalué à 1.
Faut relativiser ça quand même : le libre copyleft et le libre non-copyleft sont les deux grands types de licences libres. Dès qu'on introduit de nouvelles licences on augmente les risques d'incompatibilité et le temps passé en problèmes de licence. Donc si on voit vraiment quelque chose de gênant, il faut envisager de faire sa licence, mais il ne faut pas le faire pour le moindre détail... enfin le développeur fait ce qu'il veut, mais ça paraît vraiment réduire l'intérêt de mettre le logiciel en libre.
[^] # Re: Des utilisateurs heureux de Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.
Permettre des choses que Java ne permet pas toujours, et qui le disqualifie.
« Un jour peut être finiront t'il par nettoyer une bonne fois pour toutes la gestion des pointeur »
Très souvent on peut s'en passer, encore faut-il le faire.
« l'allocation dynamique et autre qui finissent par couter très cher en temps de développement sur une appli ou on chercher tous les bugs. »
Là c'est le comble ! Java ne fait que de l'allocation dynamique ! Au moins C++ permet de faire de l'allocation automatique. Et si c'est un ramasse-miettes qui te manque, eh bien il suffit d'en mettre un.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à 0.
Non, pas si on parle du langage. A toi d'utiliser des bibliothèques portables.
Et un programme Java n'est jamais portable que là où il y a de bonnes JVM, ce qui est plus limité que les plateformes disposant de compilateur C++.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.
« On va me dire que c'est au programmeur de coder proprement, de ne pas mélanger le C et le C++. Mais c'est justement là toute la différence entre un langage propre et un langage qui n'est qu'une rustine pour éviter aux gens pleins d'inertie d'apprendre une nouvelle syntaxe. »
Il suffit de connaître son langage, et il n'y a pas besoin de connaître C pour connaître le C++. Et vu la syntaxe de C++, il est clair que le but n'est pas de faciliter la transitions aux développeurs C.
« Java est plus proche du but que C++ avec ces objets Integer, etc. et il possède au moins l'avantage d'avoir un objet de base Object, ce qui manque cruellement en C++ (pff). Et je parle même pas des templates en C++ sur lesquels je m'arrache les cheveux juste pour une pseudo généricité. »
Ah, la classe Object, un des trucs les plus dégueulasses jamais réalisés. Heureusement Java reconnaît son erreur et va admettre des templates dans la prochaine version. Faire du générique sans support, c'est quand même aussi crade que de l'objet sans support du langage (comme de l'objet en C)
« En bref, tous les langages ont leurs défauts et il serait bien d'arrêter dire Java, c'est nul, C++, c'est de la balle. »
Ce n'est pas aussi simple. Le problème c'est que Java a trop de limitations (volontaires) censées simplifier, mais qui *manquent* vraiment. Java m'a longtemps paru meilleur, mais finalement C++ est un meilleur investissement. Par contre, il est clair qu'il faut très bien le connaître, et que son apprentissage est nettement plus long.
[^] # Re: IBM demande à Sun de "libérer" Java
Posté par #3588 . En réponse à la dépêche IBM demande à Sun de "libérer" Java. Évalué à -1.