Ne fais pas exprês de ne pas comprendre.
Euh, toi tu me dis qu'il manque la plupart des trucs.
Pourtant si tu regardes le volume d'API supportés, ben en gros il manque que System.Windows.Forms, et encore, il est implémenté en partie. Alors dire qu'ils sont loin d'arriver au bout voilà quoi...
Je te trouve un peu naif sur ce coup la :-)
C'est juste que je trouves vraiment petit d'accuser MS de mal documenter ses APIs, alors que dans l'ensemble je trouve ceux de .NET largement plus documentés que ceux de Java.
Si si je t'assure, celà changerai aussi la sémantique, notamment à l'exécution : un programme qui fait de l'introspection ne verra pas du tout la classe de la même manière selon l'implémentation choisie. Si celà ne posait pas de problème d'incompatibilité majeure, alors pourquoi ils n'ont pas choisie l'implémentation de C# ?
Ils sont masos ces mecs !!!
Comme je vais encore me répéter : là je parles de réutiliser l'existant !!! Je ne vois absolument pas ce qu'il y a de maso de proposer un framework qui permet de réutiliser facilement l'exsistant sans le recoder sur la plateforme, soit en le recompilant si le langage est supporté, soit à travers les possibilités d'appels natifs.
Déconseillé, mais possible. (c'est trés différent)
Et alors ? J'ai dis le contraire peut être ? Effectivement CNI est mieux pour celà, mais il oblige à utiliser gcj non ? Ce n'est pas un peu très limitatif ?
Chez Microsoft ils ont préférer appeler un chat un chat et mettre les pointeurs dans C# quand c'est nécessaire, sans passer par un truc intermédiaire qui cache la réalité mais pas du tout leurs conséquences.
+ qq autre. C.a.d trés peu.
Ben voyons. J'ai comme l'impression que tu n'as absolument aucune idée de l'étendue du framework .NET, pourtant c'est un peu de la même ordre de taille que le J2EE... Enfin bref, ASP.NET est 100% compatible par exemple, permet de migrer facilement des applications, tu en fais quoi ?
C'est justement pour ça que j'ai pas trop confiance en M$...
si c'est juste parcqu'ils ont oublier de documenter 2 ou 3 fonctions dans des vieux APIs, voilà quoi...
Moi je fonde mon raisonnement sur la réutilisation du réexistant, et toi t'essai de me contredire en partant d'un nouveau projet... Celà a au moins le mérite de se compléter à défaut de s'opposer :)
Euh, une implémentation comme celle-ci est forcement gravée dans la pierre, parcque là Sun n'a pas juste choisi une implémentation, il a aussi choisi une sémantique associée aux generics... ca ne se modifie pas comme celà, au risque de tout voir péter.
Non avec .NET tu es obligé de respecter seulement la CLI. La CLI a été définie pour faciliter la réutilisation d'API en spécifiant certains concepts et méthodes permettant d'assurer l'interopérabilité, mais reste assez limitée pour ne pas contraindre trop l'implémentation de nouveaux langages. Evidemment il reste des contraintes : il faut que le langage soit procédural (ou tout de moins ce qu'il expose) et objet c'est pas plus mal (s'il veut réutiliser). Mais les règles sont bien définies, c'est tout l'intérêt d'un protocole : suffisament précis pour faciliter les communications et suffisament général pour ne pas trop contraindre leur utilisation.
Pur être plus précis, le compilateur Java ne génère qu'une seule représentation du code de la classe générique.
Comment il fait ? Ben, il ajoute des opérations de castings partout, exactement comme tu l'aurais fait, et il met le type "object" partout dans le code de ta classe. Où est l'intérêt ? Si si il y en a un, le compilateur peut otut de même faire une vérification statique de type, alors que si tu l'avais fait toi même, tu aurais du vérifier à la patte tous tes casts. Dans tous les cas, à l'exécution, tous les types primitifs se font boxés et déboxés car transformés en "object", et bien sûr par introspection tu es incapable de savoir que ta classe est une classe générique et tu ne peux bien entendu pas en tirer partie. Autre avantage : il n'ont pas eu besoin d'ajouter d'instruction dans la JVM.
En C#, le compilateur génère une classe qui contient le code, mais avec des attributs indiquant que c'est une classe générique. Déjà lors de l'exécution, tu peux savoir que c'est une classe générique. Lorsque tu demandes une instance de ta classe générique, le compilateur génère une nouvelle version (sauf bien entendu si tu as déjà demandé cette classe avec le même type en paramètre) en y "collant" ton nouveau type : il n'y a aucun cast, les types primitifs ne sont pas boxé (question perfs c'est pas plus mal, surtout quand on sait que les classes génériques sont souvent utiliser pour gérer des collections), et tu n'as rien perdu des possibilités d'introspection.
Sauf que ton compilateur peut très bien faire les appels de méthodes comme il le sens avec les instructions qui lui plait, implémenter un type de base avec une taille de données qui l'amuse, sans parler de sa définition de classe qui ne sera peut-être pas la même, etc. Bref, tu pourras effectivement réutiliser du bytecode, mais le programmeur va devoir faire en sorte que son compilateur respecter toutes les règles de Java, à défaut d'un sous-ensemble plus "friendly" et bien défini. Rien ne vaut des conventions écrites, et un bytecode conçu avec cet objectif (histoire de ne pas non plus limiter les possibilités et/ou les perfs)
C'est un peu le problème de l'autoboxing : il faut plus ou moins réfléchir avant de l'utiliser, le problème c'est qu'on ne s'en rend pas toujours compte. Heuresement, l'impact sur les perfs est négligeable, sauf dans les boucles... J'ai un peu du mal à expliquer parfois à des programmeurs qu'il faut parfois l'éviter :)
M'enfin chez Sun ils sont tellement doués qu'ils sont eux même tombé dans le panneau : avec leur implémentation des generics, tout type primitif se vera boxé et déboxé lorsque associée à une classe générique... comme quoi.
Pourquoi tu ramènes cela à .net?
Ben tout simplement parcque la personne à laquelle j'ai répondu répondait elle-même à la possibilité de choisir son langage avec Mono/.NET. Cette personne a voulu montrer que en Java aussi c'était possible, j'ai juste voulu expliquer la différence. Je suis effectivement enthousiaste comme tu l'as remarqué, mais depuis le début, si tu relis tous mes posts, c'est jamais moi qui est commencé à parler de .NET. Je l'ai juste ramené quand le sujet était là, et là c'est le cas ;)
Tout à fait. Alors quand un langage supporte une nouvelle plateforme comme .NET, même s'il y a 2 ou 3 différences, c'est quand même beaucoup plus appréciable comme transition. Je pense notamment au C++ managed qui permet de combiner code natif et code managé, y'a rien de spécial à faire et ça marche : après ils peuvent commencer à utiliser les nouveaux API, écrire le nouveaux code avec, et intégrer facilement l'existant. Pareil pour J# qui propose d'importer un projet Java, avec il est vrai une limitation quand au framework supporté (Java 1.3 seulement pour le moment)
Je n'attaque pas spécialement J2EE là dessus, je dis juste que c'est le choix philosophique de la plateforme Java : limiter les possibilités de réutilisation de code existant (pour moi JNI est ce qu'on peut appeler l'opération de dernière chance, ou alors quand il n'y a pas vraiment le choix comme par exemple OpenGL qui peut difficilement être codé en plus haut niveau sans avoir accès aux drivers). C'est pas du tout la même philosophie que .NET, celà a des inconvénients, que j'ai cité, mais ausis des avantages : ils forcent le portage sur la plateforme en réécrivant le code à réutiliser et on y gagne en portabilité.
Ce que je veux dire, c'est que .NET est moins limitant, C# offre tous les outils adéquate, libre aux développeurs de faire leur choix stratégique, dans tous les cas ça se fera avec pas mal de confort.
Merci pour cet historique de Eiffel, je ne le connaissais pas.
Si tu veux vraiment faire de la méta programmation, je te recommande fortemement Smalltalk-80 ou Squeak
Je veux pouvoir en faire quand j'en ai besoin. Tu me conseille Smalltalk, c'est d'ailleur entre autre de ce langage que s'est inspiré C#. Je préfère utiliser un langage qui est un bon compromis entre fonctionnalités, performances et confort plutôt qu'un langage "joli" mais parfois dur à apréhender. Pour moi le langage doit être là pour me permettre d'exprimer des concepts avec le maximum de confort, sans avoir à trop réfléchir. Ce pourquoi par exemple je n'utilise jamais l'héritage multiple, sachant pertinament que celà va m'obliger à me poser pleins de question quand à aux conséquences. C'est de ce principe qu'est parti le concepteur de C#, c'est pourquoi il n'y a pas d'exceptions rattrapées, c'est pourquoi il n'y a pas d'héritage multiple, c'est pourquoi les méthodes sont finales "par défaut".
Tu peux voir si tu veux le C# comme une opération marketing. Il est évident que ce langage a été développé pour concurrencer Java. Mais ce que j'ai trouvé positif, c'est qu'ils ont vraiment ajouter des petits "+" qui ont su faire la différence en terme de confort et aussi de productivité (réutilisation aisée de code), bref ils ont voulu apporter des nouveautés par rapport au concurrent : c'est d'ailleur pourquoi il a eu beaucoup de succès, et c'est pas pour rien que Java reprend la plupart des petits "+" qui font la différence. C# répond à de vrais besoins, pas à des jolies théories objets.
Après on peut argumenter pendant des heures sur le fait que C# ne suit pas correctement le dernier paradigme objet à la mode avec toutes les fonctionnalités qui font la beauté d'un vrai langage objet, mais ce n'est absolument pas le but de ce langage : il existe pour répondre à des attentes, et les nouveautés apportées apporte un véritable "+" pour la plupart des utilisateurs, et pas seulement les experts. D'ailleur tu sembles clairement indiquer que Java n'était pas pour toi suffisament utilisable par rapport à d'autres langages comme Eiffel. Pourtant pour beaucoup de développeurs, l'histoire a montré que leur point de vue n'était pas du tout le même, et qu'ils n'avaient pas du tout la même notion d'un langage utilisable.
C# et Java ce sont des langages pour la "masse" de développeurs, des langages tout public si on veut, pour la plupart des programmeurs. Je ne vais pas comparer à Eiffel que je ne connais absolument pas, mais à d'autres langages comme OCaml par exemple, qui sont certes très joli et procure une certaine satisfaction lorsqu'on n'a réussi à appliquer à la perfection un concept du langage, mais qui par contre sont destinés à des programmeurs qui aime bien se "branler" le cerveau (excuse moi pour l'expression, mais je trouvais qu'elle correspondait bien ;) )
Sinon, il apparaitrait que C# 2.0 intégrera la généricité contrainte
N'emploi pas le futur, la norme C# 2.0 est sorti il y a maintenant plus d'un an.
Le compilateur de MS est passé depuis un moment en version 2.0. Effectivement elle n'est distribué que dans les version "bétas" de Visual Studio 2005 parcque MS aime bien filer la plateforme complète de développement qui va avec. Mais si tu veux tu peux chopper cette version sans Visual Studio, et Mono a une preview de C# 2.0 depuis un moment, et à un ou 2 détails près c'est parfaitement utilisable (il manque surtout de l'optimisation, mais ça compile et ca fonctionne comme on le souhaite).
Si ca peut te faire plaisir C# est un langage des années 90 (c'est pas entierment faux, ils ont commencé à bosser dessus au 20ème siècle ;)), mais largement plus utile, notamment en ce qui concerne le confort de réutilisation que l'apport de langage du 21ème siècle comme Eiffel, qui sont par contre très joli à montrer à l'université, parcque ils respectent le paradigme objet et tout et tout. Mais désolé, je trouverai toujours plus utile la gestion transparente des évenements et les métas-données que la covariance, même si c'est des fonctionnalités moins récentes et déjà existantes. C# a été conçu comme un best-of des langages industriels, et de ce fait est un langage industriel. J'entend par industriel puissant, agréable et utile, pas seulement sur le papier, mais aussi avec une équipe de programmeurs.
Pour ton vécu et les mecs qui sotn passés de VB à C#, tu aurais pu leur montrer VB.NET, ils auraient eu quasiment les mêmes possibilités qu'en C# en gardant leur syntaxe favorite ;) La transition aurait été plus douce et vous y auriez gagner en productivité ;)
A la grosse différence près que là il n'y a aucun protocole qui défini comment doivent intéragir les langages entre eux, quel format doivent avoir les données. C'est tout l'intérêt de .NET : il y a la CLI qui est clairement définie (Common Language Interface) avec un autre acronyme pour spécifier le format des données à échanger. La plateforme Java n'a pas du tout été conçue avec cet objectif, et même s'il est possible d'implémenter pleins de langages au dessus de la plateforme Java, on est loin de l'interopérabilité qu'offre la plateforme .NET.
La verbosité est un handicap quand elle n'apporte aucune sémantique. C'est le cas quand la plupart des développeurs l'utilise n'importe comment, en méettant par exemple throws Exception devant toutes les méthodes, ou en catchant systématiquement.
Les concepteurs de C# se sont basé la plupart du temps sur des constats fait auprès d'utilisateurs/ddéveloppeurs, notamment Java. Pas seulement sur de jolis principes théoriques, qui dans ce cas précis n'est pas spécialement joli car empêche par exemple de déclencher de nouvelles exceptions à travers une interface, où laisse carrement des "trous" en cas de changement de version d'une classe sans recompilation de la classe utilisatrice.
Maintenant, comme dans Mono, rien n'empêche une appli Java d'appeler des fonctions natives,
Comme je l'ai déjà dis, c'est possible comme dans Mono, mais dans un cas c'est encouragé (avec toutes les facilités qu'offre C# pour, cad la notion de structure, de pointeur, de stack, etc.) et dans l'autre cas c'est déconseillé, avec un JNI inbittable. Heuresement qu'il y a des alternative, mais ce n'est pas du tout la même philosophie entre les 2 plateformes.
Mono implémente une VM, plus les 3 librairies de base que M$ à gentiment standardisé pour faire plaisir au bon peuple.
tu oublies la pile "Microsoft" dans les API de Mono, qui visent à recoder tous les API de MS, même ceux qui ne sont pas normalisés. Et ils vont plutôt vite. Donc c'est exactement le même combat que pour ClassPath par exemple.
Pour Java, il faut comprendre la plate-forme dans son ensemble
Pareil pour Mono.
les api M$ sont énormes, peu documentées, et sujettes à des évolutions sans préavis. (cf Wine).
N'importnawak.
les APIs sont énormes, OK. Ceux de la plateforme Java aussi. peu documentées ? mdr. Qui est-ce qui se plaint tout le temps que la MSDN est imbittable parcqu'il y a trop d'info ? Elle demande un temps d'adaptation, mais quand on sait où est quoi, il y a des tonnes d'infos, bien plus que sur le site de Sun. Sans parler des sites de programmeurs autre que MS (idem pour Java). Là on parle plus particulièrement du framework .NET, et la documentation est très très complète, avec de nombreux exemples, toutes les spécifs, etc. Et ça ne change pas du tout sans préavis comme tu dis : il n'y a qu'une révision par an en gros, avec comme partout des avertissements (deprecated) et principalement des ajouts, histoire d'assurer une compatibilité.
Pour Wine, c'est la couche bas-niveau des API Windows qu'ils copient, ce n'est pas du tout pareil. Il y a 2 ou 3 trucs qui ne sont pas documentés parcque non destinés à être utilisés (ou alors jsute par Word et Outlook ;) ) Sinon le reste ne bouge strictement pas, la plupart des vieilles applications tournent toujours sous XP, même s'il faut mettr un mode d'émulation, ceci étant due à des différence d'architecture plutôt qu'à des différences d'API.
Bref tu dis vraiment n'importe quoi.
Ben moi j'ai pris un exemple où y'avait pas besoin, qui mettait justement en évidence l'utilité du multi-langage d'un point de vue réutilisation. Même si ce n'est pas toujours possible, c'est parfois un gain de temps non négligeable, et voulir ignorer ce facteur pour pouvoir comparer "équitablement" revient à vouloir masquer les différences entre les plateformes, et donc les avantages. C'est comme si je voulais comparer une ferrari et une 2 chevaux, mais que pour pas voir de différence je les brides à 50km/h, comme ça personne ne pourra me dire que ma 2 chevaux va moins vite.
Ca n'a absolument pas le même but.
Désolé, je me suis planté de mot clé : c'est le mot clé "out" dont je voulais parler :) (Mais sinon explique moi le but de la covariance par rapport à "out")
Je veut changer la visibilité de certaines methodes de ma super-classe, je fait comment?
Pour moi soit tu es le développeur, et tu as accès au source, tu peux modifier l'accessibilité. Sinon je vois vraiment pas l'intérêt de laisser la possibilité aux utilisateurs de modifier l'accès aux attributs et méthodes d'une classe... Ca va tout péter la signature de la classe !
Tu propose comme solution d'introduire tout un nouveau paradigme de programmation, qui est en plus trés criticable au niveau de l'utilisabilitée réelle;
Pour l'ajout de méthode, pareil qu'au dessus, donne moi un exemple élégant qui me permette celà, avec bien entendu un exemple où celà a un intérêt et qui ne casse pas toute la signature de ma classe. J'ai vraiment des doutes quand à l'utilité réelle.
Tu Oubli de dire que pour réaliser cela il faut absolument que les API respectent un certains guide-de-compatibilité
Tout à fait : CLI (Common Language Interface)
En effet si tu veux garantir la réutlilisabilité de tes API, il faut mieux respecter ces règles (même si t'es pas obligé), mais à l'intérieur de ton code, tu peux utiliser toutes les fonctionnalités du langage, seules les parties exposées doivent être conformes. Pareil à l'utilisation, si ton langage support l'héritage multiple, il peut utiliser des classes conçues en héritage simple.
Cepandant je le répète la posibilité de diretement réutilisé une bibliothqèue existante est super-pratique, mais ce n'est vraiment pas idéal.
C'est quoi l'idéal ?
Je suis déja tomber 3 fois sur un cas identique et impossible de trouver une echapatoire!
Vas-y balance :)
Ensuite on va voir si c'est pas contournable et si celà ne va pas poser des problèmes potentiels :)
Sur la performance, c'est n'importe quoi
Me semble que ce n'est qu'un argument, contestable effectivement, mais le 2ème est déjà mieux : le créateur de C# pense qu'il est préférable de fermer la possibilité de modifier une méthode par défaut, plutôt que l'inverse, pour des tas de raisons (d'abord le programmeur ne s'en soucis pas, il ne documente pas la possibilité et l'impact d'une méthode sur les attributs d'une classe et son état, etc.) Pleins de bonnes raisons à mon goût, même si celà va à l'encontre du paradigme "objet". Et puis dans la pratique personne ne s'en plaint.
Tu est un peu dur, Java ajoute enormément de chose par rapport à son propre langage
Vi c'est ce que j'ai dis plus haut (ou plus bas), c'est bien pour le langage, mais celà ne créé pas d'émulation, et je trouve ca vraiment dommage.
C'est de la pire mauvaise fois (heureusement qu'il y a le smiley!)
C'était juste pour la vanne :)
Je parlais principalement de la réutilisation de code d'API natifs, notamment de d'API écrit en C ou dans d'autres langages, la réutilisation du code écrit en Eiffel je m'en doute ;)
Donc alors la réutilisabilité de l'existant ? (pas de l'existant Eiffel)
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
C'est ce que je reproche à Java : il faut souvent tout réécrire pour tout réutiliser.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
Euh, toi tu me dis qu'il manque la plupart des trucs.
Pourtant si tu regardes le volume d'API supportés, ben en gros il manque que System.Windows.Forms, et encore, il est implémenté en partie. Alors dire qu'ils sont loin d'arriver au bout voilà quoi...
Je te trouve un peu naif sur ce coup la :-)
C'est juste que je trouves vraiment petit d'accuser MS de mal documenter ses APIs, alors que dans l'ensemble je trouve ceux de .NET largement plus documentés que ceux de Java.
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
Comme je vais encore me répéter : là je parles de réutiliser l'existant !!! Je ne vois absolument pas ce qu'il y a de maso de proposer un framework qui permet de réutiliser facilement l'exsistant sans le recoder sur la plateforme, soit en le recompilant si le langage est supporté, soit à travers les possibilités d'appels natifs.
Déconseillé, mais possible. (c'est trés différent)
Et alors ? J'ai dis le contraire peut être ? Effectivement CNI est mieux pour celà, mais il oblige à utiliser gcj non ? Ce n'est pas un peu très limitatif ?
Chez Microsoft ils ont préférer appeler un chat un chat et mettre les pointeurs dans C# quand c'est nécessaire, sans passer par un truc intermédiaire qui cache la réalité mais pas du tout leurs conséquences.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
Ben voyons. J'ai comme l'impression que tu n'as absolument aucune idée de l'étendue du framework .NET, pourtant c'est un peu de la même ordre de taille que le J2EE... Enfin bref, ASP.NET est 100% compatible par exemple, permet de migrer facilement des applications, tu en fais quoi ?
C'est justement pour ça que j'ai pas trop confiance en M$...
si c'est juste parcqu'ils ont oublier de documenter 2 ou 3 fonctions dans des vieux APIs, voilà quoi...
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
[^] # Re: Pour en finir avec le FUD autour de Java ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
[^] # Re: Java Generics vs. C++ Templates
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
Comment il fait ? Ben, il ajoute des opérations de castings partout, exactement comme tu l'aurais fait, et il met le type "object" partout dans le code de ta classe. Où est l'intérêt ? Si si il y en a un, le compilateur peut otut de même faire une vérification statique de type, alors que si tu l'avais fait toi même, tu aurais du vérifier à la patte tous tes casts. Dans tous les cas, à l'exécution, tous les types primitifs se font boxés et déboxés car transformés en "object", et bien sûr par introspection tu es incapable de savoir que ta classe est une classe générique et tu ne peux bien entendu pas en tirer partie. Autre avantage : il n'ont pas eu besoin d'ajouter d'instruction dans la JVM.
En C#, le compilateur génère une classe qui contient le code, mais avec des attributs indiquant que c'est une classe générique. Déjà lors de l'exécution, tu peux savoir que c'est une classe générique. Lorsque tu demandes une instance de ta classe générique, le compilateur génère une nouvelle version (sauf bien entendu si tu as déjà demandé cette classe avec le même type en paramètre) en y "collant" ton nouveau type : il n'y a aucun cast, les types primitifs ne sont pas boxé (question perfs c'est pas plus mal, surtout quand on sait que les classes génériques sont souvent utiliser pour gérer des collections), et tu n'as rien perdu des possibilités d'introspection.
[^] # Re: Pour en finir avec le FUD autour de Java ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
M'enfin chez Sun ils sont tellement doués qu'ils sont eux même tombé dans le panneau : avec leur implémentation des generics, tout type primitif se vera boxé et déboxé lorsque associée à une classe générique... comme quoi.
[^] # Re: Pour en finir avec le FUD autour de Java ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
Ben tout simplement parcque la personne à laquelle j'ai répondu répondait elle-même à la possibilité de choisir son langage avec Mono/.NET. Cette personne a voulu montrer que en Java aussi c'était possible, j'ai juste voulu expliquer la différence. Je suis effectivement enthousiaste comme tu l'as remarqué, mais depuis le début, si tu relis tous mes posts, c'est jamais moi qui est commencé à parler de .NET. Je l'ai juste ramené quand le sujet était là, et là c'est le cas ;)
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
Ce que je veux dire, c'est que .NET est moins limitant, C# offre tous les outils adéquate, libre aux développeurs de faire leur choix stratégique, dans tous les cas ça se fera avec pas mal de confort.
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
Si tu veux vraiment faire de la méta programmation, je te recommande fortemement Smalltalk-80 ou Squeak
Je veux pouvoir en faire quand j'en ai besoin. Tu me conseille Smalltalk, c'est d'ailleur entre autre de ce langage que s'est inspiré C#. Je préfère utiliser un langage qui est un bon compromis entre fonctionnalités, performances et confort plutôt qu'un langage "joli" mais parfois dur à apréhender. Pour moi le langage doit être là pour me permettre d'exprimer des concepts avec le maximum de confort, sans avoir à trop réfléchir. Ce pourquoi par exemple je n'utilise jamais l'héritage multiple, sachant pertinament que celà va m'obliger à me poser pleins de question quand à aux conséquences. C'est de ce principe qu'est parti le concepteur de C#, c'est pourquoi il n'y a pas d'exceptions rattrapées, c'est pourquoi il n'y a pas d'héritage multiple, c'est pourquoi les méthodes sont finales "par défaut".
Tu peux voir si tu veux le C# comme une opération marketing. Il est évident que ce langage a été développé pour concurrencer Java. Mais ce que j'ai trouvé positif, c'est qu'ils ont vraiment ajouter des petits "+" qui ont su faire la différence en terme de confort et aussi de productivité (réutilisation aisée de code), bref ils ont voulu apporter des nouveautés par rapport au concurrent : c'est d'ailleur pourquoi il a eu beaucoup de succès, et c'est pas pour rien que Java reprend la plupart des petits "+" qui font la différence. C# répond à de vrais besoins, pas à des jolies théories objets.
Après on peut argumenter pendant des heures sur le fait que C# ne suit pas correctement le dernier paradigme objet à la mode avec toutes les fonctionnalités qui font la beauté d'un vrai langage objet, mais ce n'est absolument pas le but de ce langage : il existe pour répondre à des attentes, et les nouveautés apportées apporte un véritable "+" pour la plupart des utilisateurs, et pas seulement les experts. D'ailleur tu sembles clairement indiquer que Java n'était pas pour toi suffisament utilisable par rapport à d'autres langages comme Eiffel. Pourtant pour beaucoup de développeurs, l'histoire a montré que leur point de vue n'était pas du tout le même, et qu'ils n'avaient pas du tout la même notion d'un langage utilisable.
C# et Java ce sont des langages pour la "masse" de développeurs, des langages tout public si on veut, pour la plupart des programmeurs. Je ne vais pas comparer à Eiffel que je ne connais absolument pas, mais à d'autres langages comme OCaml par exemple, qui sont certes très joli et procure une certaine satisfaction lorsqu'on n'a réussi à appliquer à la perfection un concept du langage, mais qui par contre sont destinés à des programmeurs qui aime bien se "branler" le cerveau (excuse moi pour l'expression, mais je trouvais qu'elle correspondait bien ;) )
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 4.
N'emploi pas le futur, la norme C# 2.0 est sorti il y a maintenant plus d'un an.
Le compilateur de MS est passé depuis un moment en version 2.0. Effectivement elle n'est distribué que dans les version "bétas" de Visual Studio 2005 parcque MS aime bien filer la plateforme complète de développement qui va avec. Mais si tu veux tu peux chopper cette version sans Visual Studio, et Mono a une preview de C# 2.0 depuis un moment, et à un ou 2 détails près c'est parfaitement utilisable (il manque surtout de l'optimisation, mais ça compile et ca fonctionne comme on le souhaite).
Si ca peut te faire plaisir C# est un langage des années 90 (c'est pas entierment faux, ils ont commencé à bosser dessus au 20ème siècle ;)), mais largement plus utile, notamment en ce qui concerne le confort de réutilisation que l'apport de langage du 21ème siècle comme Eiffel, qui sont par contre très joli à montrer à l'université, parcque ils respectent le paradigme objet et tout et tout. Mais désolé, je trouverai toujours plus utile la gestion transparente des évenements et les métas-données que la covariance, même si c'est des fonctionnalités moins récentes et déjà existantes. C# a été conçu comme un best-of des langages industriels, et de ce fait est un langage industriel. J'entend par industriel puissant, agréable et utile, pas seulement sur le papier, mais aussi avec une équipe de programmeurs.
Pour ton vécu et les mecs qui sotn passés de VB à C#, tu aurais pu leur montrer VB.NET, ils auraient eu quasiment les mêmes possibilités qu'en C# en gardant leur syntaxe favorite ;) La transition aurait été plus douce et vous y auriez gagner en productivité ;)
[^] # Re: Pour en finir avec le FUD autour de Java ...
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
Les concepteurs de C# se sont basé la plupart du temps sur des constats fait auprès d'utilisateurs/ddéveloppeurs, notamment Java. Pas seulement sur de jolis principes théoriques, qui dans ce cas précis n'est pas spécialement joli car empêche par exemple de déclencher de nouvelles exceptions à travers une interface, où laisse carrement des "trous" en cas de changement de version d'une classe sans recompilation de la classe utilisatrice.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
Comme je l'ai déjà dis, c'est possible comme dans Mono, mais dans un cas c'est encouragé (avec toutes les facilités qu'offre C# pour, cad la notion de structure, de pointeur, de stack, etc.) et dans l'autre cas c'est déconseillé, avec un JNI inbittable. Heuresement qu'il y a des alternative, mais ce n'est pas du tout la même philosophie entre les 2 plateformes.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
tu oublies la pile "Microsoft" dans les API de Mono, qui visent à recoder tous les API de MS, même ceux qui ne sont pas normalisés. Et ils vont plutôt vite. Donc c'est exactement le même combat que pour ClassPath par exemple.
Pour Java, il faut comprendre la plate-forme dans son ensemble
Pareil pour Mono.
les api M$ sont énormes, peu documentées, et sujettes à des évolutions sans préavis. (cf Wine).
N'importnawak.
les APIs sont énormes, OK. Ceux de la plateforme Java aussi. peu documentées ? mdr. Qui est-ce qui se plaint tout le temps que la MSDN est imbittable parcqu'il y a trop d'info ? Elle demande un temps d'adaptation, mais quand on sait où est quoi, il y a des tonnes d'infos, bien plus que sur le site de Sun. Sans parler des sites de programmeurs autre que MS (idem pour Java). Là on parle plus particulièrement du framework .NET, et la documentation est très très complète, avec de nombreux exemples, toutes les spécifs, etc. Et ça ne change pas du tout sans préavis comme tu dis : il n'y a qu'une révision par an en gros, avec comme partout des avertissements (deprecated) et principalement des ajouts, histoire d'assurer une compatibilité.
Pour Wine, c'est la couche bas-niveau des API Windows qu'ils copient, ce n'est pas du tout pareil. Il y a 2 ou 3 trucs qui ne sont pas documentés parcque non destinés à être utilisés (ou alors jsute par Word et Outlook ;) ) Sinon le reste ne bouge strictement pas, la plupart des vieilles applications tournent toujours sous XP, même s'il faut mettr un mode d'émulation, ceci étant due à des différence d'architecture plutôt qu'à des différences d'API.
Bref tu dis vraiment n'importe quoi.
[^] # Re: A comparer plutot au C#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
Désolé, je me suis planté de mot clé : c'est le mot clé "out" dont je voulais parler :) (Mais sinon explique moi le but de la covariance par rapport à "out")
Je veut changer la visibilité de certaines methodes de ma super-classe, je fait comment?
Pour moi soit tu es le développeur, et tu as accès au source, tu peux modifier l'accessibilité. Sinon je vois vraiment pas l'intérêt de laisser la possibilité aux utilisateurs de modifier l'accès aux attributs et méthodes d'une classe... Ca va tout péter la signature de la classe !
Tu propose comme solution d'introduire tout un nouveau paradigme de programmation, qui est en plus trés criticable au niveau de l'utilisabilitée réelle;
Pour l'ajout de méthode, pareil qu'au dessus, donne moi un exemple élégant qui me permette celà, avec bien entendu un exemple où celà a un intérêt et qui ne casse pas toute la signature de ma classe. J'ai vraiment des doutes quand à l'utilité réelle.
Tu Oubli de dire que pour réaliser cela il faut absolument que les API respectent un certains guide-de-compatibilité
Tout à fait : CLI (Common Language Interface)
En effet si tu veux garantir la réutlilisabilité de tes API, il faut mieux respecter ces règles (même si t'es pas obligé), mais à l'intérieur de ton code, tu peux utiliser toutes les fonctionnalités du langage, seules les parties exposées doivent être conformes. Pareil à l'utilisation, si ton langage support l'héritage multiple, il peut utiliser des classes conçues en héritage simple.
Cepandant je le répète la posibilité de diretement réutilisé une bibliothqèue existante est super-pratique, mais ce n'est vraiment pas idéal.
C'est quoi l'idéal ?
Je suis déja tomber 3 fois sur un cas identique et impossible de trouver une echapatoire!
Vas-y balance :)
Ensuite on va voir si c'est pas contournable et si celà ne va pas poser des problèmes potentiels :)
Sur la performance, c'est n'importe quoi
Me semble que ce n'est qu'un argument, contestable effectivement, mais le 2ème est déjà mieux : le créateur de C# pense qu'il est préférable de fermer la possibilité de modifier une méthode par défaut, plutôt que l'inverse, pour des tas de raisons (d'abord le programmeur ne s'en soucis pas, il ne documente pas la possibilité et l'impact d'une méthode sur les attributs d'une classe et son état, etc.) Pleins de bonnes raisons à mon goût, même si celà va à l'encontre du paradigme "objet". Et puis dans la pratique personne ne s'en plaint.
Tu est un peu dur, Java ajoute enormément de chose par rapport à son propre langage
Vi c'est ce que j'ai dis plus haut (ou plus bas), c'est bien pour le langage, mais celà ne créé pas d'émulation, et je trouve ca vraiment dommage.
C'est de la pire mauvaise fois (heureusement qu'il y a le smiley!)
C'était juste pour la vanne :)
Je parlais principalement de la réutilisation de code d'API natifs, notamment de d'API écrit en C ou dans d'autres langages, la réutilisation du code écrit en Eiffel je m'en doute ;)
Donc alors la réutilisabilité de l'existant ? (pas de l'existant Eiffel)