Tu pouvais pas résumer ? nan j'déconne :-) Mais ce qui est marrant, c'est que tu ne dis rien de nouveau, tous les points que tu cites ont été débattus plus bas... je vais donc tenter de te résumer les "contre-arguments".
Tout d'abord un intérêt de Mono que tu sembles oubliés : c'est une alternative à Java (je serais tenté de dire la seule qui vise les même objectifs), et rien que pour celà son existence est justifiée.
Ensuite tu rabaches que Mono est et restera une pâle copie de .NET sans intérêt basé sur des spécifications mouvantes...
Mono a 3 buts :
- proposer une implémentation complète des spécifications de l'ECMA.
- proposer un ensemble d'API destiné à la programmation sous Linux (GTK# & Co)
- proposer une compatibilité avec le framework .NET
Evidemment ce dernier point ne pourra jamais être parfait, mais l'ignorer, c'est ignorer le nombre important d'application ou de développeurs qui pourraient "migrer" (genre 300 serveurs à Munich).
Car il faut être clair, aucun outil adapté à .net "n'existe" en dehors des outils de MS (on mettra entre parenthèse les outils de borland, dont la strategie .net et leur implication sur le long terme dans cette plateforme n'est pas encore bien établie).
Eh eh eh... Donc déjà on met de côté Borland qui est pourtant une solution complète... Tu semble indiquer qu'il n'y a quasiment rien pour développer avec .NET à part VS... Et ? Il commence a fleurir un peu partout de nombreux outils, libre ou non, pour exploiter cet environnement, s'il n'y a pas de solution complète (à part si on enlève celles qui existent), c'est aussi dû à la relative jeunesse de .NET... On a mis combien de temps avant d'avoir un environnement potable pour Java ?
Partir sur Mono c'est avant tout faire une fleur à MS en favorisant une technologie entièrement controlée et dirigée par MS
.NET n'est présent que dans la compatibilité, sinon c'est juste le respect d'un standard établi, défini à l'ECMA par un consortium, et Mono a même fait des propositions pour des nouvelles spécifications... On peut dire que celà évolue en tout cas beaucoup plus vite que chez Sun...
La performance, la différence entre les perfs d'exécution d'une JVM et de la VM .net (celle disponible sur WindowsXX) sont négligeable. Sur windows, la VM de MS prend l'avantage
Si je te suis sous WindowsXX les perfs sont identiques mais celle de MS a quand même l'avantage... plutôt que d'aller chercher dans des considérations techniques hasardeuse, regarde plutôt comment les plateformes sont conçus : y'en a une qui a été conçu pour exécuter du code optimisé pour être interprété, et l'exécution commencera toujours par une interprétation; l'autre solution est conçu pour exécuter du code non interprété, il n'y a donc pas de bidouille pour essayer de déterminer la partie du code qu'il faut compiler en natif comme c'est le cas des JVM recentes... Et puis là le débat c'est linux, alors il faut plutôt comparer une JVM sous nux et Mono, je suis curieux de voir les premiers benchs (qui seront de toute façon des nids à troll comme tout bench qui se respecte)...
Pour finir, je dirais simplement que l'innovation ce n'est pas se contenter de copier ce que fais le voisin même si il le fait bien.
A défaut de pouvoir innover (parcque pas tout le monde peut se payer 10000 ingénieurs spécialisés R&D), il faut respecter les standards. Les développeurs ont besoins d'une alternative à Java, qui en comble certaines lacunes (notamment sur les langages, la gestion des versions), et qui de plus respecte les standards : c'est tout ce que fait Mono. le standard de l'ECMA est amené à être améliorer, comme c'est le cas par exemple pour les generics (si on prend la plateforme Sun ils ont choisi de faire des templates et de ne rien faire évoluer du tout)... On peut par exemple penser à des améliorations pour des langages comme OCaml ou encore pour les langages interprétés... En tout cas je trouve qu'il y a beaucoup plus d'avenir sur le long termes aux standards ouverts qu'aux standards de Sun...
Quelle est son utilité face à un éditeur qui peut à tout moment changer la donne ?
De toute façon les spécif sont ouvertes, ils ne peuvent changer la base sans prévenir, et sinon tant pis celà fait une plateforme performante... Et puis si tu prend le modèle de Windows : la plupart des problèmes de sécurité et stabilité viennent de la compatiblité avec les anciennes versions des programmes...Et pourtant ils assurent la compatibilité (évidemment certaines parties finissent par ne plus l'être) Sachant que Microsoft développe son prochain OS autour de .NET, il paraît clair que leur objectif ne sera pas de casser les normes existante en empêchant une compatibilité avec Mono... Sinon ils vont casser la compatibilité avec eux même... Et puis il faut aussi voir qu'il y a une demande de plus en plus forte de compatilibté entre Linux et Windows pour les applications, je crois surtout que Microsoft a voulu proposer une solution à ses clients pour répondre à leurs attentes (pour concurrencer Sun par exemple), et Mono est pour eux la preuve du bon fonctionnement de leur stratégie, c'est un atout supplémentaire, bref, aucune raison de casser la compatibilité.
Alors qu'a l'opposé un projet comme Classpath à besoin de beaucoup de ressources pour fournir lui une implémentation GPL intégrale d'une plateforme complètement définie et qui assurerait une réelle suprématie aux logiciels libres.
Alors là je comprend pas, tu dis de ne pas suivre Microsoft parcque il faut innover et toi tu proposes de copier la solution de Java...
Ta phrase suivante me fait encore plus rire... C'est vrai que le projet CLassPath a plus d'ambition que le projet Mono... Ah bon en quoi ? Sachant que Mono a quand même l'ambition de proposer une plateforme complète qui s'intègre à Gnome, que propose ClassPath de plus ?
Un point où on est d'accord : la portabilité. Evidemment c'est illusoire, à moins de concevoir une application dans cette perspective... Mais justement, tout ce qui est défini à l'ECMA, c'est l'équivalent du J2RE de Sun sans la partie liée aux interface graphiques, bref, il manque ce qui n'est pas portable, on ne va pas s'en plaindre. Celà forcera peut être certains développeurs à concevoir une interface différente pour chaque environnement, et d'en exploiter les possibilités spécifiques plutôt que d'utiliser un toolkit à la Java qui ne s'intègre nul part et auquel il manque beaucoup de fonctionnalités... Sinon ce sera toujours la même chose, quelque soit l'environnement : les applications seront dépendantes des API qu'elles utilisent, et seront supportés sur les plateformes où ces API sont implémentés...
Certains morceaux "facheux" genre COM+ ont été oubliés ;-)
Tu sais ce que c'est com+ ? Sous Windows il y a effectivement une certaine compatilibité avec com+, parcqu'il y a l'existant. Sous Linux aucun intérêt d'être implémenté.
PS : allez, n'oublies pas que Microsoft a fait parti du consortium qui a normalisé le XML et ses dérivés (schémas & Co), je te déconseille donc d'utiliser ces technos qui sont des standards sans avenirs, que Microsoft peut changer à tout moment...
[^] # Re: Mono SUCKS
Posté par TImaniac (site web personnel) . En réponse à la dépêche Sortie de Mono 1.0 beta 1. Évalué à 4.
Tout d'abord un intérêt de Mono que tu sembles oubliés : c'est une alternative à Java (je serais tenté de dire la seule qui vise les même objectifs), et rien que pour celà son existence est justifiée.
Ensuite tu rabaches que Mono est et restera une pâle copie de .NET sans intérêt basé sur des spécifications mouvantes...
Mono a 3 buts :
- proposer une implémentation complète des spécifications de l'ECMA.
- proposer un ensemble d'API destiné à la programmation sous Linux (GTK# & Co)
- proposer une compatibilité avec le framework .NET
Evidemment ce dernier point ne pourra jamais être parfait, mais l'ignorer, c'est ignorer le nombre important d'application ou de développeurs qui pourraient "migrer" (genre 300 serveurs à Munich).
Car il faut être clair, aucun outil adapté à .net "n'existe" en dehors des outils de MS (on mettra entre parenthèse les outils de borland, dont la strategie .net et leur implication sur le long terme dans cette plateforme n'est pas encore bien établie).
Eh eh eh... Donc déjà on met de côté Borland qui est pourtant une solution complète... Tu semble indiquer qu'il n'y a quasiment rien pour développer avec .NET à part VS... Et ? Il commence a fleurir un peu partout de nombreux outils, libre ou non, pour exploiter cet environnement, s'il n'y a pas de solution complète (à part si on enlève celles qui existent), c'est aussi dû à la relative jeunesse de .NET... On a mis combien de temps avant d'avoir un environnement potable pour Java ?
Partir sur Mono c'est avant tout faire une fleur à MS en favorisant une technologie entièrement controlée et dirigée par MS
.NET n'est présent que dans la compatibilité, sinon c'est juste le respect d'un standard établi, défini à l'ECMA par un consortium, et Mono a même fait des propositions pour des nouvelles spécifications... On peut dire que celà évolue en tout cas beaucoup plus vite que chez Sun...
La performance, la différence entre les perfs d'exécution d'une JVM et de la VM .net (celle disponible sur WindowsXX) sont négligeable. Sur windows, la VM de MS prend l'avantage
Si je te suis sous WindowsXX les perfs sont identiques mais celle de MS a quand même l'avantage... plutôt que d'aller chercher dans des considérations techniques hasardeuse, regarde plutôt comment les plateformes sont conçus : y'en a une qui a été conçu pour exécuter du code optimisé pour être interprété, et l'exécution commencera toujours par une interprétation; l'autre solution est conçu pour exécuter du code non interprété, il n'y a donc pas de bidouille pour essayer de déterminer la partie du code qu'il faut compiler en natif comme c'est le cas des JVM recentes... Et puis là le débat c'est linux, alors il faut plutôt comparer une JVM sous nux et Mono, je suis curieux de voir les premiers benchs (qui seront de toute façon des nids à troll comme tout bench qui se respecte)...
Pour finir, je dirais simplement que l'innovation ce n'est pas se contenter de copier ce que fais le voisin même si il le fait bien.
A défaut de pouvoir innover (parcque pas tout le monde peut se payer 10000 ingénieurs spécialisés R&D), il faut respecter les standards. Les développeurs ont besoins d'une alternative à Java, qui en comble certaines lacunes (notamment sur les langages, la gestion des versions), et qui de plus respecte les standards : c'est tout ce que fait Mono. le standard de l'ECMA est amené à être améliorer, comme c'est le cas par exemple pour les generics (si on prend la plateforme Sun ils ont choisi de faire des templates et de ne rien faire évoluer du tout)... On peut par exemple penser à des améliorations pour des langages comme OCaml ou encore pour les langages interprétés... En tout cas je trouve qu'il y a beaucoup plus d'avenir sur le long termes aux standards ouverts qu'aux standards de Sun...
Quelle est son utilité face à un éditeur qui peut à tout moment changer la donne ?
De toute façon les spécif sont ouvertes, ils ne peuvent changer la base sans prévenir, et sinon tant pis celà fait une plateforme performante... Et puis si tu prend le modèle de Windows : la plupart des problèmes de sécurité et stabilité viennent de la compatiblité avec les anciennes versions des programmes...Et pourtant ils assurent la compatibilité (évidemment certaines parties finissent par ne plus l'être) Sachant que Microsoft développe son prochain OS autour de .NET, il paraît clair que leur objectif ne sera pas de casser les normes existante en empêchant une compatibilité avec Mono... Sinon ils vont casser la compatibilité avec eux même... Et puis il faut aussi voir qu'il y a une demande de plus en plus forte de compatilibté entre Linux et Windows pour les applications, je crois surtout que Microsoft a voulu proposer une solution à ses clients pour répondre à leurs attentes (pour concurrencer Sun par exemple), et Mono est pour eux la preuve du bon fonctionnement de leur stratégie, c'est un atout supplémentaire, bref, aucune raison de casser la compatibilité.
Alors qu'a l'opposé un projet comme Classpath à besoin de beaucoup de ressources pour fournir lui une implémentation GPL intégrale d'une plateforme complètement définie et qui assurerait une réelle suprématie aux logiciels libres.
Alors là je comprend pas, tu dis de ne pas suivre Microsoft parcque il faut innover et toi tu proposes de copier la solution de Java...
Ta phrase suivante me fait encore plus rire... C'est vrai que le projet CLassPath a plus d'ambition que le projet Mono... Ah bon en quoi ? Sachant que Mono a quand même l'ambition de proposer une plateforme complète qui s'intègre à Gnome, que propose ClassPath de plus ?
Un point où on est d'accord : la portabilité. Evidemment c'est illusoire, à moins de concevoir une application dans cette perspective... Mais justement, tout ce qui est défini à l'ECMA, c'est l'équivalent du J2RE de Sun sans la partie liée aux interface graphiques, bref, il manque ce qui n'est pas portable, on ne va pas s'en plaindre. Celà forcera peut être certains développeurs à concevoir une interface différente pour chaque environnement, et d'en exploiter les possibilités spécifiques plutôt que d'utiliser un toolkit à la Java qui ne s'intègre nul part et auquel il manque beaucoup de fonctionnalités... Sinon ce sera toujours la même chose, quelque soit l'environnement : les applications seront dépendantes des API qu'elles utilisent, et seront supportés sur les plateformes où ces API sont implémentés...
Certains morceaux "facheux" genre COM+ ont été oubliés ;-)
Tu sais ce que c'est com+ ? Sous Windows il y a effectivement une certaine compatilibité avec com+, parcqu'il y a l'existant. Sous Linux aucun intérêt d'être implémenté.
PS : allez, n'oublies pas que Microsoft a fait parti du consortium qui a normalisé le XML et ses dérivés (schémas & Co), je te déconseille donc d'utiliser ces technos qui sont des standards sans avenirs, que Microsoft peut changer à tout moment...