TImaniac a écrit 6423 commentaires

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)

En faisant simple, c'est de pouvoir contraindre un parametre générique à n'etre que d'un certains type,
Oué enfin la solution C# ne permet effectivement pas d'imposer un type, mais permet d'imposer une interface... donc bon pour moi l'utilité est la même, il n'y a donc pas de lacune pour ce cas précis.

On parle de la covaraince du type de retour
je sais ce qu'est la covariance, ce que j'ai voulu te dire, c'est que C# a le mot clé ref qui permet d'effectuer des passages par référence et donc de "retourner" plusieurs valeurs, là encore avec vérification du type, puisque celà semble être un bon critère.

De plus ta solution n'est pas réalisable quand ce n'est pas toi qui a concu la bibliothèque.
? Une bibliothèque n'est pas censé être modifiée, tout ce qu'on peut faire c'est utiliser des constructions de la bibliothèque en les spécialisant par héritage. Je ne vois vraiment pas le rapport avec la choucroute, ou alors tu t'explique ou alors je comprend mal. QUand à mon hack immonde, désolé mais je le trouve vraiment élégant, implémenter une interface en lecture/écriture sans autoriser tout le monde à y accéder, je trouve ça class.

Laisse les Aspect ou ils sont!
Je te propose une solution, et tu me dis de la laisser tomber. Poutant elle marche très bien. Uen variante consiste à injecter du code à travers des infos passées en méta-données, là encore de manière élégante. Arrête de snober tout ce qui résoud le problème.

Mais sur ce sujet, je suis plutot sceptique sur la reelle pertinance. [multi-langages]
Ben, c'est vrai que recompiler une application existante en .NET grâce au support multi-langages c'est parfaitement inutile, c'est vrai que laisser le choix au programmeurs du langage dans un projet (ok au sein d'un même projet c'est discutable) sans se soucier de comment l'API sera utilisé et par qui, c'est encore plus inutile. D'ailleur c'est rigolo, mais pour tous les langages de la plateforme tu as accès de manière uniforme aux API du frameworks, et pourtant tu ne sais strictement pas dans quel langage il a été codé...
et du coup tu contournera le problème en duplicant ton code
Non pas forcement, il y a toujours une autre solution. Mais je maintient ce que je dis : l'héritage multiple peut poser des problèmes (multiples c'est le cas de le dire), ne serais-ce qu'à cause de l'héritage de concepts à la signature identique et à d'autres sortes de conflits.


Le fait même d'avoir conservé ce mot clef devrait faire condamner ce langage par toutes personnes ayant compris le paradigme objet
Ben désolé il me semble avoir compris le "paradigme" objet, et j'attend une explication. SI tu veux parler du choix d'avoir mis en "final" par défaut, ben l'explication est par ici : www.artima.com/intv/nonvirtual.html .

java lui etait innovant pour l'epoque
je suis tout à fait d'accord. Dommage que ce n'est pas le cas de cette version.

il n'apporte riens, ou plutot apporte n'importe-quoi.
C# a peut-être copier des fonctionnalités d'autres langages sans vraiment rien inventer, mais il a innover comme l'a fait Java à son époque : il a inclu dans un même langages des principes et techinques jusque là dispersées dans différents langages. Java5, dont on parle actuellement, n'apporte rien de plus que C#, toutes les fonctionnalités existant dans un même langage : C#.
Mais bon c'est vrai que avoir inclu dans un mêmes des petits trucs vraiment utiles (par rapport à la covariance qui est un concept facilemetn contournable) c'est vraiment du n'importe-quoi. Et puis c'est vrai que le concept d'événement qui permet d'utiliser le patron de conception Observateur facilement c'est inutile. Et puis c'est vrai que avoir rajouter la possibiliter de checker les débordement dans les opérations élémentaires c'est n'importe quoi. Et puis tout ces petits trucs tirés à droite à gauche qui rende ce langage agréable, comme le foreach, les propriétés, ou encore les métas-datas, les itérateurs, et bien sûr tout ce qui touche le confort pour la réutilisation de code : les pointeurs, la notion de structure, de stack, etc. Mais bon tout celà c'est n'importe quoi. Pourtant dans la pratique c'est super utile, en tout cas beaucoup plus que la covariance ou l'héritage multiple.

Eiffel propose tout cela, et est portable (niveau source) sur beaucoup d'architecture.
Voilà, superbe langage. Mais du point de vu "industriel" comme tu dis : rien que sur un point, facilite-t-il la réutilisation de l'existant ? Ah vi y'a une méthode simple : il cible .NET ;)

Vous essayer de démontrer quoi là ? Que il faut un certain temps pour porter un API ? Que celà prend plus de 2 jours ? Clap clap clap.
Pour ce qui est du langage en soit, Mono va aussi vite que MS, ayant tous les 2 les spécifs en même temps. Là Sun est seul à sortir une implémentation du langage Java version "5" : c'est pas la même réactivité, pourtant dans le consortium JCP il y a des acteurs "professionnels" comme IBM... Mais bon faut dire que les spécifications définitives de Java 5 ont vraisemblablement permis à tous de partir en même temps : http://www.jcp.org/en/jsr/detail?id=924(...) ...

pas de généricité contrainte.
Tu peux expliquer ?

pas de covariance.
L'utilisation qui est généralement faite de la covariance peut tout à fait être envisagé par les arguments de méthodes passés en référence. Même si il n'y a pas de covariance, il n'y a pas de limitation, puisque le but peut être atteind autrement.

pas de visibilité flexible
Alors là c'est vraiment discutable.
Il suffit d'avoir une interface I qui contient une méthode foo, alors la classe A :
class A : I {
I.foo();
}
la méthode foo n'est accessible que lorsqu'elle est référencé en tant que I. Celà permet de gérer proprement les accès aux objets utilisateurs en leur filant seulement l'interface désirée.

Je ne mettrait pas ici l'héritage multiple
Même si leur implémentation est tout à fait envisageable, il y a de nombreuses raisons de s'en passé (d'abord parcque ce n'est pas indispensable).

De même je n'introduit pas non plus la faculté de définir des méthodes supplémentaires à une classe existante ou mieux à des objets
Ce concept peut très bien envisager avec une méthode orientée aspect et un tissage sur des classes existantes. Par contre j'ai du mal à comprendre l'intérêt en dynamique (pas la beauté de la chose, l'intérêt)
C# est un langage destiné à être utilisé, pas destiné à des fins académiques, ce qui explique de nombreux choix de conceptions.
Donne moi le nom d'un seul langage "moderne" qui intègre tout tes killerfeatures et qui soient utilisées parcque utilisable et simple à apréhender ?

inventer des nouvelles choses dans les langages, tu fais pas ça tous les jours..
Pourtant certaines boîtes ont un secteur R&D et développe des nouveaux concepts, parfois tirés d'autres concepts mais dans l'innovation il y a aussi le fait de réussir à intégrer des technos du passé...

Et oui, ce JDK est une innovation
dans le monde Java uniquement.
et oui, java fait évoluer l'informatique
De part sa communauté et des produits qui sont créés avec. Mais cette version de Java en soit de fait rien progresser du tout. Je dirais même que leur implémentation des generics va plutôt limiter dans le futur, parcque ce genre de choix est difficilement modifiable. Mais fallait sortir vite fait leur produit, sans faire de gros effort de R&D alors bon...

sauf que Delphi cible maintenant .NET dans sa dernière version.
Ça ferais une plus juste comparaison à mon avis.
Pas du tout, celà fait parti d'un des atouts majeurs de la plateforme .NET : elle a été pensé multi-langages, afin notamment de pouvoir programmer dans celui qu'on veut (même si certains sont plus adaptés), mais aussi pour pouvoir réutiliser facilement l'existant. Pareil pour la faciliter d'utiliser des APIs natifs : réutiliser l'existant. A l'opposé Java n'encourage pas à réutiliser l'existant lorsqu'il est natif et ne cherche pas faciliter l'intégration d'autres langages sur sa plateforme.

mais vas pas dire qu'en Java on réinvente à chaque fois la roue
J'ai pas dis à chaque fois. Me faites pas dire ce que je n'ai pas dis ;)

une API qui est pour l'instant plus grande que celle de la plateforme.net
Je suis d'accord, celà est due en partie à la vieillesse de la plateforme Java et justement au fait qu'il faille parfois "réinventer" la roue en Java. DirectX, même si ce n'est pas une priorité, c'était juste un exemple d'API difficilement exploitable en Java, pourtant on peut imaginer qu'une équipe de développement puisse avoir recour à cette techno, propriétaire mais performante. Quand on développe en Java, on s'arrange pour faire avec ce qui est dispo sur cette plateforme, comme tu le soulignes, il y a beaucoup d'API qui ont été portés, cetains étant de simple wrapper JNI (auquel cas c'est comme en .NET, mais en beaucoup moins élégant et pratique) et on ne réinvente pas la roue, mais dans d'autres cas il faut tout recoder.
Je vais prendre l'exemple tout bête du "port" de Quake2 sur la plateforme Java (l'exemple vaut ce qu'il vaut, il faut regarder le point de vue technique) : ils se sont fait chier à refaire un moteur complet (bref réinventer la roue), car impossible d'utiliser l'existant : bref plusieurs mois de boulot par plusieurs programmeurs.
Un autre s'est lancé dans le portage sur .NET : hop il a passé une journée à passer le code original du moteur en C en C++ managed (histoire que ca compile en .NET) et une autre journée de tuning : zou il obtient exactement la même chose, avec une seule commande il compile soit en natif soit en managé, et il obtient les mêmes perfs que l'équipe Java.
Tu vois où je veux en venir ?
Je ne dis pas que c'est toujours le cas (tu ne réinvente pas toujorus la roue !), mais forcer de reconnaître que Java n'aide pas à réutiliser l'existant et a conduit à faire de nombreux API en Java qui existait déjà en natif : beaucoup de perte de temps, avec un avantage : la portabilité.
Moi je préfère faire de la portabilité le jour où j'en ai besoin, plutôt que de m'enmerder avec dès le début parcque je n'ai pas le choix.

Un autre exemple : Mono a vu très rapidement le jour, pourquoi ?
Parcque en très peu de temps on a pu obtenir une plateforme utilisable qui se basait sur un existant fiable : GTK, Mozilla, libxml, Qt, etc. Pas toujours très portable, bien qu'ils aient tout de même choisi leurs technos, ils ont eu rapidement quelque chose d'impressionnant et de relativement stable, en proposant à l'utilisateur des API qu'il connait. En Java je rigole encore du temps qu'il a fallut pour obtenir Swing, sans parler que cette solution est loin d'être parfaite, et question intégration, elle se contente d'essayer d'imiter l'aspect graphique de l'environnement qui l'entour... Clap clap clap. Tout celà parcqu'ils ont voulu réinventer la roue et refaire une couche graphique portable. Résultat : un truc portable, mais un qualité perdue : l'intégration.

.net te dit en fait : hey prenez la facilité !
je dirais plutôt : avec .NET faites simple et utilisez l'existant, soit à travers la simplicité d'utilisation d'API natif, soit à travers le support de nombreux langages permettant de réutiliser du code existant.

tu comprends rien à ce que je dis : je dis juste que la portabilité à un coût, ce n'est pas une chose qui s'acquiert pif paf poum comme ça. Par fois il est plus facile de s'appuyer sur un existant, parfois non portable, quand le besoin de portabilité ne se fait pas sentir. Et il y a pleins de cas où il ne se fait pas sentir : il est de toute façon toujours possibler plus tard de résoudre ce problème en faisant ce travail supplémentaire, mais l'avantage c'est qu'on est pas obligé de le faire directement.

La situation pour Mono est même moins avantageuse que pour Java car .net facilite l'utilisation de bibliothèques natives depuis du code alors que pour Java c'est très fortement déconseillé.
C'est effectivement une des grosses différences philosophiques entre .NET et Java. Java propose de réinventer la roue pour qu'elle soit portable, alors que .NET propose de ne pas perdre du temps et réutiliser l'existant.

Mais c'est un faux débat de dire que Mono a plus de difficulté que une implémentation de l'environnement Java : Mono doit effectivement porter des API natifs, soit en les écrivant, soit en utilisant d'autres API d'une autre plateforme. Mais pour Java on a le même problème : il faut réinventer la roue et recoder. Même inconvénients. Sauf que la solution .NET laisse plus de liberté, notamment lorsque le multi-plateforme n'est pas une priorité.

Tu vois dès que .NET est sorti, il était possible d'utiliser DirectX. Au même titre que OpenGL ou autre. En Java celà a mis combien de temps ? Tout celà parcque Sun préfère la portabilité à la réutilisation. C'est dommage car .NET propose un meilleur compromis : tu veux réutiliser du code sans perdre de temps ? C'est facile, on vous propose tous les outils adéquates dans le langages, et on vous y encourage. Vous voulez porter votre application ? Faites comme en Java, et réinventer la roue, on vous y encorage également.

Autant Java, langage des années fin 90, a les circonstances atténuantes, autant C#, apparue au 21e siècle, n'a aucun pardon pour être aussi "pauvre" comme langage dit objet
En quoi C# est-il pauvre ?

l'informatique évolue très vite et si les gens ont des idées, pkoi ne pas les utiliser ?
Justement, et je trouve dommage que Sun, pourtant dans une position très favorable, n'en profite pas pour justement faire germer des idées : non là ils se contentent de copier, et laisse les autres innover. C'est pas vraiment grâce à celà que l'informatique va évoluer, rien ne vaut l'innovation.

Tu devrais lire les différents documents présentant le JCP sur le site officiel.
Justement, c'est ce que j'ai fait : pourtant ce que je dis est parfaitement vrai :
"Participation as a Member requires you or your organization to sign the Java Specification Participation Agreement (JSPA). The JSPA is a one-year, renewable agreement between you and Sun Microsystems, Inc."
Même si Sun ne contrôle pas les décisions à l'intérieur de l'organisation, c'est Sun qui décide au cas par cas qui a le droit de rentrer ou non. Mais bon, ton commentaire semble plus pertinent, et pourtant tu ne démontres en rien mon affirmation. (elle ne me contredis pas, tes propos étant également exacts)

On se retrouve monsieur Traumat, j'ai justement pris le soin de vérifier mes dires cette fois-ci, t'ayant aperçu dans les parages ;)

meme toi, tu peux participer :)
A condition que Sun veule bien. même si Sun n'est pas seul à décider, Sun "choisi" son entourage, l'indépendance du JCP est toute relative.

Pour les exceptions non checkées, tu peux lire l'avis du concepteur de C# sur le sujet : http://www.artima.com/intv/handcuffs.html(...) . On aime ou on aime pas, mais ses choix sont justifiés, et il faut reconnaître que celà pose pas mal de problème en Java les exceptions, même si le principe est louable.

Ce que je trouve vraiment dommage avec ce Java5, c'est qu'ils se sont contenter d'ajouter des fonctionnalités de C#, sans les reprendre toutes (poutant il y en a encore des intéressantes, peut être pour Java7 ?), et surtout sans rien ajouter d'innovant. Le pire, c'est qu'ils ont préférer sortir directement les generics dans une implémentation plus que contestable, hors ce genre de choix ne se fait pas à la légère, puisque difficile modifiable... ( http://www.artima.com/intv/generics.html(...) ) Franchement je trouve celà dommage, j'aurai largement préférer une saine émulation entre les 2 concurrents.

Enfin longue vie tout de même à cette plateforme, qui a comme gros avantage une certaine maturité et une communauté très active, autour de projets fédérateurs comme Eclipse.

En même temps si tu ne veux pas que ton oeuvre soit diffusé, suffit de ne pas la leur envoyer...

Oui oui il faut que tu racontes à ta carte mère qu'elle serait gentille d'essayer de booter sur ta clé USB :) (c'est pas possible avec toutes les CM cependant, surtout les anciennes)
Tu devrais trouver les fichiers qu'il te faut par ici :
http://download.fedora.redhat.com/pub/fedora/linux/core/test/2.91/i(...)

Sinon après celà marche comme une disquette de boot.

De la même manière que beaucoup préfère acheter leur PC chez le taïwanais du coin. C'est pas nouveau, et à mon avis beaucoup plus significatif que ceux qui achète un PC sous Linux dans ce but d'installer un Windows pirate.

Toujours le même problème : le noyau 2.6 ne rentre plus sur une disquette, voilà pourquoi il n'ya plus d'image de boot proposé pour disquette. Par contre tu en touveras certainement une un peu plus gros, que tu peux mettre sur une clé usb et booter dessus par exemple.

Tu peux aussi te contenter de graver le premier CD et de choisir une installation à partir du disque dur, le premier CD faisant office d'image de boot.

Franchement, peut être que celà vient de mon niveau intellectuel pas assez élevé, mais la question :
"Veuillez indiquer s’il vous plaît dans quelle mesure vous désirez faire ce que les groupes ci-dessous pensent que vous devriez réaliser."
demande trop de relecture.

Ben ma curiosité m'a amener à me demander quelle allait être leur réaction, donc je me suis logiquement mis à leur place.

Le brevet était passé en 96, là il a été annulé.

Oué enfin je voulais parler du point de vue de MS.