Cette plateforme développée par Ximian se présente comme une alternative à la plateforme Java en proposant une implémentation libre de la plateforme .NET de Microsoft ainsi qu'un ensemble d'API destiné à la programmation objet sous GNU/Linux mais aussi Mac OS X et Windows. Les principaux objectifs et atouts de cette version sont :
- un environnement d'exécution comparable à celui de Java;
- le support de plusieurs langages de programmation dont C# et Java;
- un ensemble d'API orienté, Gnome et Mozilla;
- un serveur web pour la programmation dynamique de sites web;
- le support de plusieurs architectures matérielle : x86, SPARC et PPC;
- compatibilité avec Microsoft .NET 1.0 afin de faciliter la migration d'application Windows;
Très controversé, le projet Mono a été initié par Miguel de Icaza (un des fondateurs de Gnome) il y a maintenant 3 ans. Cette plateforme est déjà utilisée en production par Novell (qui a récemment racheté Ximian) et a entre autres permis à la ville de Munich de migrer 300 de ses serveurs sous GNU/Linux.
NdM : merci à Nicam, Romanito et D. Pierre pour avoir également soumis la news Présentation
Mono est une plateforme de développement complète basée sur une implémentation de la machine virtuelle et des API de base définis à l'ECMA (également normes ISO).
Mono propose entre autre :
- des API indépendants de l'environnement : sécurité, base de données, web services, XML, web forms;
- des API destiné à la programmation sous Linux et plus particulièrement Gnome : GTK#, Glade# Gecko#, Gst#;
- des API compatibles avec le framework .NET de Microsoft avec en preview les Winforms (utilisation de WineLib);
- un IDE (environnement de développement) : Monodevelop, avec notamment le support de la complétion de code qui fait le bonheur des utilisateurs de Visual Studio et d'Eclipse;
- un outil pour naviguer dans la documentation : Monodoc, qui a l'originalité de pouvoir être modifier par le programmeur qui peut ensuite envoyer automatiquement les modifications au CVS de Mono;
- un compilateur pour le langage C# qui est souvent présenté comme une évolution du langage Java avec une pincée de C++. Sans être une révolution, ce langage apporte de réels plus qui le rendent très agréable et puissant. Mono propose également un compilateur Javascript et VB.NET;
- une pré-version de C# 2.0 avec notamment le support des generics;
- un serveur web léger entièrement compatible avec le serveur ASP.NET qui permet d'utiliser n'importe quel langage de la plateforme pour générer des sites web dynamiques. Un module apache est également disponible.
Comparaison avec la plateforme Java :
Souvent comparé à Java, cette plateforme en partage de nombreux aspects techniques comme l'utilisation d'un langage intermédiaire (IL pour Intermediate Langage, équivalent du bytecode Java), le support d'application Web, la portabilité (toute relative cependant pour les deux plateformes) et un ensemble impressionnant d'API fournis en standards.
Mono se démarque cependant de la solution de Sun :
- le langage IL a été conçu pour être compilé et non interprété mais aussi pour supporter plusieurs langages orientés objet (C#, Java mais aussi VB.NET, Nemerle et Javascript, etc.);
- la plateforme décrit également un système facilitant l'interopérabilité entre les langages : le programmeur développe dans le langage de son choix mais sa bibliothèque pourra être utilisé par tous les langages de la plateforme, de manière transparente, sans créer de bindings souvent lourd et coûteux à utiliser et maintenir;
- des fonctionnalités supplémentaires comme les méta-données, la détection de débordement ou encore le versionning et la simplicité d'utilisation d'API écrits en C;
- la plateforme Java est une solution propriétaire alors que Mono est une implémentation libre des normes de l'ECMA qui garantissent entre autres l'impossibilité de faire valoir des brevets logiciels (seuls les WinForms, spécifiques à Windows et non normalisés à l'ECMA, sont susceptibles de poser des problèmes légaux).
Note : la plateforme est conçu pour des langages compilés et orientés objets. L'implentation de Python IronPython a cependant démontré qu'il était tout à fait possible d'obtenir des performances similaires avec un langage historiquement interprété. Il faut également noter que la plateforme est facilement interfaçable avec d'autres langages compilés de manière traditionnel comme le langage C.
Perspectives
Présentant de nombreux atouts face à son principal concurrent Java, Mono a toutefois l'handicap de la jeunesse, la documentation n'est pas complète (cependant il est possible d'aller consulter la documentation impressionnante du site MSDN de Microsoft ou encore la documentation de GTK), les performances sont encore en retrait par rapport à l'implémentation de Microsoft : il n'y a pas de comparatifs entre Mono et Java sous Linux, mais est-ce un mal étant donné l'objectivité et l'exhaustivité de ceux-ci ? De plus l'IDE n'est pas terminé, la compatibilité avec la version de Microsoft n'est que partielle et n'est prévue que dans les prochaines versions.
De nombreux débats ont lieu sur une éventuelle intégration de Mono au projet Gnome : en effet la fondation Gnome cherche a fournir une nouvelle plateforme qui éviterait notamment le support de plusieurs bindings pour différents langages tout en proposant un langage de plus haut niveau que l'actuel C. Reste le problème "philosophique" de l'intégration d'une technologie initialement développée par Microsoft. Mais il n'y a pas de réelle solution alternative qui soit libre et qui respectent des standards (DotGNU étant un projet similaire, avec les même avantages et inconvénients). Cette intégration n'est cependant pas à l'ordre du jour et il est sans doute nécessaire d'attendre que la plateforme Mono atteigne une certaine maturité.
Aller plus loin
- Le site officiel chez Novell (5 clics)
- La page de téléchargement (5 clics)
- Points communs et différences avec la plateforme Java (11 clics)
- Notes de version (10 clics)
- L'ancien site de Mono (3 clics)
# mouais
Posté par vrm (site web personnel) . Évalué à -10.
1,2,3 partez !
# ...
Posté par xsnipe . Évalué à 6.
Parce que de Windows à Linux (et du SDK officiel à Mono), il y avait de sacrés différences (il était d'ailleurs pas très conseillé de porter des applis multithread vers Mono à l'époque du 0.28...).
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 10.
[^] # Re: ...
Posté par xsnipe . Évalué à 2.
Sinon pour Monodevelop, faut-il avoir obligatoirement un kernel qui tourne à la NPTL pour pouvoir ne serait-ce que l'installer ?? Ou une bidouille est possible ??
[^] # Re: ...
Posté par Brice Carpentier . Évalué à 4.
Je m'occupe personnellement du paquetage Monodevelop pour ArchLinux [1] et puisque nous sommes en phase de transition 2.4 --> 2.6 (et que nous utilisons un système de paquetages binaires) nous ne pouvons pas fournir de glibc NPTL.
Monodevelop compile sans problème, par contre mono-debugger n'est pas utilisable.
Pour plus de renseignements au tout simplement pour en discuter, tu peux utiliser mon mail @dlfp
[1] http://www.archlinux.org(...)
Just my 2¢
[^] # Re: ...
Posté par -=[ silmaril ]=- (site web personnel) . Évalué à 2.
[^] # Re: ...
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
http://about.me/straumat
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 5.
[^] # Re: ...
Posté par Aldoo . Évalué à 1.
Et justement le "chef" du projet en question ?
[^] # Re: ...
Posté par TImaniac (site web personnel) . Évalué à 1.
[^] # Re: ...
Posté par xsnipe . Évalué à -2.
"Vous ouvrez le rideau ??"
"Noooon, je n'aime que Javaaaa !!"
"???"
Ok je ---------------------->{}
# Munich ?
Posté par Stéphane Traumat (site web personnel) . Évalué à 4.
Je n'arrive pas à trouver d'où vietn cette info. On m'avait dit que mono n'etait en production pour le moment que chez Novell.
http://about.me/straumat
[^] # Re: Munich ?
Posté par xsnipe . Évalué à 1.
[^] # Re: Munich ?
Posté par TImaniac (site web personnel) . Évalué à 7.
sinon pour l'utilisation, il y a une liste sur le site de novell des entreprises qui utilisent Mono et y contribuent :
http://www.mono-project.com/using/relnotes/1.0.html(...) (Current Users)
# Munich
Posté par Anonyme . Évalué à 1.
De quelle manière ?
[^] # Re: Munich
Posté par TImaniac (site web personnel) . Évalué à 3.
# Compilé ou pas ?
Posté par chl (site web personnel) . Évalué à 4.
- le langage IL a été conçu pour être compilé et non interprété
Je comprend pas bien ... il y a un IL (Intermediate Language), qui est compilé ! Ben s'il est compilé et non interpreté, c'est du code natif, alors ! Si c'est natif pourquoi l'avoir appellé IL ?
Quelqu'un m'explique mon erreur, je comprend pas :(
[^] # Re: Compilé ou pas ?
Posté par TImaniac (site web personnel) . Évalué à 6.
[^] # Re: Compilé ou pas ?
Posté par boubou (site web personnel) . Évalué à 10.
[^] # Re: Compilé ou pas ?
Posté par TImaniac (site web personnel) . Évalué à 1.
- Java a été conçu pour être inteprété et peut être compilé mais c'est parfait
- le code IL a été conçu pour être compilé (bah vi dès le départ on peut compiler le code IL contrairement au bytecode qui n'est pas conçu et donc optimisé pour) et peut être interprété mais c'est pas fait pour.
[^] # Re: Compilé ou pas ?
Posté par boubou (site web personnel) . Évalué à 9.
C'est faux. GCJ compile du java en code NATIF ! Il est de plus parfaitement possible de faire du JIT sans jamais interpréter le code. Je n'ai par regardé les sources de Kaffe, mais il me semble que sur une des anciennes versions, on pouvait avoir un JIT systématique. J'ai l'impression d'ailleurs que tu confonds la vérification du bytecode, étape présente aussi en IL, qui consiste effectivement en une interprétation abstraite du code, et l'exécution proprement dite.
Java a été conçu pour être inteprété
Ce n'est pas en répétant une chose fausse qu'on la fait devenir vraie. Je ne dit pas que la possibilité d'interprétation ne faisait pas partie du cahier des charges du bytecode JVM (alors qu'effectivement il est clair que cette possibilité ne faisait pas partie de celui de IL), mais d'autres éléments ont dirigé la conception.
bah vi dès le départ on peut compiler le code IL contrairement au bytecode qui n'est pas conçu et donc optimisé pour
Vu que tu affirmes avec beaucoup de force ce genre d'argument, j'aimerais que tu détailles. Ne te fais pas soucis, j'ai lu la spec de la machine virtuelle Java et la spec de LI, donc je connais un peu. Oui, IL a été conçu pour ne pas être interprété, donc quand on l'inteprete, ça rame. Maintenant donne moi un seul exemple, du même genre que celui que je donne plus haut, qui montre que le code obtenu après JIT est moins performant pour le bytecode de la JVM que pour le LI. Ou un exmple où le JIT du bytecode prendra significativement plus de temps que le JIT du LI...
[^] # Re: Compilé ou pas ?
Posté par hex . Évalué à 1.
Intéressant. Est-ce pour cette raison que .Net passe pour un très gros consommateur de resources CPU par rapport à Java ?
[^] # Re: Compilé ou pas ?
Posté par boubou (site web personnel) . Évalué à 4.
[^] # Re: Compilé ou pas ?
Posté par Staz . Évalué à 1.
# article concernant Mono sur Wikipedia : à compléter
Posté par j (site web personnel) . Évalué à 7.
# Et au niveau du FUD, il va comment, Mono ?
Posté par Nicolas Delsaux (site web personnel) . Évalué à 10.
Comparaison avec la plateforme Java :
Souvent comparé à Java, cette plateforme en partage de nombreux aspects techniques comme l'utilisation d'un langage intermédiaire (IL pour Intermediate Langage, équivalent du bytecode Java),
Jusqu'ici, tout va bien.
le support d'application Web, la portabilité (toute relative cependant pour les deux plateformes)
Là, ça dérape déja bien. Si .Net est supportée pour Linux, Windows et Mac, grâce à Mono, la liste des plateformes supportant Java (que ce soit en Open-source ou non), est quand même un peu plus longue, incluant par exemple des téléphones portables, des PDAs, des routeurs, des automates programmables, des robots mobiles, des cartes bleues, etc, ...
Mono se démarque cependant de la solution de Sun :
- le langage IL a été conçu pour être compilé et non interprété
On sent que c'est un avantage énorme, effectivement, surtout quand la plupart des JVMs supportent le JIT compiling, qui revient à disposer d'un code ... compilé.
mais aussi pour supporter plusieurs langages orientés objet (C#, Java mais aussi VB.NET, Nemerle et Javascript, etc.);
Le site http://www.robert-tolksdorf.de/vmlanguages.html(...) donne effectivement une liste fabuleusement courte de langages pouvant être compilés en bytecode, sans passer par le langage Java. Et, chose étonnante, tous ne sont pas orientés objet (je citerai par exemple Lisp, Logo, Prolog, Eiffel, Smalltalk, Ada, mais pas Cobol, malheureusement)
- la plateforme décrit également un système facilitant l'interopérabilité entre les langages : le programmeur développe dans le langage de son choix mais sa bibliothèque pourra être utilisé par tous les langages de la plateforme, de manière transparente, sans créer de bindings souvent lourd et coûteux à utiliser et maintenir;
Là, je m'avance, mais dans la mesure où tous ces langages sont compilés en bytecode, il doit être possible de faire facilement des binbdings de l'un à l'autre. je sais que c'est au moins possible pour JScheme, implémentation java d'un interpréteur Scheme permettant d'aller de l'un à l'autre et réciproquement.
- des fonctionnalités supplémentaires comme les méta-données,la détection de débordement
Ben .. ça existe depuis un bon moment en Java, à moins qu'on ne parle pas de la même chose. Quant aux metadonnées, elle sont présentes dans Java 1.5 (ou Java 5) qui sort ces temps-ci.
ou encore le versionning et la simplicité d'utilisation d'API écrits en C;
Tu peux être plus explicite sur la simplicité d'utilisation du C ? Ca me laisse pantois !
- la plateforme Java est une solution propriétaire
Non. le langage Java est libre, et son évolution est pilotée par le java Community Process, qui va parfois à l'encontre des souhaits de Sun. En revanche, effectivement, la machine virtuelle de Sun n'est pas libre, mais il existe un certain nombre de JVM libres, qui sont cependant en retard sur celle de Sun.
alors que Mono est une implémentation libre des normes de l'ECMA qui garantissent entre autres l'impossibilité de faire valoir des brevets logiciels (seul les WinForms, spécifiques à Windows et non normalisés à l'ECMA, sont susceptibles de poser des problèmes légaux)
Ca fait peut-être un peu Don Quichotte, mais pour moi cet article est symptômatique : sous couvert de défense du libre, on assiste là) à une attaque en règle contre Java, au profit de quoi , D'une plateforme dont le développement est piloté par Microsoft ? Super.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (site web personnel) . Évalué à 5.
la portabilité (toute relative cependant pour les deux plateformes)
Je sais très bien que la technologie Java est présente sur de nombreuses plateformes non supportées par Mono (pour le moment) mais bon. Ce que j'ai voulu dire c'est que de toute façon la portabilité est toute relative, et une application qui tourne sur un PC ne tournera pas forcement sur un PDA, même si c'est sur une JVM de Sun dans tous les cas. Pourquoi ? PArcque les API ne sont pas tous portés, que des API ne sont disponibles que sur certaines plateformes, etc. bref, il faut se limiter aux implentations de bases pour être 100% portable. d'où le terme "relative". (je rajouterai que la portabilité se fait en général au détriment de l'intégration dans l'environnement, autant graphiquement qu'ergonomiquement)
On sent que c'est un avantage énorme, effectivement, surtout quand la plupart des JVMs supportent le JIT compiling, qui revient à disposer d'un code ... compilé.
non non, jes JVM essai de faire du JIT, mais sont toujours obligé de faire de l'interprété pour commencer. D'ailleur le démarrage d'une appli Java donne une idée du travail que doit effectuer la VM derrière ;) Et celà ne change rien à ce que j'ai dit, le code IL est optimisé pour cette opération, qui est donc faite plus rapidement et sans passer par un système de profiling et d'interprétation.
Pour les implentation d'autres langages sur la plateforme Java, je suis tout à fait d'accord que celà est possible. Mais là encore, le bytecode n'a pas été conçu pour, et il existe de nombreuses limitations (le code IL de .NET et Mono en a également je te rassure) et surtout ne définit aucun standard d'implentation qui facile l'interopérabilité entre les langages (tu peux écrire une classe en ADA, l'instancier en Logo et la modifier en Perl sur une machine virtuelle Java ?). C'est ce qui fait toute la force de cette plateforme, on utilise une librairie et on se moque complètement du langage dans lequel il a été développé, sans faire aucun binding. (les bindings ne sont utiles que pour utiliser du code natif).
Ben .. ça existe depuis un bon moment en Java, [détection de déblordement]
ah bon tu peux faire ca en Java ? : http://www.dotnetguru.org/articles/CSharpVsJava.htm#_D%E9tection_de(...)
Pour les métas-données, effectivement elles existent désormais dans Java 5, d'ailleur cette version de Java n'est là que pour rattraper le retard sur C# quand on voit les nouvelles fonctionnalités et pour proposer une implentation bancale des generics. (je ne rentrerais pas dans le débat, c'est très bien expliqué ici : http://www.artima.com/intv/generics.html(...))
Tu peux être plus explicite sur la simplicité d'utilisation du C ? Ca me laisse pantois !
J'ai peut être mal formulé ma phrase, je voulais dire la simplicité d'utiliser un API écrit en C depuis la plateforme Mono, notamment en C#.
Tu considère l'ECMA comme étant dirigé par Microsoft (d'ailleur l'ECMA va parfois à l'encontre de Microsoft, un peu comme le java Community Process). Mais si j'en crois toutes les demandes faites à Sun pour libérer Java, j'en déduit qu'il n'est pas si libre que ça ;)
Et OUI, j'ai attaqué Java, parcque dans le domaine Java a plus ou moins le monopole (question plateforme complète) et Mono se présente comme une alternative libre qui respecte des standards, et qui apporte quelques innovations qui ont l'avantage de faire bouger les 2 parties, vive la concurrence et longue vie aux 2 plateformes.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par Nelis (site web personnel) . Évalué à 6.
C'est dommage car à part la partie comparaison avec Java la news est intéressante.
Je ne dis pas que toutes les news doivent être 100% objectives mais lorsqu'on rédige une news, je pense qu'il faut essayer de le rester un maximum ... C'est comme si on faisait une news sur Mandrake en terminant avec une comparaison biaisée avec Redhat. A part si on veut que ça parte en troll, je ne vois pas l'intérêt.
Je suis un 100% convaincu par Java, mais ça ne m'empêche pas de me tenir informer des news .NET et à l'occasion de l'essayer. Technologiquement cette plateforme à l'air très bien, moi c'est plutôt MS qui me fait peur la dedans. Bref, tout ça pour dire que ce n'est pas parce qu'on aime l'une des plateforme qu'on doit se sentir obligé de descendre l'autre ...
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (site web personnel) . Évalué à 3.
Pour la comparaison avec Java, j'ai surtout voulu montrer que c'était pareil, mais avec des petits plus qui justifiait l'existance de Mono. J'aurai dis : c'est pareil on peut faire la même chose, celà n'aurait montré aucun intérêt pour cette plateforme.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par Snark_Boojum . Évalué à 1.
Ensuite, je suis surpris que quelqu'un se vante d'avoir été partial. C'était pas "impartial" qui aurait dû être écrit?
Snark
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par boubou (site web personnel) . Évalué à 10.
Mais venons en à la news. D'abord, la comparaison avec Java est assez biaisée.
Je passe sur le FUD concernant IL auquel j'ai déjà repondu plus haut. Il est vrai par contre que certains éléments de CLI permettent d'implémenter plus efficacement certains langages que sur la JVM. Je pense en particulier au passage par référence qui n'existe pas dans la JVM. Cependant, de très nombreux langages tournent sur la JVM, donc ce n'est pas un si gros problème que ça. D'ailleurs, un JSR s'intéresse à ce problème et envisage de fournir plus de facilités pour l'implémentation d'autres langages sur la JVM.
Le passage sur les bindings est foireux. Oui, la notion de classe étant au centre de CLI, on peut appeler des classes C# en VB. Aucun problème pour faire l'équivalent en Java, cf Jython par exemple. D'autre part, il existe des outils qui construisent automatiquement les bindings JNI (un peu lourd il est vrai), cf en particulier la réalisation du binding opengl en Java (https://jogl.dev.java.net(...)).
Le versioning existe depuis longtemps en Java. Soit, il est moins évolué qu'en .NET, mais il existe. De même que les métadonnées en 1.5. Oui JNI est relativement lourd, mais cf au dessus.
Mais bien sûr, le plus scandaleux arrive ensuite, je cite :
"la plateforme Java est une solution propriétaire alors que Mono est une implémentation libre des normes de l'ECMA qui garantissent entre autres l'impossibilité de faire valoir des brevets logiciels (seuls les WinForms, spécifiques à Windows et non normalisés à l'ECMA, sont susceptibles de poser des problèmes légaux)."
Ba voyons.
Premièrement, ne sont normalisés par l'ECMA que la CLI, C# et sa bibliothèque système. On est loin des seuls WinForms. On doit par exemple ajouter ADO.NET et ASP.NET (cf http://www.mono-project.com/about/licensing.html(...)).
D'autre part dire que des normes l'ECMA qui garantissent entre autres l'impossibilité de faire valoir des brevets logiciels est un pur mensonge. Comme l'indique un des inventeurs de .NET qui est aussi un des auteurs des brevets associés (cf http://web.archive.org/web/20030609164123/http://mailserver.di.unip(...)), l'ECMA demande seulement des licences RAND, c'est-à-dire à un coût raisonnable et de type non discriminatoire. La notion même de coût raisonnable est incompatible avec l'open source et on ne parle pas ici des parties WinForms, ADO.NET et ASP.NET, mais bien de C# et de la CLI ! Microsoft s'est engagé à fournir des licences "royalty-free and otherwise RAND", ce qui ne veut pas dire grand chose. D'ailleurs, Novell n'a pas d'autorisation officielle de MS, à ma connaissance.
Je fais remarquer au passage que la plupart des organismes de normalisation demandent du RAND. Or, quand on voit qu'il faut officiellement payer pour pouvoir faire un player mp3 (qui est un standard internationnal), on peut avoir peur pour Mono.
Bref, .NET est donc au moins aussi propriétaire que Java qui est lui-même couvert par des brevets de Sun. Cependant, la communauté des détracteurs systématiques de Java semble oublier que Sun n'est pas le méchant dans cette histoire. Je tiens à rappeler que Sun a fait beaucoup pour le libre et pour les standards. Par exemple, RPC et NFS sont deux inventions de Sun. OpenOffice.org a été rendu possible par Sun qui contribue aussi au projet Gnome. Certains composants de la plate-forme Java sont officiellement open source et soutenus pas Sun. C'est le cas par exemple de Tomcat (implémentation de référence des JSP et des servlets), de l'api XML, ainsi que de ant (un projet de Sun à l'origine). Et qu'on ne vienne pas m'emmerder en me distant qu'il faut une JVM propriétaire pour les faire tourner, c'est faux, Tomcat et ant font justement partie des logiciels Java qui existent en version native grâce à GCJ et Classpath. Enfin, le JCP est un processus semi-ouvert (en tout cas beaucoup plus que ECMA) qui a voté une résolution permettant l'implémentation officielle des composants de la plate-forme Java en open source, avec même des aides financières de Sun pour passer les tests de compatibilité (cf Jonas qui est officiellement reconnu par Sun comme un projet qui vise à obtenir la certification J2EE 1.4).
Tout ça pour dire qu'avec l'histoire de Microsoft, je suis beaucoup plus soucieux pour l'avenir de Mono que pour celui des JVM open sources.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (site web personnel) . Évalué à 5.
reprenons la news.
Pour le code IL, tu as parfaitement argumenté plus haut. D'ailleur dans la news tu remarqueras que je n'ai donné aucun jugement, j'ai juste noté la différence d'objectifs lors de la conception des code intermédiaires. Enfin dans tous les cas, je penses honnêtement que celà est un point positif d'avoir un langage non orienté interprétation et conçu pour être multi-langages. J'ai d'ailleur bien précisé la limitation aux langages objets.
Pour les bindings, tu le dis toi même : c'est lourd. De toute façon sur les 2 plateformes c'est pareil : c'est utilisé pour wrapper du code binaire quelconque. C'est surtout un avantage pour fournir un API qui soit utilisable sans soucis par pleins de langages sans faire de bindings justement, comme le fait par exemple actuellement le projet Gnome qui doit maintenir plusieurs bindings. Et de ce point de vu là, la VM de l'ECMA est conçu pour et impose des règles d'inplentation, et c'est ce qui fait sa force. Je suis heureux de voir qu'il existe une initiative de ce genre du côté de Java, mais je n'en avais pas connaissance et ce n'est pas encore du concrêt dans les JVM actuelles. D'ailleur l'objectif de Sun est clairement de favoriser le langage Java comme langage universel.
Pour le versionning, on est bien d'accord que celui de Java est sans comparaison avec celui de .NET ou Mono.
Pour le problème de licence, etc. c'est possible que je n'ai pas du tout été partial. A vrai dire j'en ai tellement marre d'entendre dire que "Mono c'est mal parcque c'est une techno proprio et Java c'est bien c'est libre" que du coup j'ai peut être eu tendance à aller à l'opposé.
Pour les WinForms, j'ai précisé que c'était elles seules qui posaient des problèmes légaux actuellement. J'ai pas dit que c'était les seuls à ne pas être normalisé. C'est vrai que celà pouvait porter à confusion mais ce n'est pas volontaire, tu m'en vois désolé.
Pour les précisions de licence, je vais dans ton sens, tes propos étant exact.
Microsoft s'est engagé à fournir des licences "royalty-free and otherwise RAND", ce qui ne veut pas dire grand chose. D'ailleurs, Novell n'a pas d'autorisation officielle de MS, à ma connaissance.
Le fait que Microsoft se soit engager à ne pas fournir de licence discriminatoire indique clairement qu'il doit accepter que Novell puisse en acquérir s'il le souhaite (en respectant la licence évidemment), et c'est déjà ca. Ensuite, en dehors de ce débat, il y a les licences en soit, et d'après Icaza, ils n'ont rien trouvé dans ces licences qui puisse les géner.
Reste que je trouve l'ECMA plus ouvert que le consortium autour de Java, ou Sun aura toujours plus ou moins le dernier mot sur les principales direction de Java (c'est d'ailleur ce que Sun ne veut pas lacher, aillant peur de voir Java se faire forker).
Or, quand on voit qu'il faut officiellement payer pour pouvoir faire un player mp3 (qui est un standard internationnal), on peut avoir peur pour Mono.
Parcque c'est des normes ISO et parcque les licences mp3 sont explicitement payante, pas celles de C# & Co.
Enfin, tout celà pour dire que j'ai avant tout voulu présenter l'innovaiton technique de cette plateforme, et surtout le fait qu'elle soit une alternative face à Java. J'espère ne pas avoir dit trop de conneries, et j'ai voulu relativiser à la fin de la news. La partialité m'aurait peut être poussé à ne pas parler de Java du tout, mais il était pour vital d'avoir un point de comparaison pour se faire une idée de ce qu'est Mono, Java étant pour moi globalement équivalent dans les possibilités.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par imr . Évalué à 3.
Tu peux préciser ce point? Je n'ai pas trouvé dans les liens que tu donnes et j'aimerais en savoir plus.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (site web personnel) . Évalué à 3.
je cite l'article :
Dans le cadre de sa migration vers Linux, la municipalité de Munich (voir édition du 10 juin 2003) a ainsi exploité Mono pour migrer 300 serveurs utilisant ASP.Net.
Si certains ont d'autres sources je suis également intéressé.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par imr . Évalué à 2.
C'est effectivement interressant.
Un serveur qui fournit du ASP.Net, c'est si différent d'un ASP normal qu'il faille mono pour le migrer?
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par Anonyme . Évalué à 1.
Est-ce une bonne chose de voir des migrations vers ASP.net ?
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par Black Fox . Évalué à 2.
Ils avait du ASP.Net et voulait le garder tout en passant à Linux, pour cela ils se sont servis de Mono.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par 007 . Évalué à 1.
> C'est surtout un avantage pour fournir un API qui soit utilisable sans soucis par pleins de langages sans faire de bindings justement
C'est peut-être une question bête mais là je ne comprends pas.
Prenons python.
Pour utiliser python avec Gnome, il me faut un binding vers C.
Pour utiliser python avec Gnome qui s'appuie sur C#, il me faut aussi un binding vers C# (la machine virtuelle).
C'est quoi la différence.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (site web personnel) . Évalué à 3.
Ben, en l'état actuel, si tu utilises le python de base, il n'y en a pas. Maintenant si tu utilises un compilateur python (ou un interpréteur) qui a pour cible le code IL, tu peux utiliser tous les API de Mono, sans faire aucun bindings. Si tu fais un API que tu écris en Python qui cible le IL, ton API pourra être utilisé dans tous les autres langages qui cible le code IL, sans faire de bindings.
Après si tu veux utiliser un API écrit en code natif, par exemple en C depuis Mono (dans le langage que tu veux), tu fais un seul binding pour Mono (comme c'est le cas pour GTK ou Gecko par exemple), et le binding sera valable pour tous les langages. Bref, tu fais un seul binding pour Mono si ton code est natif (parcque tu veux le faire en C, que c'est vraiment du bas niveau système, etc.) sinon il n'y a pas besoin de bindings, pour les langages qui ciblent le code IL.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par 007 . Évalué à 1.
Chaque librairie en IL (faite à partir de n'importe quel langage) peut-être utilisé par tous les autres langages. S'il n'y a qu'un langage c'est sans intérêt (d'où mon raisonnement limite stupide en ne pensant qu'à python).
Sur le papier c'est très interessant mais dans la réalité...
Par exemple l'API C de gnome en IL n'est pas d'un grand intérêt pour celui qui veut faire du C# ou du C++. Pour C++, mieux vaut utiliser gnomemm (surtout que C++ peut "attaquer" directement API C de gnome).
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par 007 . Évalué à 1.
Je fais du C et du C++ et chaqu'un à ces avantages. Le tout objet est parfois lourdingue à faire.
Le propos n'était de dire que l'API C de Gnome était géniale mais simplement que l'API C en IL, reste l'API C et ne permet pas de tirer avantage du C# ou du C++.
Donc pour Gnome il faut aussi faire un api orienté objet pour que l'utilisation d'IL soit intéressant pour les développeurs C++ ou C# ou python, etc...
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (site web personnel) . Évalué à 2.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par 007 . Évalué à 0.
L'API est orienté objet. Mais ça reste codé en procédurale. Je pinaille...
> D'ailleur les binds vers Mono sont fait de manière automatique grâce à ca.
Là j'ai peut-être raté un truc. En fait (au moins pour Gnome/gtk+ qui est aussi orienté objet) lorsque le "binding" pour IL est fait, il est fait en essayant d'exploiter au maximum IL. Donc normalement ce n'est pas l'API C qui est porté de façon "bête" (des fonctions, des structures, des constantes, etc), mais plutôt l'orientation objet de l'API (quelque chose de moins "bas niveau" que l'API C et qui exploite mieux les capacités de l'IL). Ça fait plus de boulot mais il n'est fait qu'une fois.
Heureument que Gnome est déjà orienté objet...
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (site web personnel) . Évalué à 2.
et comme tu dis, heuresmeent que GNome est orienté objet :)
[^] # Quel avenir pour mono ?
Posté par Hive Arc . Évalué à 7.
AMHA, croire que MS va laisser copier leur plateforme de référence sans broncher est faire preuve de crédulité vu les sommes investies en R&D et marketing par MS sur la marque.
Tant que mono sert à MS pour faire avaler la pilule du "multi-plateforme" concernant .net, il n'y a aucun problème. En ça, je serais interessé par connaitre les motivation exactent de DeIcaza, vu ses relations troubles avec MS.
Concernant le "pseudo" standard ECMA, franchement MS est de mauvaise fois, car non seulement elle n'a soumis qu'une partie de la spec de .net, mais ensuite, il faut rappeler lorsque Java avait été poussé à l'ECMA les arguments qui lui avait valu d'être rejeté ... ici on se rend compte des pressions qui ont du se produire en coulisse dans les deux cas. Je ne reviendrait pas non plus sur la soumission de Java à l'ISO, qui était plus du domaine de la série Dallas ;-) Ce sont ces lobying répétés de MS qui ont obligé Sun a créé un procéssus de standardisation des specs Java décorrélé de toute influence de MS.
De plus, pour rappel, MS était il y a qqe années à fond impliqué dans Java, Visual J++ étant l'IDE n°1 et JView la VM la plus performante de plus l'ensemble des API de windows était disponible via des API Java !!! Bien sur, ensuite est arrivé la "crise" lorsque MS a essayé d'introduire une spécificité à Java pour le rendre interdépendant avec windows.
Concernant .net, toute personne qui connait les deux mondes sait bien qu'il n'y a que peu de différence. Et que basculer de l'un à l'autre est une question de jour.
Je préciserait simplement que ton point sur la généricité est ridicule, regarde les débats et JSR dans les forums Java et regarde quand MS a commancé à en parlé ... et ensuite reviens discuter serieusement (vraiment ce point prouve particulierement que tu ne fais que répeter les publi-annonces de MS).
La seule question pertinente pour moi est la pérénité des deux solutions.
Soyons honnete, personne de sensé dans le monde de l'entreprise ne fera de mono, car il y aura toujours un point valable pourdire que .net est mieux ... entre un obscur groupe, et Microsoft, croit-tu que les DSI et autres décideurs vont selectioné ? En conséquence tout ce que va faire mono, c'est apporté de l'eau au moulin de MS et jouer contre le camp du libre. Car soyons encore honnete, la notion de opensource dans l'entreprise est souvent synonime de "gratuit" et pas vraiment de liberté.
Si vraiment tu es un apotre du libre, je te conseille vivement de rejoindre la FSF et de consacrer ton temps au projet Classpath dont le but est de passer le TCK Java et fournir une implementation intégrale de la spec J2SE. Et là au moins pas de risque de voir un quelconque éditeur balayer ton ouvrage d'un simple revers de la main (non, même pas Sun, pour t'en convaincre, je te propose de relire les licences appliqués à J2SE 5.0 par exemple, ainsi que la position claire et définitive sur les brevest potentiels autours de Java).
Oui, vraiment je pense que l'avenir de mono est assez sombre. Quand à celui de .net il est assuré ... enfin, du moins pour le nom, quand au framework, les API de longhorn sont sur le point de le mettre en pièce ....adieu veaux, vaches et winforms ;-)
[^] # Re: Quel avenir pour mono ?
Posté par TImaniac (site web personnel) . Évalué à 2.
Pour les ClassPath, elles sont accessibles depuis Mono, ce n'est donc pas du tout incompatible.
Pour ce qui est de l'avenir de Mono, seul l'avenir nous dira ce qu'il en est.
PS : pour la genericité, penses aux scénarios qui font appel à la reflexion du code à l'exécution, juste pour le fun... Ou tiens fait une classe generique qui accepte des types primitifs sans sacrifier les perfs (sachant que ca va wrapper directement la class correspondante)
[^] # Re: Quel avenir pour mono ?
Posté par Anonyme . Évalué à 1.
Des migrations vers de l'ASP(.net) ? Je m'interroge sur les détails de la migration.
Par ailleurs, sur le sens stratégique de Mono, le fait que le choix fut fait ne prouve rien. De Icaza à aussi choisit de confier le développement du gestionnaire fichier GNOME à Eazel et de créer une boite pour diffuser GNOME : au bilan, ces choix stratégiques furent vites balayés, remplacés par d'autres objectifs. Pour avoir preté un peu d'attention aux décisions de ce type, ses déclarations foudroyantes et contradictoires, sans parler des ses retournements de vestes (faut être fort pour reprocher à KDE la dépendance à Qt sous QPL et faire 2 ans après du code proprio - la QPL c'est de la rigolade par comparaison), je ne vois pas quelles preuves de fiabilité sont sur la table.
Peut-être que Mono apportera beaucoup au libre. J'espère pour Mono que ce n'est pas uniquement un tremplin pour certaines personnes. Mais pour le moment, j'observe, curieux.
[^] # Re: Quel avenir pour mono ?
Posté par Pinaraf . Évalué à 1.
[^] # Re: Quel avenir pour mono ?
Posté par ftp . Évalué à 4.
En changeant quelques mots, ça marche aussi
Soyons honnete, personne de sensé dans le monde de l'entreprise ne fera de gcj, car il y aura toujours un point valable pourdire que la jvm de sun est mieux ... entre un obscur groupe, et Sun, croit-tu que les DSI et autres décideurs vont selectioné ? En conséquence tout ce que va faire gcj, c'est apporté de l'eau au moulin de sun et jouer contre le camp du libre. Car soyons encore honnete, la notion de opensource dans l'entreprise est souvent synonime de "gratuit" et pas vraiment de liberté.
Donc javasapusaipalibre, puisque gcj ne compte pas il joue contre le libre...
s/é/er/ sur les trois quarts du texte aussi ;)
[^] # Re: Quel avenir pour mono ?
Posté par 007 . Évalué à 1.
Y a comme un goût de déjà vu. Genre :
- "Soyons honnete, personne de sensé dans le monde de l'entreprise n'utilisera Windows NT ou SQL Server, etc"
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par Nicolas Delsaux (site web personnel) . Évalué à 3.
Je sais très bien que la technologie Java est présente sur de nombreuses plateformes non supportées par Mono (pour le moment) mais bon. Ce que j'ai voulu dire c'est que de toute façon la portabilité est toute relative, et une application qui tourne sur un PC ne tournera pas forcement sur un PDA, même si c'est sur une JVM de Sun dans tous les cas. Pourquoi ? PArcque les API ne sont pas tous portés, que des API ne sont disponibles que sur certaines plateformes, etc. bref, il faut se limiter aux implentations de bases pour être 100% portable. d'où le terme "relative".
S'il est vrai qu'actuellement J2SE signifie portable, n'oublions pas que les PDAs modernes ont déja des processeurs de plus de 400 MHz, ce qui fait plus que ble PC sur lequel j'ai commencé le Java. A mon avis, il sera bientôt faux de dire que la portabilité est restreinte, à moins bien sûr que ce ne soit le fait volontaire des fabricants de ces engins qui préfèrent brider les utilisateurs en imposant une méthode de téléchargement d'applications payante (ce qui risque fortement de se produire).
(je rajouterai que la portabilité se fait en général au détriment de l'intégration dans l'environnement, autant graphiquement qu'ergonomiquement)
C'est quoi cet argument à la noix non justifié ?
Je croyais avoir définitivement anéanti l'argument "Java c'est moche" ! Bref, piqûre de rappel : http://java.sun.com/products/jfc/tsc/sightings/(...) Et je connais certaines autres applis qui pourraient facilement y figurer ...
En plus, le JDK 1.4.2 amène d'importantes novueautés au niveau L&F qui mettent les applis Java au même niveau que les applis natives.
non non, jes JVM essai de faire du JIT, mais sont toujours obligé de faire de l'interprété pour commencer.
Tu as une preuve de ça ?
D'ailleur le démarrage d'une appli Java donne une idée du travail que doit effectuer la VM derrière ;)
Vachement, ouais, on est toujours dans le même niveau d'argumentaire. La machine virtuelle prend du temps à se lancer, car avant de lancer le programme, elle doit instancier le monde Java : Object, System, Class, ClassLoader et tous leurs petits potes. Après, une fois que l'appli se contente de tourner, ça va mieux. C'est d'ailleurs pour ça que certains JCP s'intéressent à des JVMs serveurs qui ne s'arrêteraient pas vraiment ...
Et celà ne change rien à ce que j'ai dit, le code IL est optimisé pour cette opération, qui est donc faite plus rapidement et sans passer par un système de profiling et d'interprétation.
Je crois que tu as eu assez d'arguments clairs à ce sujet ...
Pour les implentation d'autres langages sur la plateforme Java, je suis tout à fait d'accord que celà est possible. Mais là encore, le bytecode n'a pas été conçu pour, et il existe de nombreuses limitations (le code IL de .NET et Mono en a également je te rassure) et surtout ne définit aucun standard d'implentation qui facile l'interopérabilité entre les langages (tu peux écrire une classe en ADA, l'instancier en Logo et la modifier en Perl sur une machine virtuelle Java ?).
Déja, le faire, tout court, ça me paraît peu évident ;-)
En revanche, je l'ai déja dit, mais par exemple JScheme fournit de très efficaces moyens d'utiliser le Java en Scheme et réciproquement : http://jscheme.sourceforge.net/jscheme/doc/javaprimitives.html(...)
ah bon tu peux faire ca en Java ? : http://www.dotnetguru.org/articles/CSharpVsJava.htm#_D%E9tection_de(...))
Non, mais d'un auitre côté, quand tu mets un int dans un byte, il faut quand même être un minimum muni d'un cerveau.
Et puis, ce que j'aime bien dans cet article, c'est à quel point il démontre les différences entre Java et C#. C'est effarant de voir à quel point Microsoft a su évoluer depuis la base du VB pour produire une plateforme de qualité ;-)
Pour les métas-données, effectivement elles existent désormais dans Java 5, d'ailleur cette version de Java n'est là que pour rattraper le retard sur C# quand on voit les nouvelles fonctionnalités et pour proposer une implentation bancale des generics. (je ne rentrerais pas dans le débat, c'est très bien expliqué ici : http://www.artima.com/intv/generics.html(...(...)))
Pas besoin, les genercis sont une erreur, une stupidité innomable dont java n'avait pas besoin. En revanche, des choses comme les annotations, l'autoboxing qui apparaît enfin et le remplacement de StringBuffer me paraissent plus intéressantes, mais c'est un autre sujet ...
Tu considère l'ECMA comme étant dirigé par Microsoft (d'ailleur l'ECMA va parfois à l'encontre de Microsoft, un peu comme le java Community Process). Mais si j'en crois toutes les demandes faites à Sun pour libérer Java, j'en déduit qu'il n'est pas si libre que ça ;)
Tu me parles des demandes faites par IBM à SUN pour libérer sa machine virtuelle ? Est-ce que tu es naïf au point de ne pas voir la grossière manoeuvre stratégique ? Si IBM voulait réellement contribuer à une JVM libre, ils pourraient reprendre le projet GNU Classpath, ou d'autres (comme Blackdown, je crois), plutôt que de mendier à Sun la libération de leur travail.
Soyons sérieux cinq minutes. Si tu veux parler des gros sous entre IBM, Sun et Microsoft, pas de problèmes, mais là, ce sera DIFFICILE de ne pas marcher dans le FUD.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
Là je serais curieux de connaitre tes arguments pour étayer ça.
Vu d'ici, c'est plutôt un cas classique de : "si mon langage à moi que j'aime a pas cette feature, ben c'est que cette feature c'est que d'la merdeuhhh".
Et sérieusement, as-tu seulement lu cette série d'interview de Hejlsberg ? Le gars est impressionnant par son pragmatisme et sa franchise.
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (site web personnel) . Évalué à 2.
Je croyais avoir définitivement anéanti l'argument "Java c'est moche" !
Désolé, mais ce qui fait la spécificité de chaque environnement (Windows, Gnome, KDE ou MacOS X), c'est surtout et avant tout leur ergonomie. L'emplacement des boutons, la disposition des menus, leurs noms, la "gueule" des fenêtre de base (ouverture/fermeture de fichier, "about", propriétés), tout celà est différents selon l'environnement. Et Java ne s'intègre nulle part.
Sans parler de ces différences qui apparaîtront toujours, il y a aussi les problèmes liés à la factorisation des points communs entre les environnements. Je prend pour exemple un contrôle très simple : l'arbre. Son utilisation et ses possibilités sont totalement différentes d'un toolkit à l'autre. Java ne permettra jamais d'utiliser les particularités de chacun (en tout cas pas pour le programmeur), ce qui est plus que dommage.
Voilà pourquoi je dis que graphiquement et ergonomiquement surtout, Java ne s'intègre nulle part. C'est les inconvénients de la portabilité.
Tu as une preuve de ça ?
désolé j'ai plus mes sources, mais tu as une preuve du contraire ?
Non, mais d'un auitre côté, quand tu mets un int dans un byte, il faut quand même être un minimum muni d'un cerveau.
C'est un exemple tout con. Parfois il n'y a qu'à l'exécution que l'on connaît le vrai type qui sera la cible de l'opération. Et de toute façon le compilateur est justement là pour éviter le maximum de bêtises liées aux bourdes du cerveau.
En revanche, je l'ai déja dit, mais par exemple JScheme fournit de très efficaces moyens d'utiliser le Java en Scheme et réciproquement
C'est bien, c'est un bon exemple, mais ce n'est pas normalisé... le compilateur C# est par exemple capable de vérifier qu'un API respecte bien ces normes justement.
Pas besoin, les genercis sont une erreur, une stupidité innomable dont java n'avait pas besoin.
C'est pas parcque toi tu trouves celà inutile qu'il ne faille par répondre aux attentes de millions de programmeurs... T'as jamais eu envie de faire une collection typée dans ta vie de programmeur ? Tu n'as jamais utilisé un squelette et fait des copié-collés et remplacé les types ? Evidemment la solution adoptée par Java ne change rien du tout au niveau de l'exécution (vérification, etc.) mais ce n'est pas pour celà que les generics sont inutiles. Et rien ne t'oblige à les utiliser...
Pour la dernière partie, je ne veux pas faire de FUD dans un sens ou autre. CE que je constate c'est que Microsoft a fait l'effort de normaliser la plateforme .NET et les API de base. l'ECMA me semble plus ouvert aux évolutions que le Java Community Process, mais c'est mon avis. Mais en dehors de celà, je crois que le plus important c'est surtout qu'il y est une réelle concurrence entre les 2 plateformes, Java 5 est un exemple flagrant d'émulation entre les 2 parties (bien que j'aurai aimé que Java 5 intègre des nouveautés plutôt que de se contenter de rattraper son adversaire).
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par logout . Évalué à 1.
Il me semblait que sous MacOSX mono utilisait X11 pour l'affichage ?
Si c'est bien le cas on ne peut pas non plus parler d'integration la...
[^] # Re: Et au niveau du FUD, il va comment, Mono ?
Posté par TImaniac (site web personnel) . Évalué à 2.
# "Thème" de la dépêche
Posté par j (site web personnel) . Évalué à 2.
"Technologie" me parait quand même plus approprié...
# Intense réflexion...
Posté par sirrus . Évalué à -5.
C'est le nouveau mono qui lave plus blanc que blanc le tout crado ? Ooohhhhh....
# Usine à languages
Posté par philou (site web personnel) . Évalué à 6.
L'industrie fut une usine à copeaux !
L'informatique est une usine à languages !
Vous me direz que chaque domaines a ses modes :
- le management : le dernier concept, cette source de la productivité tant attendue,
- la politique : la décision courageuse qui va faire baisser le chômage (du moins officiellement),
- l'informatique : le dernier language, la grande fusion des paradigmes.
C'est symptomatique : sur ma babasse, la principale occupation de mon disque dur est consacrée aux langages, aux bibliothèques, aux compilateurs et autres interpréteurs.
Comment reconnaissons-t-on un informaticien (à une utilisateur avancé) ? Aux nombres des langages connus ! Quelle est la principale source financière du libre ? Les bouquins traitant des langages/bibliothèques informatiques.
Quelle est la consécration d'un informaticien ? Pondre un language ! La réalisation d'une bibliothèque, d'un interpréteur ou compilateur font néanmoins très bien sur un cv.
Question à 100 boules : Quelle est le prochain language qui fera tout péter ? ( suite de l'épisode dans 4-5ans).
Séquence recul épistémologique ...
Je ne dit pas que le diversité en soi pose problème. Loin de moi l'idée de coder uniquement en lisp (arg !) suite à un élan passéiste. J'use (souvent simultanément) moi même de beaucoup de language (prochaine conquète ocaml).
Tout simplement, je me pose juste la question sur la signification d'une telle diversité. Ainsi que de ce qu'il en reste après 10 ans ?
[^] # Re: Usine à languages
Posté par kesako . Évalué à 5.
c'est dire ...
[^] # Re: Usine à languages
Posté par Snark_Boojum . Évalué à 4.
Snark
[^] # Re: Usine à languages
Posté par xavier . Évalué à 0.
[^] # Re: Usine à languages
Posté par Ontologia (site web personnel) . Évalué à 2.
Lisaac. Premier langage objet à prototype compilé multiplateforme.
Plus d'objet à classe, fini les héritages statiques. Langage bas, moyen, haut niveau, aussi voire plus performant que du C, grace à un algo novateur qui analyse ton code et supprime les étapes inutiles
(ie. si tu fait une fonction : toto{ a=7; b=9;c=a+b; return c;} il va analyser que ça sert à rien et va remplacer la séquence par 16 et le coller 16 quand tu appelera toto)
(http://www.loria.fr/serveurs/IsaacOS/language/lisaac_overview.zip(...) pour le pdf de présentation
mais vaut mieux commencer par http://www.loria.fr/serveurs/IsaacOS/divers/project_st_overview.zip(...) pour bien comprendre)
Pour le reste je suis assez d'accord avec toi. Le problème d'un entreprise est de diminuer les coûts...
Donc, à la recherche du saint langage qui nous fait gagner du temps.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Usine à languages
Posté par Alex . Évalué à 3.
Mauvais exemple je pense, tout bon compilo fait déjà ça
J'ai survolé la doc (assez longue), et il semble y avoir quelques concepts interessants, que l'on retrouve parfois dans d'autre langage, avec l'avantage qu'il translate en C pour compiler en natif par la suite (comme ocaml je crois). Mais bon je trouve qu'on est loin de pouvoir dire qu'il fera tout péter... mais promis je lirai mieu la doc
[^] # Re: Usine à languages
Posté par Ontologia (site web personnel) . Évalué à 4.
#include <stdio.h>
int a,b,c;
int main()
{
a=8;
b=7;
c = a+b;
return c;
}
gcc -S test.c -O3 -ggdb -o test.asm
.LCFI1:
pushl %eax
pushl %eax
.loc 1 11 0
movl $15, %eax
.loc 1 6 0
andl $-16, %esp
.loc 1 7 0
movl $8, a
.loc 1 8 0
movl $7, b
.loc 1 9 0
movl $15, c
.loc 1 11 0
leave
ret
CQFD :)
PS : en gcc sans -O3, il fait le calcul
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Usine à languages
Posté par Pascal Terjan (site web personnel) . Évalué à 2.
[^] # Re: Usine à languages
Posté par Guillaume Laurent (site web personnel) . Évalué à 1.
[^] # Re: Usine à languages
Posté par Anonyme . Évalué à 1.
[^] # Re: Usine à languages
Posté par Guillaume Laurent (site web personnel) . Évalué à 0.
Après tu as toujours des gars qui préfèrent l' "ancien" langage et trouvent le nouveau pleins de features inutiles|dangereuses|lourdes etc... Ça ne loupe jamais, et le fait que ça se répète pour chaque nouveau langage prouve bien que leur réaction est avant tout émotionelle ("c'est mon langage qu'est le mieux et je changerai pas, na d'abord"), et non rationelle.
(il y a aussi ceux qui veulent à tout prix utiliser le nouveau langage dans des situations ou il ne convient pas du tout, par ex. quand Java est arrivé, il y avait un thread récurrent sur comp.emacs à propos de l'opportunité de ré-écrire Emacs en Java :-).
# Mono...tonie
Posté par Raoul Volfoni (site web personnel) . Évalué à 8.
(la même réflexion s'applique à .Net )
Quelques questions en vrac:
- Où est le serveur d'application de Mono?
- Est-ce que Com+ va être porté sous *nix?
- Existe-t-il des alternatives à Com+ pour Mono?
- Si oui quels sont les services offerts pour les composants? (sécurité, transactions, messaging, ...)
Tout ça me rappelle la propagande Microsoftienne lors des dev days où une démo bidon est faite sur un BSD pour 'prouver' que .Net est portable. Et tous les béni-win-win de faire Hooooo devant une bête boite de dialogue affichant un bouton OK!
Java n'est surement pas la panacée et il subsiste certainement des lacunes. Mais avant de combler le fossé galactique qui le sépare des autres environnements de devt d'entreprise, m'est d'avis que l'informatique aura beaucoup changé...
[^] # Re: Mono...tonie
Posté par TImaniac (site web personnel) . Évalué à 2.
Question équivalent, je penses que Corba est les même objectifs. Mais avec Mono, plus de problème de partage d'objet et d'exposition d'interface... Logiquement il n'y a plus besoin de COM & Co... sauf évidemment question compatibilité avec l'existant. C'est d'ailleur pour celà que sous WIndows cette compatibilité existe. Pas sous Linux... mais sachant que les composants COM n'existe pas sous Linux, c'est pas tellement utile à mon sens.
Sinon question messaging, transactions & co, voir doc du framework .NET.
Par contre de l'aveu même de De Icaza, il y a encore des efforts à faire du côté des API "spécial entreprise".
[^] # Re: Mono...tonie
Posté par Raoul Volfoni (site web personnel) . Évalué à 6.
Oulà. Corba est un bus, pas un serveur d'applis même si leurs services se ressemblent.
Gnnnn? Qu'est-ce que c'est que cette histoire? Qui parle de COM? Moi je demande juste comment sont hébergés les composants? Qui se charge de leur gestion, de leur allocation, des pools, de la sécurité, des accès concurrents, des messages pour les broker, de la répartition de charge, etc...
Il ne faut surtout pas confondre COM ou DCOM qui sont des technologies propres à des composants (dont la compatibilité est assurée dans .Net), avec COM+ qui est un serveur d'applications. (anciennement Microsoft Transaction Server)
Non. Encore une fois, il ne faut pas confondre la compatibilité avec des composants COM ou DCOM et le serveur d'appli intégré à Windows alias COM+.Ben si justement ça existe:
http://www2.softwareag.com/corporate/products/entirex/default.asp(...)
Manquerai plus que celà: les composants qui se chargent eux-même du boulot d'un serveur d'appli! On marche sur la tête là...Je dirais même qu'absolument tout reste à faire, et que ce ne sont pas que des API...
Bref, Mono ne sert à rien pour les applications d'entreprise. Merci de m'avoir lu jusqu'ici, vous pouvez continuer votre travail et retourner bosser sur Jonas ou Jboss.
[^] # Re: Mono...tonie
Posté par TImaniac (site web personnel) . Évalué à 4.
Sinon pour le serveur d'application, il me semble que c'est ASP.NET qui joue se rôle dans le monde .NET...
Après il manque effectivement System.EnterpriseServices dans Mono.
Enfin reste à voir ce que nous réserve Novell, car un de leur objectifs est de propouvoir Mono en entreprise, et il semble qu'en l'état actuel il manque vraiment beaucoup de choses...
Manquerai plus que celà: les composants qui se chargent eux-même du boulot d'un serveur d'appli! On marche sur la tête là...
Euh, j'ai jamais dis celà...
Un article qui peut t'intéresser, même si je suppose que je n'ai rien à t'apprendre dans le domaine : http://www.dotnetguru.org/articles/CoucheService.htm(...)
Enfin je suppose que ce post était surtout présent pour montrer une des lacunes de Mono, notamment pour les entreprises et tu as parfaitement bien fait de le souligner, étant incompétent dans ce domaine je n'avais pas soulever le problème dans ma news.
[^] # Re: Mono...tonie
Posté par Raoul Volfoni (site web personnel) . Évalué à 3.
L'humilité toujours tu devras garder... :)Voilà, et aussi pour dire qu'en la matière, Java a encore de belles années devant lui.
Parce que même avec .Net on ne va pas loin, car contrairement aux dires de Ms, ce n'est pas vraiment portable.
[^] # Re: Mono...tonie
Posté par Raoul Volfoni (site web personnel) . Évalué à 2.
http://www.dotnetguru.org/articles/pooling.htm(...)
En clair, certaines propriétés des composants .Net peuvent être définies à l'écriture du code (mauvaise idée, changer d'idée) ou via la console d'admin de COM+ ce que font tous les serveurs d'applis digne de ce nom. Tu vois j'ai appris quelque chose! :)
[^] # Re: Mono...tonie
Posté par TImaniac (site web personnel) . Évalué à 2.
# intégration Gnome
Posté par 007 . Évalué à 4.
Ça reste au niveau du débat actuellement. Java est aussi très bien placé et même s'il a l'air technologiquement moins "hype" il a une grosse communauté, est mature, à plein d'outils et librairies. Pour le côté "hype", java peut toujours évoluer. Rien n'est définitivement figé. Mono a des problèmes de licences/brevets/chez_pas_quoi_d_autre qui en calme plus d'un (à tord ou à raison). Quoiqu'il en soit, Red Hat ne veut actuellement pas mettre de mono dans Fedora (ni Fedora Extra) pour des problèmes de licences/brevets/chez_pas_quoi_d_autre. Or il y a gcj, tomcat, etc dans Fedora .
Red Hat (du moins par la voie d'Havoc) a clairement une préférence pour Java. On aime ou on n'aime pas Red Hat mais son influence ne peut pas être ignorée. Et je n'oublie pas que Sun qui est plus free software friendly que MS (ya pas photo).
Bref, c'est vraiment pas gagné pour l'un ou pour l'autre.
L'intégration d'un java ou mono, c'est du long terme et aucune décision n'est prise. Il se peut que l'intégration d'un tel langage n'arrive pas avant plusieurs années. En autre car les bindings marchent et rendent service. Puis il y a aussi le raprochement de mozilla avec Gnome qui peut répondre à d'autres besoins.
Pour être honnète, je ne vois pas la situation de façon très claire car c'est techniquement très complexe et qu'il faut prendre en compte la "sensibilité" de la communauté.
Mais je suis toujours méfiant lorsqu'on annonce la déferlante d'une technologie qui va tout remplacer. L'historique de Java est un bon exemple. On devait avoir du java à tous les étages et sur une distribution Linux "classique" moderne c'est généralement limité au plug-in mozilla ou tomcat. Si je fais un tour sur freshmeat, Il n'y a pas beaucoup de projet sexy en java pour le desktop.
Puis MS a repris le développement d'IE :-)
Pour moi c'est : wait and see.
Hors-sujet:
--------------
Comme je ne peux pas faire de journaux, donc j'en profite ici.
Ébauche (donc c'est loin d'être définitif) de FC3 (servira aussi de base pour RHEL 4) :
http://www.redhat.com/archives/fedora-devel-list/2004-July/msg00056(...)
Pas aussi "révolutionnaire" que FC2.
Pour ma part je relève :
- Pango support for Mozilla
Un petit raprochement supplémentaire entre Gnome (en fait Gtk+) et mozilla.
Trou de sécurité Linux 2.4 et 2.6 :
http://www.redhat.com/archives/fedora-announce-list/2004-July/msg00(...)
During an audit of the Linux kernel, SUSE discovered a flaw in the
Linux kernel that inappropriately allows an unprivileged user to change the group ID of a file to his/her own group ID. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CAN-2004-0497 to this issue.
# Corrections
Posté par manalfer . Évalué à 1.
Mais il n'y a pas de réelle solution alternative qui soit libre et qui respecte les standard
Je remplacerait aussi solution alternative par solution concurrente, ou plus simplement autre solution.
# De mauvaise foi !
Posté par Hive Arc . Évalué à 5.
De plus, que je sache Java est disponible dans sa toute derniere version sur Linux et avec une compatibilité de 100% (merci au TCK). Alors passer aussi rapidement sur un "détail" à son importance.
Pour moi c'est de la mauvaise fois pure et simple.
Franchement, quite a faire du "portable à tout prix" autant faire du python !
Maintenant si, la portabilité doit être conservé et l'environement souple, alors Java reste le meilleur compromit. Et la confiance renouvellée de Apache avec le passage du projet Geronimo comme projet de premier niveau prouve que le temps n'est plus aux tergiversations dans la communauté.
Mieux vaut laiser icaza jouer avec son mono, moi pendant ce temps je joue avec Looking Glasses :
https://lg3d-core.dev.java.net/lg3dgettingstarted.html(...)
A chacun ces "jeux" ;-)
[^] # Re: De mauvaise foi !
Posté par HappyPeng . Évalué à 1.
Vous utilisez abusivement le mot communauté pour désigner des développeurs et des utilisateurs qui ont pour l'instant fait le choix de fonder leur travail sur une solution quasi exclusivement propriétaire, avec la machine virtuelle (les environnements J2EE libres et les projets Apache en Java ne tournent pas ou peu sur des machines virtuelles libres, etc.). Mais ce n'est pas le choix de tous (en particulier ça n'est pas le mien) et même d'entreprises importantes pour le libre telles RedHat (qui a choisi de libérer Eclipse de la machine virtuelle de Sun en adaptant la machine virtuelle de GNU, gcj/gij, et Eclipse pour qu'ils puissent fonctionner ensemble).
L'heure est donc bel et bien aux tergiversations, lorsqu'il s'agit de sujets aussi primordiaux. Comment tournerait un programme écrit en C sans compilateur ? Alors comment tournerait un programme écrit en Java ou en C# sans les environnements correspondants ? Tant qu'il subsistera un doute sur la viabilité de ces environnements pour le logiciel libre au point de vue licence, il y aura bien tergiversation.
Pour ceux qui parlent des spécifications Sun : est-il de toute façon possible qu'une implémentation libre puisse suivre au même rythme que sort le code nécessitant la toute dernière version (Looking Glass demande comme par hasard une bêta de Java 1.5) ?
[^] # Re: De mauvaise foi !
Posté par 007 . Évalué à 2.
La réponse est forcément non.
Mais c'est une mauvais question si l'objectif est d'avoir java en libre fonctionnel pour les projets libres.
Red Hat a fait l'effort pour avoir Eclipse "totalement libéré". Le même travail peut-être fait ailleur. Si l'objectivité est la liberté, avoir une vm en retard sur la dernière vm de Sun n'est pas un problème. Malheureusement, les gens choisirons toujours (ou presque) la vm la plus complète au détriment de la plus libre.
C'est bien con. La seule solution, est de faire une vm meilleure que Sun. C'est très dure surtout si les gens "boudent" la vm libre tant qu'elle n'est pas au niveau de celle de Sun.
Mais je pense que celà peut basculer rapidement. Le problème est qu'il n'y a pas une forte demande (sauf côté serveur). Si la demande croit (peut-être avec Gnome) ça peut changer.
Pourquoi il n'y a pas de bonne vm libre ? Peut-être parceque la vm Sun est dispo (suffit de la downloader). Mono est développé rapidement car il n'y a pas le chois...
[^] # Re: De mauvaise foi !
Posté par Nelis (site web personnel) . Évalué à 0.
Pourquoi ? Le terme communauté est breveté ? Seul le libre peut utiliser communauté ?
[^] # Re: De mauvaise foi !
Posté par HappyPeng . Évalué à 1.
Il me paraissait assez clair qu'il n'y avait pas lieu de tergiverser si le mot communauté désignait ceux qui avaient de toute façon déjà opté pour Java. J'ai donc pensé qu'il parlait de la communauté du logiciel libre en général.
# Point de vue d'un "javateux"
Posté par Julien Bidault . Évalué à 3.
Faut pas oublier de bien comparer par rapport à Java 1.5, qui implique des changements assez profonds dans le langage, et des améliorations diverses un peu partout...c'est une plateforme largement utilisée en entreprise, qui de ce fait bénéficie d'un gros feedback des utilisateurs...ce qui se voit dans les JCP.
Enfin, Java est soutenu également par des gros, dont IBM, Borland, etc...
Bref, je pense que Mono va pas remplacer tt de suite Java...
maintenant, si Mono clarifie ses pb de licences vis à vis de MS, si les API sont toutes portées sous linux, si la compatibilité devient la même que celle de Java (nombre de plateformes supportées), alors y'aura un match intéressant, qui vue l'aspect ouvert des 2 langages, pourra que déboucher sur du bon...
[^] # Compatibilité ... oui justement !
Posté par Hive Arc . Évalué à 3.
Car c'est bien là le noeud du PB. Prend les fonctionalités entreprises de .net comme elle sont basés sur COM+ et qu'il n'y a aucune spec de dispo, il est impossible à mono de les supporter. Or toute platforme qui veut vraiment faire un truc qui monte en charge va passer par ces fonctionalités. Finit la "compatibilité" promise. De plus, avoir des API identique est une chose mais offrir un comportement identique en est un autre. Et le TCK est là pour ça !
Tant que MS ne fournira pas de TCK, il n'y aura pas d'avenir pour mono.
# Mort au libre qui ne fait que copier, longue vie au libre qui innove!
Posté par HappyCrow . Évalué à -2.
expertise informatique.
Par contre, en marketing peut-être
et en abus de position
dominante sûrement!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.