Tu as moyen de distribuer mono avec ton application sans forcement l'installer et en y intégrant juste les libs que tu utilises, c'est un des avantages de Mono d'ailleur, tu fais une installation qui consiste alors à un simple copier-coller. Sinon il me semble que les dépendances sont un faut problème, puisque d'une manière ou d'une autre, si tu ne veux pas perdre de temps et réinventer la roue, tu utilisera forcement des libs existantes, qu'elles soient incluses dans un framework complexe ou non...
ça reste trop "Windows"
Comment ça ? Effectivement si tu veux utiliser les WinForms... mais avec GTK# je trouve que celà ressemble trop à Gnome ;).
Après libre à toi de voir si tu veux apprendre un nouvel API ou pas...
Bah c'est toujours pareil, tout dépend de ce que tu connais comme langages et à quels API tu es habitué...
Si tu connais bien le Java, passe directement à Mono et GTk# avec C#, tu apprécieras les améliorations par rapport à Java et tu auras toute la puissance de GTK.
Sinon bien sûr Python/wxWindows est une bonne solution.
Perso je choisirai Glade + GTK# + Mono (pas Qt# parcque c'est pas vraiment mis à jour) pour la richesse du framework, le côté 100% libre, l'ergonomie du C# et l'intégration dans l'environnement.
Un dernier conseil, quelque soit ton choix, fait en sorte que l'interface utilisateur soit bien détaché du reste de l'application pour pouvoir facilement l'adapter à un autre environnement, et bien sûr évite toute solution "imitant" un environnement ou ne s'intégrant dans rien du tout parcqu'elle a son propre toolkit graphique.
Qu'il soit libre ou proprio ne fait alors pas grande différence dans les coûts.
C'est bien pour ça que le choix est difficile, il faut réussir à les convaincre que rien ne vaut la philosophie du LL, quitte à sacrifier la compatibilité (.doc & co), l'ergonomie et le temps/cout de formation des employés...
tu prend le langage IL défini par l'ECMA, il a été conçu spécialement pour ça. Evidemment c'est pas du XML mais bon ça doit pas être compliquer de mapper tout ca :)
RelaxNG me semble un peu un cas à part puisqu'il peut devenir un standard au même titre que les schéma XML ou les DTD (qui ne sont pas du XML non plus d'ailleur).
Evidemment les gens préfèrent utiliser la syntaxe "compacte" parcque l'utilisateur écrit directement une grammaire (contrairement à la plupart des autres format XML qui ne sont qu'un support pour représenter des informations, le but n'est pas de proposer à l'utilisateur de taper directement son document XML, c'est pour celà que normalement, le fait que ce soit pas tellement lisible c'est pas bien important). Mais perso je vois plus cette syntaxe comme un "frontend" utilisateur du format RelaxNG standard qui lui est en XML et qui sera bien plus facilement exploitable. RelaxNG compact devrait jouer le même rôle pour RelaxNG "normal" que Glade joue son rôle d'interface utilisateur pour le format sous-jacent. Je sais pas si je suis clair :-)
Bref, dans tous les cas ce qu'il manque à XUL c'est plutôt un véritable environnement de développement, bref une interface utilisateur. C'est aussi ça la force du XML, il force les programmeur a faire une interface plus conviviale que la syntaxe XML :)
Il est intéressant de noter par exemple que Microsoft a dans un premier temps choisi la syntaxe CSS pour son format XAML, c'était effectivement plus lisible mais les nombreux testeurs ont vite râler parcqu'ils ne pouvaient pas manipuler leurs documents XAML comme tout autre document XML...
Je ne suis pas contre le fait d'utiliser un format "alternatif" pour faciliter la création d'un document XUL, mais le document final DOIT rester en XML, même s'il faut faire une conversion.
Faut arrêter de fumer là... Le XML n'est peut être pas très agréable à lire, mais c'est pas sa vocation : il est là pour éviter à tous les programmeurs de refaire un énième parser et avec un schéma ou une DTD il te fait même gentiment une partie de l'analyse syntaxique... Y'en n'a qui n'ont vraiment rien compris...
Merci pour ces informations. Pour la généricité le problème sera peut être résolu par les nouvelles spécifications qui introduisent la notion de généricité dans la VM... pour le sous-typage, il faut faire des proposition à l'ECMA... Bref, rien d'insurmontable amha.
Je suis totalement d'accord avec toi. Ce que je voulais dire c'est que Mono peut être une plateforme "universelle" pour être un point de convergence entre les API et leurs utilisateurs, le fait que la VM soit adaptée à plusieurs langages ne fait qu'aller dans ce sens sans tout faire bien évidemment (ce n'est effectivement pas la VM qui est universelle).
Pour ce qui est des primitives qu'il manque dans la VM pour certaines catégories de langages, il faut se dire que les spécifs de L'ECMA ne sont pas du tout fermées et la VM peut donc très bien évoluer, notamment en rajoutant des primitives. Par contre je suis curieux de connaître les primitives qui n'existe pas et qui pose problème, je suis intéressé et je veux bien que tu m'aiguilles, j'ai jamais essayé de faire un compilo de langage fonctionnel alors bon...
Pour l'exemple de OCaml, regarde du côté de Ocamil, qui semble bien plus prometteur que F# qui reste un rat de laboratoire... Si ça se trouve il va y avoir la même différence qu'entre Python.NET et IronPython... La VM de l'ECMA n'est pas prévu pour être utilisé avec un langage interprêter pourtant IronPython tourne plus vite que l'original... Comme quoi les préjugés...
Disons que les templates en gros le compilo il se fait pas trop chier : il compile la classe générique avec le type object. Et pour faire semblant d'avoir réussi son tour de passe passe, il fait pas dans le détail : il rajoute des cast partout. Voilà pour la solution Java. Avantage : ça marche sur les VM actuelles sans problème (et pour cause, c'est juste de la bidouille syntaxique à la compilation)
Pour ce qui est de l'implémentation du C#, le code est remplacé à l'éxécution par son vrai type. Ca change quoi ? Tout. Tout d'abord le code est partagé par toutes les instances de la classe "générique", et surtout, à l'exécution, une classe générique reste une classe générique et toutes les possibilités de Reflexions sont parfaitement gardées. Si l'on prend exemple sur un type liste générique, en Java tu pourras déterminer à l'exécution qu'une liste est une liste, mais pas plus, tu ne peux pas savoir que c'est une liste de int ou de bool. En C# tu peux récupérer le vrai type, créer une nouvelle instance avec un nouveau type à la volée, etc.
Pour plus de détails sur les différences entre les generics en Java, C++ et C#, c'est par ici : http://www.artima.com/intv/generics.html(...)
On y comprend clairement les limites des templates en C++ notamment.
Il est clair que l'avantage de la solution Sun et de ne pas avoir à modifier l'implémentation des VM pour faire fonctionner son code... Mais celà risque de rendre la VM Java vite obsolète face aux concurrents, les spécifications officielles de la VM de l'ECMA (celle de Mono et Microsoft) a déjà plus évolué en 2 ans que celle de Java depuis sa création...
Vi, enfin faut voir aussi ce qu'on veut : avoir une plateforme plus ou moins "universelle" pour le desktop : et le fait est que la plupart des composants actuels de l'OS sont constitués d'API basé sur des langages qui n'ont rien de fonctionnel mais par contre avec une bonne dose d'objet pour ce uqi est des interfaces... c'est peut être pas pour rien que Microsoft et Mono ont fait ce choix... De plus un langage fonctionnel peut aussi être objet, et peut donc très bien s'intrégrer avec cette plateforme, et c'est d'ailleur le but. L'inverse est beaucoup moins vrai.
Après les langages fonctionnels font tous le même taf et finisse par créer du code itératif de base, ce qu'une VM propose bien évidemment. Reste que si tu veux optimiser pour certain langages fonctionnels, rien n'interdit de "factoriser" les points communs et d'intégrer ces possibilités dans la VM... notamment la VM de l'Ecma qui n'est pas du tout hostile aux évolution contrairement à celle de Sun (voir le résultat foireux des generics pour continuer à utiliser les VM actuelles...).
Je ne parle pas du C#, je parle de Mono, et de .NET par abus de langage, c'est vrai, pour représenter le framework. Mais dans le contexte je parle bien sûr de l'ensemble de l'API Mono qui est en partie basé sur les spécifications de l'ECMA, et en partie sous licence (L)GPL pour le reste (GTK#, Mozilla#, Glade#, etc), bref, aucun problème pour le logiciel libre. Ce que je voulais dire c'est qu'il est très facile d'appliquer le même principe (con mais tellement simple et avantageux) que XAML pour Mono, ce qui limite l'utilisation pour moi de XUL#, et que effectivement le débat se situe évidemment plus bas, dans le choix de la plateforme comme tu le dis d'ailleur.
Mais moi y'a une question que je me pose, c'est que chez mozilla ils ont l'air de vouloir se rapprocher de Gnome et éventuellement de Mono (qui tente déjà de flirter avec Gnome), mais quid de KDE ? N'auraient-ils eux non plus pas le droit à un environnement intégré basé sur une nouvelle plateforme ?
Pour préciser un peu plus :
le bytecode Java a été conçu pour être interprété, et les VM récentes utilisent des techniques d'optimisation pour arranger tout ca : elles "profilent" le code pour déterminer les portions de code les plus utilisées et les compile "à la volée". Celà dis ce n'est pas toujours parfait, et il faut commencer en mode interprété.
Si on prend exemple sur le CIL (l'équivalent du bytecode chez .NET et Mono) , celui-ci est optimisé et a été conçu pour être compilé. Il est donc parfaitement possible de compiler le code intermédiaire en code natif, à la volée (JIT), ou même avant exécution.
Pour ce uqi est du JIT (compilation à la volée à l'éxecution), il faut juste se dire que c'est la dernière étape de la compilation qui a lieu, elle est juste retardée au dernier moment, notamment pour que le code soit plus "portable". (il faut bien se dire qu'il y a également un code intermédiaire dans GCC)
Dans tous les cas, qu'il s'agissent du bytecode Java ou du CIL, on peut compiler ou intepréter, seulement l'un est optimisé pour la compilation et l'autre pour l'interprétation...
Seulement voilà, il est encore plus facile, AMHA, de faire une implémentation de XAML qui n'est que du mapping des classes .NET (element = classe, attribut = propriété de la classe, mapping des événements, etc) ... De plus ce sera beaucoup plus puissant car pas limité à XUL (on perd forcement une partie de la puissance de GTK en passant par une couche d'API supplémentaire), et surtout le programmeur n'aura pas a apprendre un enième API différent... Mono (et la techno .NET) offre ce formidable avantage de proposer le même API pour tous, de manière transparente...
De plus la documentation n'en sera que plus aisée à rédiger : regardez la documentation à votre disposition pour programmer avec Mono, on en trouve beaucoup plus qu'en lisant celle de XUL... Pourquoi ? Parcque Mono a un API proche de celui de Microsoft pour la partie normalisée, et "copié" sur les API GTK pour GTK#... C'est ce qui fait aussi la force d'une techno, c'est l'ensemble de la documentation et des ressources qui vont avec ...
Evidemment on pourra reprocher le fait que beaucoup de ressources pour mono sont directement issu de Microsoft, mais bon, la documentation c'est au moins quelque chose qu'ils fournissent gratuitement, sans aucune restriction, à tous, et dans de nombreuses langues... Microsoft contribuerait à sa façon au développement communautaire :) Bon ok, j'arrête de triper.
Cad en gros que si tu es un développeur Java tu trouves que c'est parfaitement inutile, et que si tu es un développeur curieux et que tu goutes à toutes ces nouveautés tu pleures quand tu retourne coder en Java... Sinon dis toi qu'il y a des améliorations de syntaxe, l'ajout de design patterns courant dans le langage, une intégration bien plus aisée avec l'existant, une évolution bien plus facile grâce aux attributs et méta données, une génération de code optimisé pour le JIT (bref pas pour être interpréter comme a été conçu Java)...
Bref un langage plus souple, plus agréable, qui utilise une syntaxe de base "connue", bref, plein de nouveautés qui ont conduit Sun a ajouter plein de trucs dans la version 1.5 (comme quoi même chez Sun ils ont du kiffer le C#).
mmmh, je vais encore me faire moinsser mais c'est pas grave, je vais me répeter :
XUL n'est pas une alternative à XAML. A la rigueur, XAML correspond à Glade dans le monde Gnome. Les gens voit du XML et la génération d'interface et zou... c'est la même chose... ralala. Mais Brendan le dit lui même : on peut récuperer quelques trucs dans XUL : en gros la syntaxe XML (bref on garde rien de XUL dans ce contexte) et tout le reste est à faire.
XAML n'est rien d'autre que l'utilisation du langage XML pour mapper n'importe quelle classe du framework .NET, bref, rien d'innovant, rien de breveté, rien de dérangeant en soit.
Passons à la partie troll du sujet (bah oui quoi, faudrait pas l'oublier :) ) : "Pour cela, il faut mettre en commun les efforts, et présenter un front unifié et Libre basé sur des standards ouverts."
Le problème, c'est que pour le moment, seul Mono est capable de rivaliser avec les techno de Microsoft, Mono étant la seule plateforme managée (y'a une VM et tout le toutim qui va avec) indépendante du langage (en tout cas facilement utilisable dans tous les langages, même s'ils ne ciblent pas directement la VM, parcqu'il existe évidemment des langages pas tellement adaptés, mais bon, IronPython en a calmé plus d'un sur des affirmations gratuites que tout le monde a repris a coeur joie parcque ca leur faisait plaisir d'y croire).
Bref, Mono est libre, basé sur des standards ouverts (GPL+LPGL+X11+ECMA+ISO+absence de brevets sur toute la partie qui nous intéresse), c'est un projet qui a maintenant plus de 2 ans, bien avancé, et surtout qui commence à être utilisé, ne serait-ce que par Novell qui base tout ses développement "multiplateforme" dessus.
Après si y'en a qui veulent encore réinventer la roue et perdre un temps précieux face à la concurrence, pourquoi pas. Mais c'est pas aussi simple que XUL, et c'est pour ça que MDI il veut intégrer Mono à Gnome.
Vi je suis entièrement d'accord avec toi... Mais j'ai préférépréciser, parcque bon, jusque là il y avait un mélange bien souvent entre langage et API de base, on parlait de Java mais aussi de ce qui allait avec indifférement, alors que C# s'intègre dans un environnement ou le langage se différencie des concurrent surtout du fait de la syntaxe, chaque langage ayant accès à la même VM (je parle de l'environnement .NET ou mono bien entendu)
C# corrige quoi comme défauts ? je suppose en plus que tu ne parles que de la syntaxe !
eh déjà un langage est avant tout caractérisé par sa syntaxe... donc bon...
Sinon pour les améliorations :
- autoboxing
- métadonnées
- événements
- les delegates
- détection de débordement
- implémentation explicite d'interface
- propriétés, indexeurs, foreach, liste variable de paramètres
- types valeur
- énumérations
- pointeurs (pas de troll merci, il n'y a aucun obligation de les utiliser et ils sont bien mieux contrôlés et ont leur utilité dans des cas bien précis)
- le versionning
- passage par référence
Et puis pour C# 2.0 vs Java 1.5 (les 2 étant en phase de béta test), y'en a un qui fait des vrais generics, et l'autre qui fait des templates, ou plutôt du "replace all"... devine lequel est lequel ;)
Désolé mais les API Java sont propriétaires (si si je t'assure) et les API de base de .NET sont normalisés ce qui a permi entre autre à Mono de voir le jour tout en conservant une certaine compatiblité et en proposant une alternative à la partie proprio (GTK# à la place des WinForms par exemple). Bref tout le contraire de ce que tu veux bien affirmer.
La question n'est pas de savoir qui trahira qui, le truc c'est que les 2 parties voient un intérêt dans cet accord, c'est pas pour ça qu'ils sont main dans la main et amis pour la vie. Microsoft passe des accords avec d'autres concurrents comme IBM pour développer certaines technologies, celà ne les empêche pas de se battre sur d'autres produits... Quand vous aurez compris qu'on peut très bien être partenaires et concurrents sans que celà pose le moindre problème...
Le problème de Java c'est pas que le langage en soit est désagréable (et en dehors du fait que capucpaslibre), le problème c'est que depuis sa sortie et depuis les langages que tu as utilisé (c,c++, VB, TPascal), il y a pleins d'autres langages qui sont sortis... et le langage Java n'a malheuresement que trop peu évoluer pour être le choix le plus agréable, élégant et puissant qu'il faut utiliser. Reste qu'il y a le point positif : tout un ensemble d'applications existante et une certaine maturité due à son âge.
En effet Mono + Linux implique d'utiliser une technologie Microsoft mais sans que cette technologie soit certifié par M$, chose plus qu'improbable pour un décideur (car je le rappelle, un décideur ne prend jamais la solution la mieux adapté techniquement mais la plus sûre commercialement -support/assistance/marketing-)
Mmmmh, je trouve que tu y vas un peu fort... Tout d'abord Java a commencé au même niveau que Mono...
Et si le décideur choisi la solution qui favorise la triplette support/assistance/marketing, je doute qu'il choisisse forcement Java+Linux (ou Zope ou PHP) si tu vois ce que je veux dire...
De plus il faut savoir que Mono étant basé sur les technos de Microsoft, toutes les SSII qui sont en train d'acquérir tout le bagage technique pour .NET pourra aisément proposer ses services pour Mono... Bref, rien de pire que Java à ses débuts, ou encore PHP... Tes spéculations sur sur les choix futurs des décideurs me paraîssent un peu fantaisistes... enfin moi c'que j'en dis...
[^] # Re: Quel est selon vous le langage... le plus adapté pour...
Posté par TImaniac (site web personnel) . En réponse au journal Quel est selon vous le langage... le plus adapté pour.... Évalué à 1.
[^] # Re: Quel est selon vous le langage... le plus adapté pour...
Posté par TImaniac (site web personnel) . En réponse au journal Quel est selon vous le langage... le plus adapté pour.... Évalué à 1.
Comment ça ? Effectivement si tu veux utiliser les WinForms... mais avec GTK# je trouve que celà ressemble trop à Gnome ;).
Après libre à toi de voir si tu veux apprendre un nouvel API ou pas...
# Re: Quel est selon vous le langage... le plus adapté pour...
Posté par TImaniac (site web personnel) . En réponse au journal Quel est selon vous le langage... le plus adapté pour.... Évalué à 1.
Si tu connais bien le Java, passe directement à Mono et GTk# avec C#, tu apprécieras les améliorations par rapport à Java et tu auras toute la puissance de GTK.
Sinon bien sûr Python/wxWindows est une bonne solution.
Perso je choisirai Glade + GTK# + Mono (pas Qt# parcque c'est pas vraiment mis à jour) pour la richesse du framework, le côté 100% libre, l'ergonomie du C# et l'intégration dans l'environnement.
Un dernier conseil, quelque soit ton choix, fait en sorte que l'interface utilisateur soit bien détaché du reste de l'application pour pouvoir facilement l'adapter à un autre environnement, et bien sûr évite toute solution "imitant" un environnement ou ne s'intégrant dans rien du tout parcqu'elle a son propre toolkit graphique.
[^] # Re: Un sujet de réflexion pour l'administration
Posté par TImaniac (site web personnel) . En réponse au journal Un sujet de réflexion pour l'administration. Évalué à 1.
C'est bien pour ça que le choix est difficile, il faut réussir à les convaincre que rien ne vaut la philosophie du LL, quitte à sacrifier la compatibilité (.doc & co), l'ergonomie et le temps/cout de formation des employés...
[^] # Re: Doc nautilus spatial et polices pdf
Posté par TImaniac (site web personnel) . En réponse au journal Doc nautilus spatial et polices pdf. Évalué à 1.
[^] # Re: XUL compact
Posté par TImaniac (site web personnel) . En réponse au journal XUL compact. Évalué à 1.
http://www.gnu.org/projects/dotgnu/html2.0/acronyms.html(...)
spécifications officielles par ici :
http://www.ecma-international.org/publications/standards/Ecma-335.h(...)
Mais bon c'est un petit peu hors sujet, ou plutôt pas tellement adapté (quoique)
[^] # Re: XUL compact
Posté par TImaniac (site web personnel) . En réponse au journal XUL compact. Évalué à 1.
[^] # Re: XUL compact
Posté par TImaniac (site web personnel) . En réponse au journal XUL compact. Évalué à 1.
Evidemment les gens préfèrent utiliser la syntaxe "compacte" parcque l'utilisateur écrit directement une grammaire (contrairement à la plupart des autres format XML qui ne sont qu'un support pour représenter des informations, le but n'est pas de proposer à l'utilisateur de taper directement son document XML, c'est pour celà que normalement, le fait que ce soit pas tellement lisible c'est pas bien important). Mais perso je vois plus cette syntaxe comme un "frontend" utilisateur du format RelaxNG standard qui lui est en XML et qui sera bien plus facilement exploitable. RelaxNG compact devrait jouer le même rôle pour RelaxNG "normal" que Glade joue son rôle d'interface utilisateur pour le format sous-jacent. Je sais pas si je suis clair :-)
Bref, dans tous les cas ce qu'il manque à XUL c'est plutôt un véritable environnement de développement, bref une interface utilisateur. C'est aussi ça la force du XML, il force les programmeur a faire une interface plus conviviale que la syntaxe XML :)
Il est intéressant de noter par exemple que Microsoft a dans un premier temps choisi la syntaxe CSS pour son format XAML, c'était effectivement plus lisible mais les nombreux testeurs ont vite râler parcqu'ils ne pouvaient pas manipuler leurs documents XAML comme tout autre document XML...
Je ne suis pas contre le fait d'utiliser un format "alternatif" pour faciliter la création d'un document XUL, mais le document final DOIT rester en XML, même s'il faut faire une conversion.
[^] # Re: C
Posté par TImaniac (site web personnel) . En réponse au journal C. Évalué à 1.
# Re: XUL compact
Posté par TImaniac (site web personnel) . En réponse au journal XUL compact. Évalué à 2.
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par TImaniac (site web personnel) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 1.
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par TImaniac (site web personnel) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 1.
Pour ce qui est des primitives qu'il manque dans la VM pour certaines catégories de langages, il faut se dire que les spécifs de L'ECMA ne sont pas du tout fermées et la VM peut donc très bien évoluer, notamment en rajoutant des primitives. Par contre je suis curieux de connaître les primitives qui n'existe pas et qui pose problème, je suis intéressé et je veux bien que tu m'aiguilles, j'ai jamais essayé de faire un compilo de langage fonctionnel alors bon...
Pour l'exemple de OCaml, regarde du côté de Ocamil, qui semble bien plus prometteur que F# qui reste un rat de laboratoire... Si ça se trouve il va y avoir la même différence qu'entre Python.NET et IronPython... La VM de l'ECMA n'est pas prévu pour être utilisé avec un langage interprêter pourtant IronPython tourne plus vite que l'original... Comme quoi les préjugés...
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par TImaniac (site web personnel) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 2.
Pour ce qui est de l'implémentation du C#, le code est remplacé à l'éxécution par son vrai type. Ca change quoi ? Tout. Tout d'abord le code est partagé par toutes les instances de la classe "générique", et surtout, à l'exécution, une classe générique reste une classe générique et toutes les possibilités de Reflexions sont parfaitement gardées. Si l'on prend exemple sur un type liste générique, en Java tu pourras déterminer à l'exécution qu'une liste est une liste, mais pas plus, tu ne peux pas savoir que c'est une liste de int ou de bool. En C# tu peux récupérer le vrai type, créer une nouvelle instance avec un nouveau type à la volée, etc.
Pour plus de détails sur les différences entre les generics en Java, C++ et C#, c'est par ici :
http://www.artima.com/intv/generics.html(...)
On y comprend clairement les limites des templates en C++ notamment.
Il est clair que l'avantage de la solution Sun et de ne pas avoir à modifier l'implémentation des VM pour faire fonctionner son code... Mais celà risque de rendre la VM Java vite obsolète face aux concurrents, les spécifications officielles de la VM de l'ECMA (celle de Mono et Microsoft) a déjà plus évolué en 2 ans que celle de Java depuis sa création...
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par TImaniac (site web personnel) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 3.
Après les langages fonctionnels font tous le même taf et finisse par créer du code itératif de base, ce qu'une VM propose bien évidemment. Reste que si tu veux optimiser pour certain langages fonctionnels, rien n'interdit de "factoriser" les points communs et d'intégrer ces possibilités dans la VM... notamment la VM de l'Ecma qui n'est pas du tout hostile aux évolution contrairement à celle de Sun (voir le résultat foireux des generics pour continuer à utiliser les VM actuelles...).
[^] # Re: XUL#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 1.
Mais moi y'a une question que je me pose, c'est que chez mozilla ils ont l'air de vouloir se rapprocher de Gnome et éventuellement de Mono (qui tente déjà de flirter avec Gnome), mais quid de KDE ? N'auraient-ils eux non plus pas le droit à un environnement intégré basé sur une nouvelle plateforme ?
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par TImaniac (site web personnel) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 1.
le bytecode Java a été conçu pour être interprété, et les VM récentes utilisent des techniques d'optimisation pour arranger tout ca : elles "profilent" le code pour déterminer les portions de code les plus utilisées et les compile "à la volée". Celà dis ce n'est pas toujours parfait, et il faut commencer en mode interprété.
Si on prend exemple sur le CIL (l'équivalent du bytecode chez .NET et Mono) , celui-ci est optimisé et a été conçu pour être compilé. Il est donc parfaitement possible de compiler le code intermédiaire en code natif, à la volée (JIT), ou même avant exécution.
Pour ce uqi est du JIT (compilation à la volée à l'éxecution), il faut juste se dire que c'est la dernière étape de la compilation qui a lieu, elle est juste retardée au dernier moment, notamment pour que le code soit plus "portable". (il faut bien se dire qu'il y a également un code intermédiaire dans GCC)
Dans tous les cas, qu'il s'agissent du bytecode Java ou du CIL, on peut compiler ou intepréter, seulement l'un est optimisé pour la compilation et l'autre pour l'interprétation...
[^] # Re: XUL#
Posté par TImaniac (site web personnel) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 1.
Seulement voilà, il est encore plus facile, AMHA, de faire une implémentation de XAML qui n'est que du mapping des classes .NET (element = classe, attribut = propriété de la classe, mapping des événements, etc) ... De plus ce sera beaucoup plus puissant car pas limité à XUL (on perd forcement une partie de la puissance de GTK en passant par une couche d'API supplémentaire), et surtout le programmeur n'aura pas a apprendre un enième API différent... Mono (et la techno .NET) offre ce formidable avantage de proposer le même API pour tous, de manière transparente...
De plus la documentation n'en sera que plus aisée à rédiger : regardez la documentation à votre disposition pour programmer avec Mono, on en trouve beaucoup plus qu'en lisant celle de XUL... Pourquoi ? Parcque Mono a un API proche de celui de Microsoft pour la partie normalisée, et "copié" sur les API GTK pour GTK#... C'est ce qui fait aussi la force d'une techno, c'est l'ensemble de la documentation et des ressources qui vont avec ...
Evidemment on pourra reprocher le fait que beaucoup de ressources pour mono sont directement issu de Microsoft, mais bon, la documentation c'est au moins quelque chose qu'ils fournissent gratuitement, sans aucune restriction, à tous, et dans de nombreuses langues... Microsoft contribuerait à sa façon au développement communautaire :) Bon ok, j'arrête de triper.
[^] # Re: Java c'est bien !
Posté par TImaniac (site web personnel) . En réponse au journal Java c'est bien !. Évalué à 1.
Bref un langage plus souple, plus agréable, qui utilise une syntaxe de base "connue", bref, plein de nouveautés qui ont conduit Sun a ajouter plein de trucs dans la version 1.5 (comme quoi même chez Sun ils ont du kiffer le C#).
# Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par TImaniac (site web personnel) . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 5.
XUL n'est pas une alternative à XAML. A la rigueur, XAML correspond à Glade dans le monde Gnome. Les gens voit du XML et la génération d'interface et zou... c'est la même chose... ralala. Mais Brendan le dit lui même : on peut récuperer quelques trucs dans XUL : en gros la syntaxe XML (bref on garde rien de XUL dans ce contexte) et tout le reste est à faire.
XAML n'est rien d'autre que l'utilisation du langage XML pour mapper n'importe quelle classe du framework .NET, bref, rien d'innovant, rien de breveté, rien de dérangeant en soit.
Passons à la partie troll du sujet (bah oui quoi, faudrait pas l'oublier :) ) :
"Pour cela, il faut mettre en commun les efforts, et présenter un front unifié et Libre basé sur des standards ouverts."
Le problème, c'est que pour le moment, seul Mono est capable de rivaliser avec les techno de Microsoft, Mono étant la seule plateforme managée (y'a une VM et tout le toutim qui va avec) indépendante du langage (en tout cas facilement utilisable dans tous les langages, même s'ils ne ciblent pas directement la VM, parcqu'il existe évidemment des langages pas tellement adaptés, mais bon, IronPython en a calmé plus d'un sur des affirmations gratuites que tout le monde a repris a coeur joie parcque ca leur faisait plaisir d'y croire).
Bref, Mono est libre, basé sur des standards ouverts (GPL+LPGL+X11+ECMA+ISO+absence de brevets sur toute la partie qui nous intéresse), c'est un projet qui a maintenant plus de 2 ans, bien avancé, et surtout qui commence à être utilisé, ne serait-ce que par Novell qui base tout ses développement "multiplateforme" dessus.
Après si y'en a qui veulent encore réinventer la roue et perdre un temps précieux face à la concurrence, pourquoi pas. Mais c'est pas aussi simple que XUL, et c'est pour ça que MDI il veut intégrer Mono à Gnome.
[^] # Re: Java c'est bien !
Posté par TImaniac (site web personnel) . En réponse au journal Java c'est bien !. Évalué à 1.
[^] # Re: Java c'est bien !
Posté par TImaniac (site web personnel) . En réponse au journal Java c'est bien !. Évalué à 1.
eh déjà un langage est avant tout caractérisé par sa syntaxe... donc bon...
Sinon pour les améliorations :
- autoboxing
- métadonnées
- événements
- les delegates
- détection de débordement
- implémentation explicite d'interface
- propriétés, indexeurs, foreach, liste variable de paramètres
- types valeur
- énumérations
- pointeurs (pas de troll merci, il n'y a aucun obligation de les utiliser et ils sont bien mieux contrôlés et ont leur utilité dans des cas bien précis)
- le versionning
- passage par référence
Et puis pour C# 2.0 vs Java 1.5 (les 2 étant en phase de béta test), y'en a un qui fait des vrais generics, et l'autre qui fait des templates, ou plutôt du "replace all"... devine lequel est lequel ;)
[^] # Re: Sun reçoit 2 milliard de $ de MS
Posté par TImaniac (site web personnel) . En réponse au journal Sun reçoit 2 milliard de $ de MS. Évalué à 2.
La question n'est pas de savoir qui trahira qui, le truc c'est que les 2 parties voient un intérêt dans cet accord, c'est pas pour ça qu'ils sont main dans la main et amis pour la vie. Microsoft passe des accords avec d'autres concurrents comme IBM pour développer certaines technologies, celà ne les empêche pas de se battre sur d'autres produits... Quand vous aurez compris qu'on peut très bien être partenaires et concurrents sans que celà pose le moindre problème...
# Re: Java c'est bien !
Posté par TImaniac (site web personnel) . En réponse au journal Java c'est bien !. Évalué à 0.
[^] # Re: Branches et Fedora
Posté par TImaniac (site web personnel) . En réponse au journal Branches et Fedora. Évalué à 1.
[^] # Re: Combien de temps pour Sun ...
Posté par TImaniac (site web personnel) . En réponse au journal Combien de temps pour Sun .... Évalué à 1.
Mmmmh, je trouve que tu y vas un peu fort... Tout d'abord Java a commencé au même niveau que Mono...
Et si le décideur choisi la solution qui favorise la triplette support/assistance/marketing, je doute qu'il choisisse forcement Java+Linux (ou Zope ou PHP) si tu vois ce que je veux dire...
De plus il faut savoir que Mono étant basé sur les technos de Microsoft, toutes les SSII qui sont en train d'acquérir tout le bagage technique pour .NET pourra aisément proposer ses services pour Mono... Bref, rien de pire que Java à ses débuts, ou encore PHP... Tes spéculations sur sur les choix futurs des décideurs me paraîssent un peu fantaisistes... enfin moi c'que j'en dis...