Articles précédents : Développeur
- [13] La Fondation Mozilla a un an
- [34] Un nouveau site à propos de la bibliothèque Qt.
- [30] Appel à contribution sur l'avenir de XUL
- [7] Un jeu concours
- [22] Sortie de JOFFAD 2.0 !
- [23] Concours pour la promotion de projets Libres francophones.
- [9] Traduction du tutoriel de GnuArch
- [16] Projet tuteuré pour apprendre Zope
- [16] Nouveau service APINC : DevLibre
- [89] Les spécifications du langage D sont arrivées
Liens connexes
- Le projet Mono (1007 hits)
- La présentation d'Arstechnica (1303 hits)
- L'interview de Miguel de Icaza (445 hits)
- La sortie de Mono 1.0 sur DLFP (775 hits)
Dépêche modérée par
Dépêche éditée par
Développeur : Mono 1.0 sous le feu des projecteurs
Posté par patrick_g (page perso, ). Modéré le 16 juillet 2004.Un article sur le site Arstechnica donne des exemples (et du code ; par exemple avec GTK#) et développe l'idée que ce framework offre des gages de rapidité de développement, du fait d'une grande simplicité.
Le projet Mono (1007 hits)
La présentation d'Arstechnica (1303 hits)
L'interview de Miguel de Icaza (445 hits)
La sortie de Mono 1.0 sur DLFP (775 hits)
> Lire la suite (177 commentaires, moyenne: 2,4). [dépêche : 1403 caractères]
Il est à noter que le projet GNOME est actuellement en phase de réflexion sur son avenir afin de faciliter et d'en accélérer le développement.
Le projet Mono est l'un des candidats envisagé mais il rencontre une grande résistance du fait de son « origine » Microsoft et des incertitudes sur les problèmes de brevets.
Une autre difficulté est qu'il sera, par essence, toujours en retard sur les dernières nouveautés de Microsoft comme c'est déjà le cas actuellement, selon l'aveu même du leader du projet Mono signalant que « Nous sommes en retard ; nous sommes très en retard ; nous avons 18 mois de retard par rapport à Microsoft ».
C'est un troll.
C'est un troll ou quoi cet article d'Arstechnica ?
D'abord on peut lire :
Mono's main pull for developers is that it is cross-platform and makes writing applications very fast because of its extensive framework. Mono also has the concept of garbage collection. Gone are the days of using malloc() and free() and recording where you allocated memory and making sure you free() it. Java has GC as well, but Java never really caught on as an application language.
Gni ? Ça veut dire que l'auteur pense que Java n'a jamais été utilisé pour écrire des vrais programmes ? C'est du grand n'importe quoi.
Ensuite on nous présente un exemple de code, avec le morceau de bravoure suivant :
The great power of Mono and .NET lies in the ONE line of code:
bool matches = Regex.IsMatch( input, regex );
.NET and Mono are actually a collection of libraries that form a framework which allows you, the programmer, to write the logic of your application. I can call one line of code to do input validation on a string which saves you possibly hours of time. Things like Input validation, network communication, file reading and writing, text encoding, regular expressions, formatting, XML Parsing, LDAP Access, remoting, and GUI development are reduced to just a few lines of code compared to possibly hundreds.
Euh, oui c'est sûr si on compare .Net à l'assembleur, c'est sûr qu'il faut une seule ligne par rapport à plein de lignes pour faire ça. Sauf que .Net vient chasser sur les terres de Java, hors en Java ça s'écrit en une ligne (et avec moins de caractères en plus).
boolean matches = input.matches( regex );
Bon on se décourage pas on continue. On nous montre ensuite une belle page de Gtk#, bon on aime ou on aime pas, moi je trouve que le style impératif forcé de Gtk+ donne des fonctions illisibles et trop longues mais bon c'est pas le sujet. La conclusion est assez fantastique :
a commercial software provider would target Mono and it would "just work" on all platforms that Mono supported. How is this different from Java? In my opinion Java makes things harder than it needs to be. For starters, enforced exception handling can't auto-box/unbox primitive types and doesn't support arbitrary length parameter lists String.Format() style.
Alors le type a rien prouvé du tout vu qu'il n'a jamais comparé avec Java sauf à dire que en Java y'a pas d'applications, mais bon il se permet quand même de dire qu'en Java c'est trop dur (sous-entendu c'est plus simple en .Net ? oui mais où et comment ?). Ensuite il parle à la fois d'exception et des types primitifs, là j'avoue que je comprends pas le rapport, mais il pointe un problème effectivement de Java (la dualité int/Integer et compagnie qui est vraiment un truc chiant en Java) et ensuite nous parle de l'impossibilité d'appeler une méthode Format avec un nombre variable de paramètres.
Ok, donc, .Net est vachement mieux que Java parce que... y'a pas le problème des types primitifs de Java, et y'a des méthodes avec nombre variable de paramètres ? On est d'accords que ce sont des problèmes de Java mais si .Net compte là-dessus pour faire la différence ça laisse rêveur...
Il finit par :
The framework of Mono provides the ability to make a very tedious task in C/C++ almost trivial in C#. As the above example, RegEx, shows, it helps the programmer concentrate on the program itself, rather than the logic supporting the code.
Ouais bon d'accord mais ça on sait que la gestion automatique de la mémoire c'est une avancée importante, et qu'une bonne bibliothèque de base c'est capital. Bref, cet article ne montre aucun intérêt de .Net par rapport à Java, (alors que .Net est là juste pour tuer Java, ce qui est de notoriété publique)
Cependant, et pour adopter un point de vue plus utile à Linux et au logiciel libre, ça peut être intéressant de disposer d'un runtime libre (Mono), car en face il n'y a pas de runtime libre Java correct à ma connaissance - mais il ne me semble pas que ce point soit abordé dans l'article.
-
[^]Re: C'est un troll.
Posté par lezardbreton (Jabber id, page perso, ) le 16/07/2004 à 14:43. (lien). Évalué à 9.Java never really caught on as an application language.
Effectivement, cette phrase peut choquer les afficionados de java.
Pour expliquer ce que l'auteur voulait dire, je vous fournis une statistique que j'ai faite récemment sur l'environnement d'une entreprise de grande dimension pour laquelle je travaille.
Le catalogue des applications logicielles pour Windows contient 2143 logiciels différents. Parmi ceux-ci, 56 ont une machine virtuelle java comme pré-requis, soit 2.61%. Il existe aussi 5 applications ayant comme pré-requis le framework .Net, soit 0.23% du parc.
Je pense pour ma part que c'est assez révélateur de l'état actuel de la popularité de ces deux plate-formes sur les postes clients, et il reste donc beaucoup de chemin à faire.-
[^]Re: C'est un troll.
Posté par gc (page perso, ) le 16/07/2004 à 14:56. (lien). Évalué à 4.Tu penses que parler d'une seule boîte ça indique une statistique intéressante ? Je vais paraître aggressif mais çe me fait penser au journal télévisé : hop, on a un exemple d'un truc à un endroit, hop on le présente comme le cas général. Oui dans cette grande entreprise c'est le cas. Et si dans la grande banque à côté ils utilisent quasi-uniquement du Java, on comptera 90% de Java et on dira que c'est révélateur de quelque chose ? (et au passage je précise que je fais du Java pour gagner ma vie mais que je ne suis pas du tout un aficionado de ce langage)
Bon, alors essayons de trouver des stats. Comparons par exemple Java avec C++, puisque le C++ était le langage le plus poussé en avant par Microsoft pour faire des applications jusqu'à l'arrivée de .Net (le VB étant réservé aux scripts et petits programmes).
Recherchons sur google les matches de gens qui cherchent à embaucher des développeurs C++ et Java (ça n'indique pas le nombre de programmes en circulation mais plutôt la tendance d'avenir ce qui est ce qui nous intéresse je suppose).
"software developer" c++ hire -> 7500 matches
"software developer" java hire -> 13200 matches
Allez hop recherchons les annonces sur jobpilot.fr. Dans les 4 dernières semaines pour du développement logiciel, 11 annonces matchent C++ et 18 matchent Java.
Voilà déjà deux exemples assez intéressant : je persiste à dire que c'est du grand n'importe quoi de dire que Java n'a jamais percé dans le domaine du développement logiciel. Dans le développement logiciel actuellement, bien sûr : il reste de nombreuses applications en Cobol, Fortran et compagnie fossilisées sur leur slowlaris mais on s'en tappe on ne parle pas de ça.-
[^]Re: C'est un troll.
Posté par Strass (page perso, ) le 16/07/2004 à 15:02. (lien). Évalué à 7.Je pense que ce que l'auteur de l'article voulait soulever, c'est que Java n'a pas vraiment révolutionné le développement d'application pour le Desktop, mais qu'avec .Net on a un bon outil de dev pour application Desktop.
Par contre, je suis tout à fait d'accord avec toi pour dire que l'article insiste bcp sur la simplicité de développement en utilisant comme exemple qqch qui existe déjà dans les bibliothèques de Mono. C'est-à-dire que si je décide par exemple de développer un éditeur de vidéo, Mono ne rendra pas le développement plus simple s'il n'y a pas de base des bibliothèques servant à manipuler et découper des vidéos.
-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 16/07/2004 à 15:03. (lien). Évalué à 5.le domaine du développement logiciel
Je crois que ce que voulais dire l'auteur de l'article (pourri) de Arstechnica est que Java n'a jamais vraiment pris pour faire des applications desktop, ce qui n'est pas complètement faux, mais ce qui néglige aussi le fait que beaucoup d'applications spécifiques (du genre la gestion de l'inventaire dans une boite lambda) sont maintenant développées un modèle de client léger, domaine dans lequel Java excelle.
Ceci dit, je suis d'accord avec toi, l'article de Arstechnica est pourri et l'interview de De Icaza est grotesque. C'est encroyable combien le Java bashing fait recette dans le monde linux. Et dire que Sun ne comprend toujours pas qu'il faut open sourcer Java, ça devient pathétique.
-
[^]Re: C'est un troll.
Posté par lezardbreton (Jabber id, page perso, ) le 16/07/2004 à 16:09. (lien). Évalué à 2.Bien sûr, il s'agit seulement d'un exemple d'entreprise. Mais comme très bien résumé un peu en dessous, java s'est surtout démarqué sur des plateformes serveurs pour le moment. Cela n'enlève rien aux qualités du langage, et je suis sûr que des personnes vont me fournir des statistiques complètement différentes suivant leur entreprise.
Mais est ce que cela te choque si je te dis que je pense avoir près de la moitié des applications développées en Visual Basic, et une bonne partie en C/C++ ?
PS: en aucun cas je n'ai dit que java n'est pas prêt pour le desktop, je n'y connais rien en développement, et j'ai répondu bash comme langage de programmation préféré pour le sondage "Linux Journal's 2004 Readers' Choice" :)
PS2: qu'est ce que ça excite les gens cette histoire de java/Mono... Ca m'impressionera toujours !-
[^]Re: C'est un troll.
Posté par gc (page perso, ) le 16/07/2004 à 16:16. (lien). Évalué à 2.Je n'affirme pas que Java soit prêt pour le desktop et suite au premier commentaire dans la veine de ce que tu dis, un peu plus bas, j'ai acquiescé et effectivement, si c'était ce que l'auteur voulait dire, je suis prêt à y souscrire : je suis d'accord que Java est probablement essentiellement utilisé pour des servlets (et applets).
-
-
[^]Re: C'est un troll.
Posté par syj () le 16/07/2004 à 16:43. (lien). Évalué à 4.Je n'avais jamais essayé de faire de ce type de recherche avec Google. J'ai toujours pensé à utiliser Monster.fr pour faire ces comparaisons.
mais depuis que j'ai trouvé ce site, je trouve que çà va plus vite ;-)
http://mshiltonj.com/sm/categories/languages/(...)
Fait attention C# est la même couleur que sql, et c'est la courbe de Sql qui se trouve au-dessus de Java
Par contre, si tu regarde les courbes sur les technologies, le resultat est faut car la requête qui récupère les annonces .Net récupère des annonce qui n'ont rien à voir avec les techno de Microsoft probablement les URL en .net. Il explique çà dans son blogue-
[^]Re: C'est un troll.
Posté par Erwan (page perso, ) le 17/07/2004 à 01:59. (lien). Évalué à 3.Comparer SQL avec des langages de programmation, c'est quand meme tres con.
-
-
-
[^]Re: C'est un troll.
Posté par jcs (page perso, ) le 16/07/2004 à 15:01. (lien). Évalué à 10.Effectivement, cette phrase peut choquer les afficionados de java.
Non, je ne pense pas. Les afficionados sont bien conscients que Java s'il est omniprésent côté serveur, il est presque complètement abscent côté client. ll n'y a qu'à regarder les offres d'emplois pour s'en rendre compte : quand il est question de java c'est toujours Tomcat, EJB, Servlets et compagnie.
La raison de ce déséquilibre ? Même s'il existait des problèmes de performance au début, je pense qu'une grande partie en revient à Microsoft et ses facéties au sujet de la JVM qu'il distribuait, telles que les problèmes d'interopérabilité. Par contre sur d'autres terres vierges comme les téléphones portables, Java, côté client cette fois, se taille la part du lion, au point même d'en faire un argument commercial, les fameux jeux Java sur les derniers modèles.-
[^]Re: C'est un troll.
Posté par gc (page perso, ) le 16/07/2004 à 15:04. (lien). Évalué à 2.Hum, ceci est un argument intéressant, effectivement dans ce sens-là ça devient tout de suite assez crédible... merci de tes lumières :)
-
[^]Re: C'est un troll.
Posté par reno () le 16/07/2004 à 18:25. (lien). Évalué à 5.Moi ce que je trouve bizarre, c'est qu'on est passé de Java n'est pas utilisé pour développer des applications (ce qui est faux) à Java n'est pas utilisé pour développer des applications graphiques/clientes, ce qui est globalement vrai.
Dans l'article, ou il parle juste d'application sans précision, il dit une bétise point.
Ce qui globalement correspond à la (piètre) qualité de l'article..
Pour information, je ne suis pas du tout un fan de Java, j'ai essayé d'utiliser Swing en 99, c'était une catastrophe: buggé jusqu'a la moelle, avec Sun mettant des *années* pour corriger des bugs tres genant et tres voté dans la bugparade (et ce n'est pas une exagération malheureusement :-( )..
Maintenant pour ce qui est de .Net ou Mono, je laisse le soin aux autres d'essuyer les plâtres. Dans les deux cas, a mon avis, c'est trop tôt, dans 3-4 ans, pourquoi pas d'ils murissent bien..
-
[^]Re: C'est un troll.
Posté par Croconux () le 17/07/2004 à 09:49. (lien). Évalué à 10.La raison de ce déséquilibre ?
Swing. C'est vrai, si SWT était apparu plus tôt à mon avis, java aurais beaucoup plus insipré les développeurs d'application de bureau. Mais Sun voulait à tout prix rester 100% indépendant de la plateforme. Les appels à du code natif sont fortement découragés (d'ailleurs c'est imbitable). Depuis le début Sun décourage tout ce qui est natif (compilation ahead of time, lib native). Ils avaient très peur de Microsoft et du fait que tout le monde se mette à coder en utilisant des libs natives trop liées à windows.
C'est justement la force de .NET: Toutes les APIs sont dispo directement. Il n'y a pas une appli .NET sur 20 qui puisse tourner sur autre chose que windows. Il n'y a pas longtemps dans un article de ZDnet un journaliste déblatérait encore des conneries sur le fait que mono allait permettre de faire tourner des appli windows sous linux, office, les jeux... Mouais...
Un programme qui commence par "using Microsoft.DirectX" ou "using Microsoft.Office" ça ne tournera jamais allieurs que sous windows (et la bonne version encore). Il faut prendre .NET pour ce que c'est : Un environnement pour développer des appli windows.
-
-
[^]Re: C'est un troll.
Posté par capicapio () le 16/07/2004 à 16:27. (lien). Évalué à 2."Le catalogue des applications logicielles pour Windows contient 2143 logiciels différents. Parmi ceux-ci, 56 ont une machine virtuelle java comme pré-requis, soit 2.61%. Il existe aussi 5 applications ayant comme pré-requis le framework .Net, soit 0.23% du parc."
Et windows représente quel pourcentage du parc?-
[^]Re: C'est un troll.
Posté par lezardbreton (Jabber id, page perso, ) le 16/07/2004 à 16:32. (lien). Évalué à 3.100%, c'est triste, hein ?
-
-
-
[^]Re: C'est un troll.
Posté par vrm (page perso, ) le 16/07/2004 à 15:04. (lien). Évalué à 3.l'autoboxing en java existe dans la bêta du JDK 1.5. Exemple :
public void autoBoxing() { int a = 12; Integer b = a; int c = b; }-
[^]Re: C'est un troll.
Posté par gc (page perso, ) le 16/07/2004 à 15:11. (lien). Évalué à 2.Est-ce que par hasard tu aurais la moindre idée de pourquoi ça n'a pas été fait dès le début ? ça me semble totalement stupide, mais il doit quand même y avoir une raison (j'espère). Genre, on s'en tappe d'avoir deux types de données du point de vue du programmeur (à moins d'avoir un problème de chemin critique), il faut juste que le compilateur insère le code de conversion au bon endroit.
-
[^]Re: C'est un troll.
Posté par Pierre Tramo (page perso, ) le 16/07/2004 à 22:13. (lien). Évalué à 1.pourquoi ça n'a pas été fait dès le début ?
Probablement parce que les concepteurs de Java sont des gros feignants.
Déjà que la justification pour ne pas avoir d'héritage multiple c'est "ben on avait pas le courage, et pis bon, avec les interfaces on limite la casse"...-
[^]Re: C'est un troll.
Posté par Croconux () le 17/07/2004 à 09:54. (lien). Évalué à 3.Déjà que la justification pour ne pas avoir d'héritage multiple c'est "ben on avait pas le courage, et pis bon, avec les interfaces on limite la casse"...
Ce n'est pas celle que donne James Gosling. Au moment de la conception de java il est allé voir dans les universités comment les profs enseignaient le concept d'héritage multiple pour savoir comment le traiter dans java. A sa surprise la plupart des profs lui ont dit qu'il ne l'enseignait pas ou ne faisait que le survoler. La raison : Ca apporte autant de problème que ça n'en résout. Et puis il me semble qu'au début vu comment les compilateurs C++ l'implémentaient de façon assez sportive et pas standardisée.-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 17/07/2004 à 13:19. (lien). Évalué à 3.Disons que c'est la légende qu'aime répéter Gosling. Il faut arrêter de voir C++ comme le seul exemple de langage orienté objet antérieur à Java. Eiffel proposait avant Java de l'héritage multiple et sans aucun des aspects gores du C++. Si Gosling a fait certains choix dans Java, c'est aussi parce qu'il n'a justement par considéré de façon assez complète ce qui se faisait dans la recherche et dans certaines niches industrielles. Bon, on est loin du C++ qui est à mon avis l'exemple même du langage construit de bric et de broc sans aucune interaction avec les "gens qui savent", mais Java reste quand même bancal sur certains points (et certains sont d'ailleurs corrigés par C#).
-
[^]Re: C'est un troll.
Posté par Guillaume Laurent (page perso, ) le 17/07/2004 à 17:11. (lien). Évalué à 3.Bon, on est loin du C++ qui est à mon avis l'exemple même du langage construit de bric et de broc sans aucune interaction avec les "gens qui savent"
Ça dépend qui tu entends par "gens qui savent". Si tu parles des théoriciens des langages, c'est partiellement vrai (Stroustrup est avant tout un pragmatique). Si tu parles des gens qui utilisent les langages pour développer avec, c'est complètement faux (c'est même bien pour ça que C++ est devenu aussi complexe : chaque feature est là parce que quelqu'un l'utilise.-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 18/07/2004 à 06:48. (lien). Évalué à 2.J'entends par "gens qui savent" les théoriciens des langages et du génie logiciel. Stroustrup n'a pas eu une interaction suffisante avec les universitaires et n'a donc pas utilisé l'expérience d'Eiffel et d'autres langages (genre Oberon, etc.).
Je suis d'accord avec toi, Stroustrup est partisant du "more is more" et effectivement chaque feature du C++ est utilisée et c'est bien le problème. Disons que "less is more" me convient plus, mais vu le succès de Perl et de C++, je suppose que pour beaucoup de gens, "more is more"...
Nous avons d'ailleurs déjà eu cette discussion un certain nombre de fois et nous ne serons jamais d'accord, je suppose.-
[^]Re: C'est un troll.
Posté par Guillaume Laurent (page perso, ) le 18/07/2004 à 08:38. (lien). Évalué à 2.> Stroustrup n'a pas eu une interaction suffisante avec les universitaires et n'a donc pas utilisé l'expérience d'Eiffel et d'autres langages
Pour avoir feuilleté "The Design and Evolution of C++", il me semble que tu te trompes.
> Stroustrup est partisant du "more is more" et effectivement chaque feature du C++ est utilisée et c'est bien le problème.
Ben oui mais a un moment il faut bien que ton langage serve à quelque chose :-). Et si tu prends le contre-exemple de Java, tu vois que très rapidement on a cherché à y ajouter des choses comme les templates ou même l'overloading d'operateur. Et même C#, qui a pourtant ajouté un certain nombre de choses à Java dès le départ, se retrouve contraint d'en ajouter encore.
> Nous avons d'ailleurs déjà eu cette discussion un certain nombre de fois et nous ne serons jamais d'accord, je suppose.
Sans doute. :-)-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 18/07/2004 à 10:17. (lien). Évalué à 3.Pour avoir feuilleté "The Design and Evolution of C++", il me semble que tu te trompes.
Il y a de la marge entre ce que dit Stroustrup et le résultat de sa reflexion. Pour avoir lu des articles théoriques sur Caml et ses dérivées, je comprends parfaitement que Stroustrup ait pu être rebuté par la théorie des langages de programmation et ait préfére faire l'ingénieur. Mais le résultat est ce qu'il est, mauvais sur de nombreux points. Il est vrai qu'Eiffel n'était pas un modèle d'efficacité, ni d'ailleurs smalltalk, par exemple, donc Stroustrup a pu être échaudé par ces expériences (commetant l'erreur habituelle qui est de confondre design et implémentation). Maintenant, l'exemple du virtual me semble emblématique du design raté. Sous pretexte de faciliter l'interfaçage avec le C, Stroustrup casse le modèle objet expérimenté par toute la communauté de l'orienté objet. Pour qu'un objet fonctionne (c'est-à-dire que le polymorphisme marche), il faut maintenant déclarer ses méthodes "virtuel", sinon il s'agit d'une struct à laquelle on ajoute des méthodes. L'exemple même de l'optimisation à l'envers. Plutôt que d'étendre la sémantique de struct en permettant d'insérer des méthodes ou encore de choisir un mot clé particulier pour ces "objets" qui n'en sont pas, Stroustrup préfère casser le cas général tout ça pour soit disant faciliter la récupération du C (alors que cela aurait marché très bien avec les autres solutions). Je ne peux pas prouver qu'on savait faire ça à l'époque, mais c'est tellement trivial pour quelqu'un qui s'intéresse aux langages de programmation que ça me semble évident.
De même beaucoup plus tard pour les templates qui sont à la fois trop puissants (il a fallu attendre si longtemps avant d'avoir des compilateurs qui marchent) et pas assez (les contraintes sur les types sont implicites, ce qui retarde la vérification de la validité du code). Encore une fois, l'expérience des autres langages aurait permis d'éviter ça. Soit, on n'aurait pas eu les expressions templates, mais franchement, j'ai des doutes sur leur intérêt réel.
Et si tu prends le contre-exemple de Java, tu vois que très rapidement on a cherché à y ajouter des choses comme les templates ou même l'overloading d'operateur.
Ok pour les templates (le résultat est d'ailleurs pourri si tu veux mon avis), mais pas pour les opérateurs. Ils ne sont pas surchargeables en Java et ça risque de durer. Sur le fond, je fini par être d'accord. Oui, ça permet d'écrire du code numérique lisible et avec les expressions templates du C++, ça permet même de faire du code relativement efficace. Cependant, j'ai lu pas mal de papier de numériciens et je suis maintenant convaincu par leur argumentation : si on veut faire proprement et efficacement du calcul numérique, il faut déléguer au compilateur. Il faut donc que les nombres complexes, les vecteurs et les matrices soient intégrés au langage et que le compilateur se démerde pour optimiser le code. Ca veut dire qu'il doit pouvoir appeler des bibliothèques comme Atlas. On en est loin, mais j'avoue que je ne vois pas comment faire autrement. Et si on enlève le code numérique, la surcharge d'opérateurs ça ne sert franchement à rien.
Et même C#, qui a pourtant ajouté un certain nombre de choses à Java dès le départ, se retrouve contraint d'en ajouter encore.
Oui et non. Si j'ai bien compris (je peux me tromper) les generics de C# ont été retardés pour la version 2 car les équipes de Microsoft research bossaient encore dessus. Il s'agit d'équipe de chercheurs en théorie des langages et franchement, le résultat est vraiment impressionnant (j'ai honte d'admirer une production de MS, mais bon). Soit, on a du more is more ici, mais fait proprement. Sinon, oui C# a ajouté des choses à Java, peut être un peu trop comme les opérateurs, mais aussi dans la bonne direction comme les structs. Mais surtout, en s'appuyant sur des équipes de recherche pour certaines features...-
[^]Re: C'est un troll.
Posté par Guillaume Laurent (page perso, ) le 18/07/2004 à 11:51. (lien). Évalué à 3.commetant l'erreur habituelle qui est de confondre design et implémentation
Oui, ça c'est ce que les architectes disent pour se défendre quand le marketing vient leur dire "ça rame" : "c'est pas not' faute, c'est les ingé qu'on mal implémenté notre beau design". Non, j'ai trop vécu ce cas pour avaler ce genre d'excuse : un design peut être intrinsèquement lent, quelque soit l'implémentation. C'est pas pour rien que toutes les methodologies de prog actuelles (extreme programming en tete) sont sous forme de cycle ou le design est revu avec l'expérience de l'implementation.
Maintenant, l'exemple du virtual me semble emblématique du design raté. Sous pretexte de faciliter l'interfaçage avec le C
Effectivement, on a déjà eu cette discussion. Bon, je continue de penser que Stroustrup a fait un langage utilisable en pratique, avec des avantages concrets sur les concurrents, plutôt qu'un bel objet de laboratoire, et qu'il a eu raison de le faire. Je ne crois pas aux "erreurs" de l'industrie, si un machin a du succès, c'est le plus souvent pour de bonnes raisons, les pressions marketing et les "décideurs pressés" ne font pas tout. Au final, il a fait un langage qui s'interface avec C de façon triviale, et relativement facile à implementer. Sans ça, C++ n'aurait jamais marché.
si on veut faire proprement et efficacement du calcul numérique, il faut déléguer au compilateur. Il faut donc que les nombres complexes, les vecteurs et les matrices soient intégrés au langage et que le compilateur se démerde pour optimiser le code
Je veux bien, mais alors bonjours le tas de feature en plus à flanquer dans la spec. Et donc tu te retrouves soit avec un langage hyper-specialisé qui ne fait que du calcul numérique et rien d'autres (donc prévoir moyens pour l'interfacer avec autre chose pour faire des vrais softs utiles, avec GUI & co...), soit un langage encore plus énorme que C++ :-). "Less is more" ?
Si j'ai bien compris (je peux me tromper) les generics de C# ont été retardés pour la version 2 car les équipes de Microsoft research bossaient encore dessus.
C'est exact, ils ont préféré attendre d'avoir une bonne implémentation du concept. Encore un point ou Hejlsberg m'impressionne plus que Gosling.
mais aussi dans la bonne direction comme les structs
Entièrement d'accord, je ne vois pas d'autre issue que d'avoir 2 modèles objets dans un langage : un "leger" (structs) ou tu peux creer tout les objets que tu veux sans trop de soucis de perfs, et un plus lourd et complet (class), avec toutes les features bien sympa qu'on aime avoir (introspection, etc...).-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 18/07/2004 à 13:44. (lien). Évalué à 2.Oui, ça c'est ce que les architectes disent pour se défendre quand le marketing vient leur dire "ça rame" : "c'est pas not' faute, c'est les ingé qu'on mal implémenté notre beau design". Non, j'ai trop vécu ce cas pour avaler ce genre d'excuse : un design peut être intrinsèquement lent, quelque soit l'implémentation. C'est pas pour rien que toutes les methodologies de prog actuelles (extreme programming en tete) sont sous forme de cycle ou le design est revu avec l'expérience de l'implementation.
Ok, nous sommes d'accord sur le principe, j'aurais donc du ajouter des exemples pour illustrer mon propos. Le cas de Java qui est emblématique. Les premières JVM étaient d'une lenteur délirante, à tel point que pour certains Java est intrinsèquement lent, seulement interprété, etc. En fait, le design de Java contient des erreurs, en particulier l'absence de struct qui fait qu'on se retrouve avec une énorme consommation mémoire. Mais les JVM modernes sont très rapides et dans certaines situations on peut même faire mieux que du C ou du C++ en Java. Il n'y a rien intrinsèquement en Java qui rend le langage lent. C'est la même chose pour Eiffel par exemple dont les premiers compilateurs étaient tellement lents que le langage était presque inutilisable (idem pour Ada, d'ailleurs). Des progrès énormes ont été réalisés et on constate maintenant que le design d'Eiffel ou d'Ada est bien meilleur que celui de C++.
Tiens, je termine pas un exemple concret. Il a une grosse couille de conception dans Java, c'est le lock par objet qui est soit disant plus objet que l'utilisation de mutex. Enfin, disons plutôt que je pensais qu'il y avait une couille de conception. Bon, je n'aime pas, mais surtout j'étais persuadé qu'on était obligé d'avoir un mot par objet au minimum pour gérer ce lock, soit une perte de 4 octets sur nos architectures 32 bits. Encore de la mémoire gâchée... Sauf que les concepteurs de SableVM ont trouvé un moyen de virer ce mot et d'éviter la perte mémoire.
Il a un phénomène du même genre en Eiffel, avec un truc ultra-puissant découvert par les chercheurs qui implémentent smalleiffel. Je ne me rappelle plus des détails, mais en gros ça permet de garder un modèle objet cohérent tout en se débarassant de la "table des méthodes virtuelles".
Je ne crois pas aux "erreurs" de l'industrie, si un machin a du succès, c'est le plus souvent pour de bonnes raisons, les pressions marketing et les "décideurs pressés" ne font pas tout.
Terrain glissant ! VHS contre Betacam, USB 1 contre Firewire, Unix contre Windows, etc. L'industrie ne fait que des erreurs ou presque, mais heureusement, ça change car l'information circule bien mieux. J'en veux pour preuve l'adoption de ogg dans de plus en plus de players.
Au final, il a fait un langage qui s'interface avec C de façon triviale, et relativement facile à implementer. Sans ça, C++ n'aurait jamais marché.
D'un côté je suis d'accord (interface triviale avec le C) et j'ajouterais même courbe d'apprentissage rapide pour un développeur C. Mais d'un autre, tout ça n'est vrai que pour les vieilles versions du C++. Parce qu'avec l'arrivée des templates, ça a été le délire. Il a fallu littéralement une décénie pour avoir des compilateurs décents...
Je veux bien, mais alors bonjours le tas de feature en plus à flanquer dans la spec. Et donc tu te retrouves soit avec un langage hyper-specialisé qui ne fait que du calcul numérique et rien d'autres (donc prévoir moyens pour l'interfacer avec autre chose pour faire des vrais softs utiles, avec GUI & co...), soit un langage encore plus énorme que C++ :-). "Less is more" ?
Salaud, tu m'as coincé et tu en profites ;-) Je n'irais pas jusqu'à dire qu'on obtient plus gros que du C++, mais bon tu as raisons. Excepté une spec modulaire, j'avoue que je ne vois pas trop comment faire.
C'est exact, ils ont préféré attendre d'avoir une bonne implémentation du concept. Encore un point ou Hejlsberg m'impressionne plus que Gosling.
Ouaip. Le pire, c'est que la solution retenue pour les generics de Java existe depuis au moins 5 ou 6 ans, avec des prototypes qui marchent, etc. Alors attendre tout ce temps pour une solution moyenne, c'est vraiment nul.
Entièrement d'accord, je ne vois pas d'autre issue que d'avoir 2 modèles objets dans un langage : un "leger" (structs) ou tu peux creer tout les objets que tu veux sans trop de soucis de perfs, et un plus lourd et complet (class), avec toutes les features bien sympa qu'on aime avoir (introspection, etc...).
Ba oui, je crois qu'on est obligé. Mais Eiffel et Sather le savent depuis plus de dix ans...-
[^]Re: C'est un troll.
Posté par Bière Drabo () le 18/07/2004 à 13:56. (lien). Évalué à 0.> Mais les JVM modernes sont très rapides et dans certaines situations on peut même faire mieux que du C ou du C++ en Java.
- les JVM propriétaires de Sun uniquement
- uniquement sur des cas d'écoles ou spécialement préparés : on ne peut pas en même temps arguer de la simplicité de Java par rapport à C++ et de cette supériorité en vitesse car il faut être un spécialiste Java pour y arriver, avoir une expérience aussi grande que ce que nécessite l'apprentissage de C++.
Le seul véritable argument (valable aussi pour Python, etc.) est que la plupart du temps le code sera exécuté à une vitesse bien suffisante. C'est au cas par cas, ensuite, que l'on s'intéresse aux portions critiques.
Le problème de Java n'est pas la vitesse, mais tu n'utilises pas le bon argument.
> Parce qu'avec l'arrivée des templates, ça a été le délire. Il a fallu littéralement une décénie pour avoir des compilateurs décents...
Il en a fallu autant à Java pour avoir des génériques. Il ne faut pas oublier aussi que C99 a retardé le travail sur C++98 chez beaucoup d'implémenteurs.-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 18/07/2004 à 15:48. (lien). Évalué à 2.Mon propos n'est pas de dire que Java est en tout point supérieur à C++ mais simplement d'illustrer par divers exemples que la conception et l'implémentation sont des choses différentes. Tu es donc vastement hors sujet, mais ça n'a pas l'air de te gêner.
-
[^]Re: C'est un troll.
Posté par Bière Drabo () le 19/07/2004 à 15:56. (lien). Évalué à 1.Je ne dis pas que c'est ton propos.
> illustrer par divers exemples que la conception et l'implémentation sont des choses différentes.
Justement c'est ce que tu as du mal à comprendre.
-
-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 18/07/2004 à 16:03. (lien). Évalué à 2.Il en a fallu autant à Java pour avoir des génériques. Il ne faut pas oublier aussi que C99 a retardé le travail sur C++98 chez beaucoup d'implémenteurs.
Oups, j'avais oublié ça. Je te l'apprends peut être, mais gcc supportait déjà les templates vers 1994, mais de façon très bugguée. Dire que C99 a retardé le travail de normalisation est une vaste blague. De plus, la notion de generique ou de template pré-date le C++ (ça date des langages de la famille ML) et c'est bien la complexité du modèle retenu en C++ qui a rendu son implémentation difficile.-
[^]Re: C'est un troll.
Posté par Bière Drabo () le 19/07/2004 à 15:56. (lien). Évalué à 1.> Je te l'apprends peut être, mais gcc supportait déjà les templates vers 1994, mais de façon très bugguée.
Tu ne me l'apprends pas mais ça ne présente aucun intérêt.
> Dire que C99 a retardé le travail de normalisation est une vaste blague.
Ah mais je veux bien qu'on me contredise, mais ce qui est rigolo c'est que tu n'emploies que des arguments foireux pour démontrer ce point. Intéressant.
> De plus, la notion de generique ou de template pré-date le C++ (ça date des langages de la famille ML) et c'est bien la complexité du modèle retenu en C++ qui a rendu son implémentation difficile.
Personne ne dit qu'elle est simple, mais beaucoup de choses semblent confuses dans ta tête. Ce que tu dis là par exemple n'a aucun intérêt vis à vis de ce que je disais.
-
-
[^]Re: C'est un troll.
Posté par Nicolas Delsaux (page perso, ) le 20/07/2004 à 08:24. (lien). Évalué à 2.- les JVM propriétaires de Sun uniquement
Pas seulement. Le seul problème est qu'en Java, les plus mauvaises JVM sont Open-source; Mais si tu prends celle de BEA, par exemple, elle déchire pour toutes les applications serveur (quand je dis elle déchire, je veux dire qu'elle est vraiment plus rapide que celle de Sun, et également gratuite).
- uniquement sur des cas d'écoles ou spécialement préparés : on ne peut pas en même temps arguer de la simplicité de Java par rapport à C++ et de cette supériorité en vitesse car il faut être un spécialiste Java pour y arriver, avoir une expérience aussi grande que ce que nécessite l'apprentissage de C++.
Je ne suis pas d'accord.
L'avantage de Java dans ce domaine tient à la qualité des librairies proposées, qui permettent souvent, pour les tâches communes, de disposer des meilleures implémentations existantes. Ca rend les programmes Java facilement aussi rapides que leurs concurrents C++-
[^]Re: C'est un troll.
Posté par Bière Drabo () le 20/07/2004 à 11:55. (lien). Évalué à 1.> Pas seulement. Le seul problème est qu'en Java, les plus mauvaises JVM sont Open-source; Mais si tu prends celle de BEA, par exemple, elle déchire pour toutes les applications serveur (quand je dis elle déchire, je veux dire qu'elle est vraiment plus rapide que celle de Sun, et également gratuite).
Ok tu fais bien de me corriger, c'est au fait que les plus mauvaises soient open source que je pensais, c'est vraiment un inconvénient.
> L'avantage de Java dans ce domaine tient à la qualité des librairies proposées, qui permettent souvent, pour les tâches communes, de disposer des meilleures implémentations existantes. Ca rend les programmes Java facilement aussi rapides que leurs concurrents C++
Je ne dis pas que ça ne peut pas l'être mais qu'il faut savoir quelle est la bonne bibliothèque à utiliser, par exemple. Je pense à des cas où l'emploi d'une bibliothèque était efficace, et l'emploi d'une autre, en apparence similaire (en fait, similaire pour le néophyte) l'était beaucoup moins. Tout ceci à disparu de Java, ou bien les bibliothèques proposées dans la dernière version ne présentent plus cet inconvénient ?
-
-
-
[^]Re: C'est un troll.
Posté par Philip Marlowe (Jabber id, ) le 18/07/2004 à 20:40. (lien). Évalué à 1.Il a un phénomène du même genre en Eiffel, avec un truc ultra-puissant découvert par les chercheurs qui implémentent smalleiffel. Je ne me rappelle plus des détails, mais en gros ça permet de garder un modèle objet cohérent tout en se débarassant de la "table des méthodes virtuelles".
As-tu quelque lien à ce sujet ? Parce qu'entre deux releases, on ne peut pas dire que l'équipe de SmartEiffel abuse de la communication... Je suis utilisateur d'Eiffel pour mon travail et les progrès de SmartEiffel m'intéressent beaucoup (en gestation : un IDE, l'implémentation de la concurrence selon SCOOP), mais les dernières infos de leur site dataient de juin 2003. Dataient, SmartEiffel 2.0 beta #1 est sur le site depuis le 16 jullet, je viens de m'en rendre compte.
Ceci dit, l'information à leur sujet n'est pas pléthorique, alors y a-t-il des sites que je ne connais pas, ou les connais-tu personnellement ?-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 19/07/2004 à 07:51. (lien). Évalué à 2.Dans la partie papier de leur site (http://smarteiffel.loria.fr/papers/papers.html(...)), tu trouveras des choses intéressantes. Mais bon, effectivement, la communication n'est pas hyper forte...
-
-
-
-
[^]Re: C'est un troll.
Posté par Bière Drabo () le 18/07/2004 à 12:10. (lien). Évalué à 0.J'ai vu bien des gens compétents critiquer constructivement C++, et Stroustrup ne serait pas le dernier de ceux-là d'après ce que j'ai vu de son attitude. Mais le coup du virtual ça non, c'est d'un ridicule ! C'est une simple définition dans le langage et le comportement souhaité est trivialement obtenu. Et le pire c'est que tu ne cesses de te contredire : tantôt c'est pour la compatibilité C tantôt ça n'est pas nécessaire pour la compatibilité C. Mais sais-tu au moins de quoi tu parles ? Si oui tu as du mal à l'expliquer clairement. As-tu lu le D&E ou toutes suppositions sur l'optimisation ne seraient-elles justement que des suppositions ?
Je serais curieux de te voir poster tout ceci sur fclc++, je pense que des gens comme G. Dos Reis (qui travaille justement avec Stroustrup) auraient quelques trucs à t'expliquer, et ça te permettrait de comprendre tes erreurs. On constatera aussi que, curieusement, les professionnels qui sur ce forum maîtrisent plusieurs langages (Java, Ada) ne font pas le même bilan que toi, et font une critique constructive du langage qui n'a rien à voir avec ces puérilités sur virtual.
Les remarques sur la surcharge d'opérateurs sont aussi ridicules : ainsi personne ailleurs qu'en numérique n'utilise de matrices ou de vecteurs ? C'est classique d'une critique faite « dans son petit monde à soi ».-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 18/07/2004 à 14:00. (lien). Évalué à 2.Tout en finesse, comme tes remarques sur PbPg...
Pour le virtual, je t'explique. Dans les langages objets avant C++, la notion d'objet implique celle de polymorphisme. Si B hérite de A, je peux écrire un code qui pense utiliser des A mais lui transmettre des B, tout ce passera bien, les méthodes de B seront appelées. En C++, ceci ne fonctionne que si on ajoute virtual devant les méthodes qu'on veut voir fonctionner correctement. Bien entendu, on peut toujours avoir B qui hérite de A, passer un B à un code qui attend un A et obtenir un comportement débile car les méthodes redéfinies dans B ne sont pas appelées. Cette sémantique est tout simplement pourrie. C'est d'autant plus pourri que ça dépend du mode de passage. Si A est passé par valeur, alors les méthodes de A seront toujours appelées, alors que si A est passé par référence ou pointeur, le polymorphisme fonctionne. Or, un langage doit être prévisible simplement. Un tel comportement est nuisible et ne fait que compliquer la tâche du programmeur sans aucun intérêt pratique.
Dans un langage objet qui fonctionne, toutes les méthodes sont "virtuel" par défaut. Si on a besoin d'interdire la redéfinition, on utilise un mot clé adapté, comme "final" en Java. De cette manière, on ne peut pas se tirer dans le pied en croyant avoir du polymorphisme mais en ayant en fait un truc boiteux. On peut aussi imaginer une solution à la C++ mais qui empêche de se tirer dans le pied, en ayant une seule sémantique (et pas une sémantique qui dépend du mode de passage) et en interdisant la redéfinition des méthodes non virtuel. Personnellement, j'aime moins, mais bon, c'est un choix.
Les arguments des défenseurs de la sémantique débile du C++ sont multiples et plutôt foireux.
Le plus convainquant est celui qui dit que cela facilite l'interfaçage avec du C en ayant des objets sans table des méthodes virtuelles. On peut alors passer leur contenu à des fonctions C sans soucis. On peut aussi "encapsuler" une struct C en un objet C++ en ajoutant des méthodes. Sauf qu'on sait depuis des années comment faire ça proprement : avec des objets "lights" comme dit Guillaume, c'est-à-dire des objets qui sont manipulables par valeur (contrairement aux objets de Java) et qui ne supportent pas l'héritage. Ce sont les structs du C#, mais ça existe depuis longtemps en Eiffel et Sather (et ça manque drôlement en Java).
Le plus pourri est celui qui dit que virtuel permet d'optimiser le code. C'est grotesque. De toute manière, on obtient la même chose avec du final (i.e., la possibilité de virer le passage par la table des méthodes virtuelles et d'inline les méthodes associées si ça vaut le coup). De plus, depuis Eiffel et Sather, on sait que des techniques évoluées permettent de laisser le compilateur faire ça de façon beaucoup plus efficace que le programmeur.
Voilà, voilà, tu vois, je connais un peu le sujet, mais bon, vu ton aggressivité déplacée, je suppose que tu t'en fous.-
[^]Re: C'est un troll.
Posté par Bière Drabo () le 18/07/2004 à 14:23. (lien). Évalué à 0.> Tout en finesse, comme tes remarques sur PbPg...
> Pour le virtual, je t'explique.
Alors là c'est toi qui est gonflé ! Pourquoi rappeler tout ceci alors que je le sais pertinemment, je ne n'aurais pas parlé sur ce sujet sinon ? N'importe quel programmeur C++ doit savoir ça, c'est la base pour la partie objet. Le fait est que si tu veux que tous tes objets aient le comportement que tu attends, dès le départ tu dis dans ton projet « toutes les fonctions membres seront virtuelles », et c'est fini. Aucune difficulté. Seulement ce qui ne te plait pas c'est que le comportement qui te sert le plus nécessite un mot clé. C'est du délit de sale gueule, il n'y a pas d'autre argument "contre".
> Dans un langage objet qui fonctionne, toutes les méthodes sont "virtuel" par défaut. Si on a besoin d'interdire la redéfinition, on utilise un mot clé adapté, comme "final" en Java.
Non. C'est un choix dans la conception du langage, point. De plus C++ n'est pas objet mais propose un support pour la programmation OO, c'est différent. Il n'a pas prétention à être un langage objet. Bref, tu lui donnes des prétentions et tu le critiques dessus, alors je dis que c'est ridicule. Le support OO est présent, point. Si ce n'est pas le langage qui te convient, prends-en un autre plus adapté à ton projet. Mais le simple fait de devoir marquer « virtual » des fonctions n'est certainement pas un élément déterminant pour exclure C++. Tes qualifications de « boiteux » et autre sont totalement subjectives. C++ n'a pas vocation à être simple à apprendre mais puissant à l'utilisation. Il nécessite un investissement plus grand en apprentissage, mais c'est payant au bout du compte. L'apprendre à la légère n'est pas une option, mieux vaut utiliser un langage plus simple à apprendre.
> Le plus convainquant est celui qui dit que cela facilite l'interfaçage avec du C en ayant des objets sans table des méthodes virtuelles.
Je ne sais pas si ça nécessite un argument, mais ce serait bien que tu cites ceux qui ont réellement été pris en compte et pas ceux que tu as pu lire ici ou là. Des fanatiques du C++ ont pu te sortir n'importe quel mauvais argument, moi ce qui m'intéresse serait le raisonnement de Stroustrup et du comité. Pour ma part, c'est juste un choix du langage et j'utilise la syntaxe qui va bien en fonction de ce que je veux faire.
> On peut alors passer leur contenu à des fonctions C sans soucis. On peut aussi "encapsuler" une struct C en un objet C++ en ajoutant des méthodes. Sauf qu'on sait depuis des années comment faire ça proprement : avec des objets "lights" comme dit Guillaume, c'est-à-dire des objets qui sont manipulables par valeur (contrairement aux objets de Java) et qui ne supportent pas l'héritage.
Mais tout ça ce sont des questions de conception justement. Tu dois savoir si tu utilises tes objets avec une sémantique de valeur ou d'identité, tu les définis en fonction de ça, et pour ça tu utilises le langage. C++ n'impose pas une seule sémantique contrairement à Java, donc tu as plus de choix, plus d'efforts à faire sur la conception et sa transposition en code.
> Voilà, voilà, tu vois, je connais un peu le sujet, mais bon, vu ton aggressivité déplacée, je suppose que tu t'en fous.
Non, mais ce qui ne m'intéresse pas, c'est des arguments contre des arguments qui ne m'intéressent pas. Si tu vois passer des arguments pipeau pour virtual, ça ne m'intéresse pas de voir ce que tu dis contre eux, parce que moi-même ils ne m'ont pas convaincu. J'aurais d'ailleurs préféré que C++ ait le comportement que tu dis ! Seulement ce n'est vraiment pas bien grave, la solution est tellement triviale (déclarer correctement) que c'est tout sauf un argument contre C++ : C++ a bien d'autres problèmes qui font qu'on préférera d'autres langages à celui-ci, mais le "virtual" comme problème insoluble n'est vraiment pas sérieux. Si tu veux faire de l'objet à la Java en C++, tous tes objets ont des fonctions membre virtuels et tu les utilises avec une sémantique d'identité, autant que possible avec des références, sinon des pointeurs, et jamais directement. Je ne dis pas que l'apprentissage nécessaire pour bien s'en servir est comparable à Java ou autre sur ce point là.
Je vois que tu n'as pas cité de références vers les arguments officiels qui ont mené à la syntaxe avec virtual. Un discours constructif aurait commencé par ça, il me semble.-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 18/07/2004 à 16:14. (lien). Évalué à 2.Je vois que tu n'as pas cité de références vers les arguments officiels qui ont mené à la syntaxe avec virtual. Un discours constructif aurait commencé par ça, il me semble.
Il me semble avoir lu les deux arguments débiles que j'évoque sous la plume de Stroustrup, mais comme je n'en suis pas certain, j'ai préféré ne rien dire. Sur son site on trouve le même genre d'arguments débiles du genre "toutes classes ne sont pas destinées à devenir des classes de base", ce qui signifie dans le contexte des classes dont on peut dériver d'autres classes. Et surtout un argument sur la table des méthodes virtuelles qui prend de la place. Les deux "problèmes" sont réglés par des objets lightweights, ce qui évite les problèmes de sémantique variable selon le mode de passage et ce qui rend donc le langage plus clair. De plus, la table des méthode virtuelles peut être supprimée automatiquement par un compilateur intelligent dans un langage sans pointeur.
Ceci étant, merci pour le fou rire que tu as provoqué en parlant de discours constructif, venant de toi, c'était vraiment puissant.-
[^]Re: C'est un troll.
Posté par Bière Drabo () le 19/07/2004 à 16:00. (lien). Évalué à 1.J'espère que tu travailles activement à l'évolution du C++ car si les solutions sont si triviales que tu le dis, personne ne t'arrives à la cheville, bravo !
> Ceci étant, merci pour le fou rire que tu as provoqué en parlant de discours constructif, venant de toi, c'était vraiment puissant.
Je réponds quand c'est nécessaire, et je n'en fais pas plus que nécessaire en réponse aux trolls dans ton genre. C++ a des défauts mais toi tu ne ressors que les vieux trolls et arguments ridiculisés depuis longtemps.
-
-
-
[^]Re: C'est un troll.
Posté par Bière Drabo () le 18/07/2004 à 15:22. (lien). Évalué à 1.> je connais un peu le sujet
J'en doute quand je lis « Cette sémantique est tout simplement pourrie. C'est d'autant plus pourri que ça dépend du mode de passage. Si A est passé par valeur, alors les méthodes de A seront toujours appelées, alors que si A est passé par référence ou pointeur, le polymorphisme fonctionne. »
Ou je me dis plutôt que tu ne veux pas comprendre pourquoi ça se passe comme ça.
Des langages différents, des objectifs différents, des choix différents. Pourquoi cet intégrisme sur les solutions Java ? Si l'objet répondait à tous les problèmes, C++ aurait été abandonné depuis longtemps.
-
[^]Re: C'est un troll.
Posté par Guillaume Laurent (page perso, ) le 20/07/2004 à 07:11. (lien). Évalué à 4.> Pour le virtual, je t'explique
Au fait, tu as remarqué qu'en C# aussi, les méthodes ne sont pas virtuelles par défaut ? :-)-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 20/07/2004 à 08:10. (lien). Évalué à 3.Au fait, tu as Chroma Medical Systems remarqué qu'en C# aussi, les méthodes ne sont pas virtuelles par défaut ? :-)
Oui et c'est à mon avis l'un des seuls défauts du langage. La sémantique de l'héritage est d'ailleurs assez complexe par rapport à Java et je ne la trouve pas très convainquante. Si tu as un exemple de l'utilité pratique du bousin, je suis preneur.
Par contre, il n'y a pas de changement de sémantique suivant le mode de passage qui rend le C++ inconsistant. Je n'ai d'ailleurs surement pas assez insisté sur ce point : je trouve idiot d'avoir à ajouter virtual, mais c'est surtout une question de goût. Cela pose aussi des problèmes de génie logiciel : le concepteur d'une classe doit explicitement rendre ces méthodes modifiables et doit donc penser aux extensions possibles, ce qui est beaucoup plus dur que de penser aux méthodes qui ne doivent surtout pas être modifiées. Je trouve donc que le final de Java est plus utile, mais je ne me battrais par pour ça.
Ce qui pose vraiment problème en C++ et qui est une erreur de conception à mon avis, c'est que le comportement des méthodes d'un objet dépend du mode de passage de celui-ci. De plus, il n'y a pas de garde fous en C++, alors que c'est le cas en C# (tu ne peux redéfinir une méthode non virtual que si tu le demandes de façon très explicite en ajoutant un new).-
[^]Re: C'est un troll.
Posté par TImaniac (page perso, ) le 20/07/2004 à 08:32. (lien). Évalué à 2.Explication (tiré d'une interview sur artima.com) :
Anders Hejlsberg: There are several reasons. One is performance. We can observe that as people write code in Java, they forget to mark their methods final. Therefore, those methods are virtual. Because they're virtual, they don't perform as well. There's just performance overhead associated with being a virtual method. That's one issue.
A more important issue is versioning. There are two schools of thought about virtual methods. The academic school of thought says, "Everything should be virtual, because I might want to override it someday." The pragmatic school of thought, which comes from building real applications that run in the real world, says, "We've got to be real careful about what we make virtual."
When we make something virtual in a platform, we're making an awful lot of promises about how it evolves in the future. For a non-virtual method, we promise that when you call this method, x and y will happen. When we publish a virtual method in an API, we not only promise that when you call this method, x and y will happen. We also promise that when you override this method, we will call it in this particular sequence with regard to these other ones and the state will be in this and that invariant.
Every time you say virtual in an API, you are creating a call back hook. As an OS or API framework designer, you've got to be real careful about that. You don't want users overriding and hooking at any arbitrary point in an API, because you cannot necessarily make those promises. And people may not fully understand the promises they are making when they make something virtual.-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 20/07/2004 à 09:49. (lien). Évalué à 2.Attention, je ne parle pas de virtual vs final, mais de la sémantique des appels, i.e., le fait que le polymorphisme ne "fonctionne pas" toujours.
Sinon, les explications données ne sont pas très convainquantes :
Anders Hejlsberg: There are several reasons. One is performance. We can observe that as people write code in Java, they forget to mark their methods final. Therefore, those methods are virtual. Because they're virtual, they don't perform as well. There's just performance overhead associated with being a virtual method. That's one issue.
C'est grotesque, mais malheureusement ça a la vie dure. Oui, il y a un léger overhead quand on utilise une méthode virtual. Mais ce n'est surtout pas au programmeur de s'en occuper ! Ca fait des années (7 ans dans le cas de SmallEiffel et 10 dans le cas de Sather), qu'on sait faire des optimisations globales qui permettent de virer les virtual inutiles (ou de rendre final les méthodes concernées, si tu préfères). Non seulement cela permet au programmeur de ne pas se soucier du problème d'efficacité, mais en plus cela permet de faire des optimisations locales. Par exemple dans un morceau de code, on peut virer les virtual et inliner les méthodes concernées, alors que dans un autre boût de code du même programme, on doit garder le late binding. Bref, il est impossible de faire ça à la main. Cf les articles des auteurs de SmallEiffel (http://smarteiffel.loria.fr/papers/papers.html(...)).
Quant à la seconde partie, elle est intéressante, mais je doute qu'on puisse faire de la théorie là dessus. Mon expérience personnelle est qu'en C++, je finaissais par presque tout mettre en virtual, sauf les méthodes pour lesquelles cela aurait pu potentiellement casser le reste du programme.
Mais encore une fois, en fait on s'en fout un peu. Le point important est qu'en C#, on peut avoir un comportement différent pour un objet selon le type de la variable qui contient la référence vers l'objet, alors que c'est impossible en Java. Personnellement, je trouve ça plutôt gênant et surtout, je ne vois pas d'application pratique.-
[^]Re: C'est un troll.
Posté par Philip Marlowe (Jabber id, ) le 20/07/2004 à 12:12. (lien). Évalué à 2.Mais ce n'est surtout pas au programmeur de s'en occuper !
Je me suis tué à le dire : se prendre pour un compilateur, c'est un trouble du comportement !
-
[^]Re: C'est un troll.
Posté par TImaniac (page perso, ) le 20/07/2004 à 15:10. (lien). Évalué à 3.Ca fait des années qu'on sait faire des optimisations globales qui permettent de virer les virtual inutiles
Dans le cas de C#, le code est transformé en code intermédiaire, si le compilateur a procédé à des optimisations, comme par exemple des inlines, je vois de gros problèmes dans certains scénarios :
Je déclare une classe qui dérive d'une classe du code intermédiaire...
je fais la même chose au runtime de manière dynamique...
C'est pas pour rien que Java ou C# n'a jamais et ne pourra jamais procéder à ce genre d'opitmisation !
Tu vois où est le problème maintenant ;)-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 20/07/2004 à 16:57. (lien). Évalué à 2.Oui, il est connu que la création de classes dynamiquement empêche ce genre d'optimisation. Mais rien n'empêche de désactiver cette création dynamique dans un certain mode de compilation. Or, de très nombreuses applications n'ont pas besoin du chargement de code dynamique. De plus, on peut très bien imaginer un contrôle très fin de la création de classes dynamiques qui permettrait une optimisation partielle avec du code générique pour certaines classes et du code optimisé pour d'autres, dans le même esprit que ce qui est prévu pour les generics de C#.
Donc C'est pas pour rien que Java ou C# n'a jamais et ne pourra jamais procéder à ce genre d'opitmisation ! est peut être vrai, mais pas pour les raisons que tu indiques.-
[^]Re: C'est un troll.
Posté par TImaniac (page perso, ) le 20/07/2004 à 18:55. (lien). Évalué à 2.Sauf que dans .NET/Mono, les chargements de classes se font TOUJOURS de manière dynamique s'il n'est pas situé dans la même dll...
-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 21/07/2004 à 06:44. (lien). Évalué à 2.Le problème n'est pas le chargement mais la CREATION de classes. Quand le code d'un programme est compilé, le compilateur a accès au bytecode des autres classes et peut donc faire une analyse de celui-ci. En Java, et je suppose que c'est la même chose en .NET, tu peux en plus charger le code d'une classe dynamiquement, sans que cette classe a été présente à la compilation. Si la classe en question implémente une interface quelconque, alors le code utilisant cette interface ne peut pas être optimisé en enlevant les virtuals car on ne peut pas restreindre le type effectif des objets qui vont être passés au code concerné. C'est pourquoi les conteneurs à base d'Object sont pourris et donc que les Generics de Java sont une mauvaise solution en terme de performances (contrairement à ceux de C#). Bien entendu, il est possible de tracer statiquement dans un programme les utilisations des objets dont la classe peut être créé dynamiquement et donc d'optimiser le reste du code.
-
[^]Re: C'est un troll.
Posté par TImaniac (page perso, ) le 21/07/2004 à 10:45. (lien). Évalué à 2.Le compilateur a effectivement accès au bytecode des autres classes... Mais je comprend pas trop comment il peut se permettre de faire des inlines comme ça... la classe qu'il référencie est toujours dans un autre assembly (.dll), et imagine que tu changes l'assembly, par exemple pour réparer un bug, ben toutes tes fonctions inlinées ne vont pas en profiter... Et c'est une situation classique en .NET d'avoir des classes dans des assemblies différentes...
Et puis les scénarios de chargement dynamique au runtime sont de plus en plus courant, ne serais-ce que pour faire une architecture de plugin, on parcourt un assembly au runtime et on créé des instances à la volée... Enfin tout ca pour dire que les cas où le compilateur peut faire son boulot trankilou il est rare...
Je me trompes peut-être complètement :)-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 21/07/2004 à 12:04. (lien). Évalué à 2.Non, non, tu as raison, c'est compliqué, mais c'est faisable en particulier quand on veut distribuer un binaire hyper efficace, quitte à ce qu'il soit statiquement lié.
Ceci étant, sur le fond, quand on a besoin d'un vrai polymorphisme, on doit avoir des méthodes virtuals avec late biding. Alors qu'on marque explicitement les méthodes en question virtual ou qu'on marque final celles qui ne sont pas polymorphes, franchement, c'est la même chose...
-
-
-
-
[^]Re: C'est un troll.
Posté par TImaniac (page perso, ) le 20/07/2004 à 21:18. (lien). Évalué à 2.J'en profite pour te demander ce que tu entends quand tu dis :
Mais encore une fois, en fait on s'en fout un peu. Le point important est qu'en C#, on peut avoir un comportement différent pour un objet selon le type de la variable qui contient la référence vers l'objet, alors que c'est impossible en Java. Personnellement, je trouve ça plutôt gênant et surtout, je ne vois pas d'application pratique.-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 21/07/2004 à 06:50. (lien). Évalué à 2.Sauf erreur de ma part, on a la situation suivante. Je déclare une classe A avec une méthode d sans mettre de virtual, puis une classe B qui hérite de A et qui redéfinie d avec un new. Cette redéfinition n'implique aucun polymorphisme : si j'ai une variable de type A, alors l'appel à d provoquera toujours l'exécution de la méthode de A, même si le type réel de l'objet référencé par la variable est B. Par contre, si j'ai une variable de type B, alors l'appel à d exécutera la méthode de B. En d'autres termes, selon le type de la référence vers un même objet, la méthode exécutée n'est pas la même. Il n'est pas possible de faire ça en Java et je trouve ça bien. J'avoue que je ne comprends pas trop à quoi ça sert en C#.
-
[^]Re: C'est un troll.
Posté par TImaniac (page perso, ) le 21/07/2004 à 11:03. (lien). Évalué à 2.using System;
class MainClass
{
public static void Main(string[] args)
{
A a = new B();
B b = new B();
a.d();
b.d();
}
}
class A{
public void d(){
Console.WriteLine("Je suis une voiture");
}
}
class B : A{
public new void d(){
Console.WriteLine("Je suis une ford");
}
}
on obtient effectivement :
Je suis une voiture
Je suis une ford
Je vois effectivement ce que tu veux dire.
Le compilateur se base sur la définition stricte de a et fait dès lors exécuter d de A. Le compilateur n'a pas tenu compte du véritable type de a. Considérons une instruction if et imaginons qu'en fonction de l'évaluation de la condition, on assigne dans a soit un objet A, soit un object B. Le compilateur lui-même ne peut savoir que a contient réellement un objet B. Ce n'est qu'en cours d'exécution de programme que cette constatation peut-être faite, et, par défaut, le compilateur ne génère pas de code permettant de faire cette constatation. (sinon on aurait les même problème de perfs qu'avec les virtual)
Effectivement celà peut-être troublant, mais bon, ce n'est pas non plus vraiment génant à mon goût... celui qui développe la classe sait explicitement ce qu'il fait, il redéfini une méthode d'une classe alors que normalement il ne peut pas (elle n'est pas virtual), donc celà paraît normal qu'il ne puisse pas en modifier le comportement... Je pense que celà permet de redéfinir une méthode, et, en connaisssant le type exact on peut appeler cette version de la méthode. (pour contourner le fait que les méthodes ne sont pas virtual par défaut).
Enfin perso je me souvient pas avoir rencontrer le problème.-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 21/07/2004 à 12:06. (lien). Évalué à 2.Ce qu'est j'aimerais surtout savoir, c'est à quoi ça peut bien servir... Je veux dire, contrêtement ?
-
[^]Re: C'est un troll.
Posté par TImaniac (page perso, ) le 21/07/2004 à 17:12. (lien). Évalué à 2.Concrêtement ? Réutiliser une classe (par exemple je veux me faire un contrôle personnalisé) et changer l'implémentation d'une méthode...
Je fais un contrôle MonButtonAmélioré
celui qui considère que c'est un bouton de base, il aura accès aux méthodes comme si c'était un bouton, la classe bouton n'ayant pas autorisé la virtualisation, l'utilisateur n'est pas perdu. L'utilisateur qui considère que c'est une instance de MonButtonAmélioré appelera ma méthode qui fait des trucs en plus, et là il saura à quoi s'attendre puisque c'est lui qui a demandé explicitement une référence vers cette sous-classe.
En gros je crois qu'il faut voir celà comme ca :
1 - tu peux toujours redéfinir une méthode dans une classe qui hérite d'une autre
2 - soit la classe mère veut que ce soit la classe fille qui définisse une méthode précise, auquelle cas le développeur la met virtual. Sinon dans tous les autres cas le comportement ne change pas, il faut que le développeur fasse une référence explicite au type exacte de la classe pour obtenir le comportement différent si c'est une classe hérité avec une méthode new.
On retrouve le même principe pour les interfaces :
class A : InterfaceB {
interfaceB.methode(){
}
}
là il faut utiliser explicitement une référence à l'intefaceB (par exemple (new A() as InterfaceB).methode(); ) pour pouvoir en utiliser une méthode.
Je trouve à la limite ce comportement plus cohérent pour l'utilisateur...
Imagines le cas suivant :
class Véhicule{
private nom = "voiture" //ca pourrait évoluer
public ToString(){
Console.WriteLine(nom);
}
}
class Mercedes : Véhicule{
public new ToString(){
Console.WriteLine("Mercedes Class A");
}
}
Maitenant on prend toujours le cas où c'est la Mercedes qui est instanciée, mais la référence est pas la même.
Je veux lister mes véhicules pour aovir leur types :
j'obtiendrai en C# quelque chose comme ca en utilisant que des références de
Véhicule :
voiture
camion
voiture
4x4
en Java il obtiendrait celà :
voiture
Mercedes Class A
camion
Ford Focus 1.4l
Bref le new est là pour ne pas brider le développeur qui a besoin d'un nom particulier, mais lui empêche tout de même de changer le comportement qui peut être attendu par l'utlisateur qui ne s'attend peut être pas à une redéfinission de la méthode. C'est celui qui développe la super classe qui décide de mettre virtual ou pas.
-
-
-
-
-
-
-
-
-
[^]Re: C'est un troll.
Posté par boubou (page perso, ) le 20/07/2004 à 09:51. (lien). Évalué à 1.Au fait, tu as Chroma Medical Systems remarqué qu'en C# aussi, les méthodes ne sont pas virtuelles par défaut ? :-)
Trop de copier/coller tue le copier/coller... Je me demande comment j'ai réussi à faire ça...
-
[^]Re: C'est un troll.
Posté par Bière Drabo () le 20/07/2004 à 12:39. (lien). Évalué à 1.> Ce qui pose vraiment problème en C++ et qui est une erreur de conception à mon avis, c'est que le comportement des méthodes d'un objet dépend du mode de passage de celui-ci.
Le problème est plutôt la cohabitation de deux approches et le fait que ce soit trompeur si on les mélange, mais c'est le choix de C++ : n'en privilégier aucune. On peut s'efforcer :
- quand on fait de l'objet de n'avoir que du virtual (sans se poser de question) et de n'accéder aux objets que par pointeur ou référence, « à la Java », c'est assez naturel dans une sémantique d'identité
- quand on fait de la sémantique de valeur, utiliser les objets directement ou des références constantes.
C'est vrai qu'une solution plus propre serait d'avoir une différence de nature entre ces deux catégories. Difficile de juger de la pertinence des choix quand les premiers éléments de C++ étaient vraiment envisagés comme de futures extensions de C. Je trouve quand même un peu fort de parler d'erreur de conception : tout le monde s'accorde sur la syntaxe pénible et l'héritage lourd dans l'évolution de C++, mais l'essentiel (pour ce langage et avec ses objectifs) est de permettre un paradigme quitte à ce que le fait d'en permettre plusieurs apparaisse bancal quand on n'en considère qu'un seul.
-
-
-
-
-
[^]Re: C'est un troll.
Posté par Black Fox (page perso, ) le 20/07/2004 à 11:19. (lien). Évalué à 2.Il s'agit d'équipe de chercheurs en théorie des langages et franchement, le résultat est vraiment impressionnant (j'ai honte d'admirer une production de MS, mais bon).
T'inquiette le leader de ce groupe as été débauché de chez borland et est le créateur du compilo turbo pascal ainsi que du Delphi (Et les évolutions du language Pascal Object qui vont avec) :p
Par contre le multi héritage n'est pas prévu pour la CLI 2.0 et je trouve ça vraiment domage...
Que certains langages .Net ne le supportent pas : ok
Mais que ce ne soit même pas présent ça manque vraiment (le seul language qui l'implémente est le C++, mais hors de la CLI donc si cette fonctionalité est utilisée les autres languages ne peuvent pas utiliser les classes produites, la réflexion est impossible, ...)-
[^]Re: C'est un troll.
Posté par Philip Marlowe (Jabber id, ) le 20/07/2004 à 12:17. (lien). Évalué à 1.le seul language qui l'implémente est le C++, mais hors de la CLI
Eiffel Software implémente un compilateur Eiffel pour .NET qui supporte l'héritage multiple. Cela s'appelle ENViSioN.
http://www.eiffel.com/products/(...)
-
-
-
-
-
-
-
-
-
-
[^]Re: C'est un troll.
Posté par Dring FirebirdVsMySql () le 16/07/2004 à 21:14. (lien). Évalué à 1.Et l'équivalent de printf et le nombre d'arguments variables aussi.
Cela dit, je ne vois pas ce que ça apporte par rapport au passage d'un tableau de taille variable.
Mais pour les habitués du printf, j'imagine que c'est plus naturel. Amélioration ou pollution ?--
Non, rien.-
[^]Re: C'est un troll.
Posté par kra () le 16/07/2004 à 22:29. (lien). Évalué à 1.ceci dit, avec toString() et la somme de chaine en Java, je vois pas l'interet d'avoir un equivalent de printf avec un nombre d'arguments variables, si ce n'est eviter de bousculer les habitudes indecrottables des developpeurs C
-
[^]Re: C'est un troll.
Posté par Guillaume Laurent (page perso, ) le 17/07/2004 à 07:59. (lien). Évalué à 3.> je vois pas l'interet d'avoir un equivalent de printf
Regarde mieux :
- c'est plus rapide (concatener des String en Java est assez couteux)
- c'est beaucoup plus lisible.
- il est impossible d'internationaliser une chaine construite à coup de "+".-
[^]Re: C'est un troll.
Posté par kra () le 17/07/2004 à 11:11. (lien). Évalué à 0.ok pour le reste (en fait, j'ai pas cherche a verifier, mais ca a l'air de se tenir, donc je le prend pour comptant), mais l'argument de la lisibilite me laisse pantois!!!
perso je lis de gauche a droite et mon cerveau a du mal a remplacer un %i par le n-ieme argument lui correspondant situe apres la chaine que je lis, chose qui ne se produit pas en Java, vu que t'ecris sequentiellement ta chaine.-
[^]Re: C'est un troll.
Posté par Guillaume Laurent (page perso, ) le 17/07/2004 à 12:13. (lien). Évalué à 2.Pantois, vraiment... Bon puisqu'il faut te tenir la main pour verifier les choses, allons-y :
"Erreur numero %1 a la ligne %2, colonne %3 du fichier %4", errno, lineNb, colNb, fileName
"Erreur numero " + error + " a la ligne " + lineNb + ", colonne" + colNb + " du fichier " + fileName
Tu n'a pas besoin de "remplacer les %i", tu infères leur valeur par le contexte du string. Lequel contexte est beaucoup plus clair si le string n'est pas entrelardé de '"' et de '+'. Sans compter que c'est bien plus facile à écrire, par exemple j'ai volontairement fait une erreur dans le 2eme exemple, tu arrives à la voir facilement ?-
[+] [^]Re: C'est un troll.
Posté par kra () le 17/07/2004 à 14:40. (lien). Évalué à -1.mouais, pour commencer, tu seras gentil de me lacher la main.
si par erreur, tu entends l'absence d'espace apres colonne, j'appelle pas vraiment ca une erreur, plus une faute de frappe.
Je l'ai vu a la deuxieme lecture de la ligne.
bref, toujours est il que pour ecrire ta premiere ligne, tu as du ecrire le message d'erreur, puis donner le nom des variables en te demandant dans quel ordre tu dois les donner : 2 etapes au lieu d'une.
ensuite, quand tu "infere leur valeur par le contexte du string", tu devines ce que la ligne veut dire, pas ce qu'elle fera effectivement, ce qui me parait quand meme le plus important.
quand a ce qui est d'entrelacer avec des " et des +, c'est pas pire que d'entrelacer avec des %i
peut etre es tu rentre dans la matrice du C, ce qui fait que tu es parfaitement habitue a lire un printf.
l'ecriture java-style me parait plus naturelle.-
[^]Re: C'est un troll.
Posté par jmfayard () le 17/07/2004 à 20:04. (lien). Évalué à 5.Pour mettre tout le monde d'accord :
ces 2 syntaxes sont à chier par rapport à l'interpolation directe de variables à la Perl ou Ruby, beaucoup plus naturelles et lisibles :
"Erreur numero $error a la ligne $lineNb, colonne $colNb du fichier $fileName"
ou quelquechose comme
"Erreur numero %{error} a la ligne %{lineNb}, colonne %{colNb} du fichier %{fileName}"-
[^]Re: C'est un troll.
Posté par reno () le 17/07/2004 à 22:23. (lien). Évalué à 1.Rah, merci tu me fais plaisir!
Je viens de lire un tutorial sur D ( http://www.digitalmars.com/d/index.html(...) ) ou ils present printf comme la huitieme merveille du monde..
Je pense que les devs de Java et de D auraient dut regarder la syntaxe de Ruby au moins pour ce point la!
OK, c'est du "sucre syntaxique" mais les commandes d'affichage sont tellement utilisé que ça le vaut et moi entre un:
1- puts "Erreur numero %{error} a la ligne %{lineNb}, colonne %{colNb} du fichier %{fileName}"
2- printeln "Erreur numero " + error.toString + " a la ligne " + lineNb + ", colonne" + colNb + " du fichier " + fileName
3- printf( "Erreur numero %d a la ligne %ld, colonne %ld du fichier %s", errno, lineNb, colNb, fileName);
Je prends 1!
La grosse difference entre 1 et 2 est que dans 1 le toString est appelé "magiquement"..
Normalement string+objet, cela fait type error et heureusement pour la vérification de typage, mais dans 1, la syntaxe indique bien quand veut obtenir une string en final et donc c'est remplacé par string+objet.toString..
Le printf est vraiment tres moche, il n'y a que le C++ qui ait réussi a faire pire.. Le seul avantage que je lui voit c'est qu'on peut facilement faire des formattage assez complexe (indentation a gauche, a droite,etc..), possibilité qui est quand même assez rarement utilisé..
Je ne vois pas pourquoi ce "syntactic sugar" bien agréable devrait être réservé aux languages "de script"..-
[^]Re: C'est un troll.
Posté par Guillaume Laurent (page perso, ) le 18/07/2004 à 08:30. (lien). Évalué à 3.> La grosse difference entre 1 et 2 est que dans 1 le toString est appelé "magiquement"..
Euh, en java aussi, quand tu concatènes à coup de '+' il appelle toString() tout seul comme un grand.
> Je ne vois pas pourquoi ce "syntactic sugar" bien agréable devrait être réservé aux languages "de script"..
Plus exactement, aux langages interpretés. Un langage compilé ne peut pas faire ce genre de choses, déjà parce que le nom d'une variable n'est pas une information que la compilation conserve (donc plus moyen d'interpoler "blah %{foo} blah").-
[^]Re: C'est un troll.
Posté par Sidoine de Wispelaere (page perso, ) le 19/07/2004 à 12:56. (lien). Évalué à 1.L'interpolation de "blah $foo blah" se fait à la compilation, ça donne un truc du genre "blah ".$foo." blah".
-
-
-
[^]Re: C'est un troll.
Posté par Guillaume Laurent (page perso, ) le 18/07/2004 à 08:08. (lien). Évalué à 2.> ces 2 syntaxes sont à chier par rapport à l'interpolation directe de variables
C'est vrai, mais :
- un langage compilé ne sait pas faire ça, donc on est un peu hors sujet :-)
- tu n'as pas de controle sur la façon dont les variables sont effectivement affichée (par ex., afficher un entier en hexa, ou un float avec une certaine précision).
C'est pas pour rien que Ruby a sprintf() aussi :-) (et Perl aussi, mais j'aime pas Perl).-
[^]Re: C'est un troll.
Posté p
-
-
-
-
-
-
-
-
-


Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.