TImaniac a écrit 6420 commentaires

Ah oui et pour l'idée de m'apprendre à écire un vrai post ou j'exprime clairement mon opinion, bah euh, désolé j'ai l'impression d'être pourtant clair... tu le dis toi même je me répète, c'est que je ne suis pas trop contradictoire :) Celà dis j'y peux rien si les gens ne lisent pas tous les posts... heuresement d'ailleur. Mais c'est vrai que je me répète je l'avoue. C'est grave docteur ?

Désolé si je me sens intéressé par le sujet et par le débat. Je n'est pas l'impression de partir en troll, je n'est pas l'impression d'être insultant ou quoique ce soit. Vi j'ai rien à foutre ce soir et je vais me marier avec MDI et alors ?
En tout cas ça fait plaisir d'avoir un journal qui m'est dédié ;)

Enfin si ca vous gène vraiment moinsser moi, c'est fait pour ça.

désolé je préfère laisser le plus de problèmes possible à la VM, j'ai plus confiance dans la fiabilité de la VM que dans la fiabilité de ce que j'écris. C'est plus fort que moi. Si tu préfères tout faire à la main, le GC, etc. c'est toi qui vois.
Sinon je suis d'accord sur le fait qu'on ne choisi pas un langage parcqu'il est réputé pour être fiable (d'ailleur ça veut pas dire grand chose pour un langage). Evidemment que tu resteras dépendant du runtime, comme tu resteras dépendant du compilateur, que tu restera dépendant d'un OS, que tu resteras dépendant des API proposés à ton langage, etc. Je préfères factoriser les problèmes et essayer de fiabiliser une seule VM. Bref y'a le même problème partout, pas plus sur .NET qu'ailleur.

Les pointeurs dans .NET c'est pour simplifier l'utilisation d'API écrit en C par exemple et aussi pour laisser le choix aux langages d'implenter les pointeurs ou non. Les pointeurs peuvent être très utile pour des API de plus bas niveau, pour des optimisations.
Je n'est qu'une chose à dire : essai .NET et fait toi un vrai jugement sur ses capacités.

Pourquoi je défends .NET ? Sans doute pour les même raisons que MDI. Parcque je trouve ca techniquement impressionnant, que ca résoud pas mal de problème, que j'aime développer avec et que bah voilà quoi, ca te suffit pas ? :) Ah si, je défend .NET aussi contre tous les vilains trolls et les préjugés sur cette techno qui a eu le malheur d'avoir été conçu par "le mal".
Euh non, les librairies .NET n'était pas codé en Java... Enfin j'ai jamais entendu ca, et je vois pas trop l'intérêt, vu que les API de bases sont pour la plupart de simple appels aux API natifs, et le reste est construit au dessus...
Pour ce qui est de porter du C# en bytecode Java, nan c'est pas possible malgrès ce que certaines sociétés veulent faire croire, because y'a des notions du framework .NET qui ne peuvent être implémenter au dessus de Java (à moins de ne plus faire tourner les parties concernées au dessus de la JVM et à moins de supprimer les fonctionnalités de reflexivité du code au runtime).

Si tu te renseignai un peu tu saurais que c'est aussi une norme ISO depuis cet automne, d'où l'utilisation du terme ISOtifié...

D'après MDI (qui tu penses bien a du réfléchir à 2 fois), à partir du moment où ils réécrivent tout il n'y a pas de violation de brevets. La seule chose que pourra faire Microsoft c'est ce que fait SCO actuellement, c'est râler parcque ils ont pomper le code, mais ils sont pas cons pour faire ça...
Toute la partie basse du framework, la VM sont parfaitement utlisables sous Gnome sans violer quoique ce soit. Ils implémentent juste un standard (ECMA) et écrivent des API au dessus.

Pas besoin de marketer pour .NET, ils l'utilisent en interne, et vont de toute façon rendre cette plateforme incontournable dans longhorn.

Méfies toi, moi perso gphoto ne récupère pas toutes les images (genre 80%) ce qui est plutôt sournoit et incompréhensible vu que l'appareil semble parfaitement reconnu...

Parcque quand on programme en objet, il y a tellement de dépendance entre eux qu'il est parfois difficile de juger du moment opportun pour le delete (ou free). le GC trace en permanence les objets utilisés et choisi un moment "calme" pour le faire, cad quand le programme utilise moins de ressources. De plus comme toujours il faut mieux faire confiance au GC qui a moins de chance de se planter que le programmeur : il faut mieux automatiser tout ce qui peut l'être, c'est une source de bug en moins (si le GC ne l'est pas bien sûr).

BOon bah voilà t'as trouvé le coupable (il était dur à trouver...) ! Bref rien à voir avec le sujet, qui est quand même Mono sous Linux...

Je trouve ça de l'extorsion de fond vraiment facile vu le sujet du monopole (WMP qui est sans doute la partie de Windows qui a le plus de concurrence...).

C'est pour ça qu'ils veulent compléter l'API Gnome# pour ne pas entendre ce genre de remarques ;)

Comme je l'ai dit plus haut, un langage porté sur la JVM ne respecte aucun standard, aucune norme pour les types, les appels de fonctions, etc. Bref, tout l'intérêt de l'interopérabilité est perdu. De plus l'absence de la notion de pointeurs limite l'interopérabilité avec l'existant et la création d'API bas-niveau.

ce qui n'est pas normalisé c'est ce qui est dépendant de Windows, bref, on s'en fou plus ou moins dans le contexte, c'est intéressant et c'est présent juste pour faciliter la migration vers nunux.

tu n'as pas bien compris.
1 des objectifs de MDI c'est de pouvoir proposer un API indépendant du langage, entendre par là ne pas avoir à supporter plusieurs bindings.

XAML c'est pour Windows à la base, je vois pas torp le rapport... Ce qui veut être repris dans XAML c'est le principe de correspondance entre les classes .NET et les balises XML... Bref, celà peut être le plus simplement du monde adapté à GTK# par exemple.

Pour ce qui est d'utiliser les librairies .NET de Microsoft, je vois pas trop, vu que MDI s'acharne à tout réécrire... De plus le but n'est pas d'utiliser les API windows sous Nux, c'est ici juste pour la compatiblité et attirer les développeurs windozien et faciliter la transition vers Linux, sinon tu utilises des lib .NET (Mono) 100% GPL au dessus de GTK, de Mozilla, de Qt, etc... je vois vraiment pas où est le problème.

Parcque le leur est en test grandeur nature depuis 2 ans, que ca sert à rien de réinventer la roue et parcque un des buts est d'attirer des développeurs windozien sous nux en favorisant la migration sous nux.

.NET c'est une infrastructure de développement + une machine virtuelle. En théorie, c'est indépendant du langage, mais en pratique la machine virtuelle est fortement optimisée pour exécuter de C# (voire du java). En revanche les pour les autres lanages c'est pas toujours cela (cf. ocaml, eiffel...). D'autre part les librairies .NET ne sont pas libre et non standardisée.
.NET a été conçu pour le langages intégrant la notion d'objet : c'est effectivement une restriction, mais tous les langages modernes semble intégrer cette notion.
Pour ce qui est de l'implémentation des autres langages, wait&see... tu as testé pour juger de la qualité des compilateur et du code généré ?

D'autre part les librairies .NET ne sont pas libre et non standardisée.
Si les parties indépendantes de l'OS. Les parties "hautes", surtout les WinForms ne sont pas standardisées. Est-ce un problème sous Linux où l'on veut plutôt utiliser GTK ou Qt ?
Pourquoi? J'utilise tous les jours les librairies Apache, et ma foi c'est pas pire qu'ailleurs.
Ah tu l'utilises dans n'importe quel langage ? Ou alors t'as triché et tu fais tourner du bytecode Java au dessus de Mono ;)

Pour accéder à des librairies en C depuis Java tu peux soit utiliser le JNI, c'est effectivement un peu lourd mais cela oblige à faire du code (au niveau java) peu près portable. Soit utiliser des interface spécifiques (type CNI pour gcj), c'est plus rapide, plus léger, mais c'est lié à ta machine virtuelle commen c#.
et c'est où le problème ?
Le plus impressionnant c'est C++, tu peux mixer du code .NET et du code C++ traditionnel, ça marche (me demande pas comment) très bien. Si .NET peut être un point de rassemblement pour les API ca me paraît déjà pas mal...

Le but c'est justement de s'en passer. Sinon on utlie du C ou du C++ et c'est tres bien.
Non le but c'est de laisser le langage décider. Tu utilises un langage qui ne gère pas les pointeurs si tu veux. Mais faut laisser le choix. Notamment pour utiliser du code C c'est bien pratique, mais aussi pour des algo bas-niveau.

Pour ton info, plus de langages ont été porté en bytecode Java qu'en MSIL.
Pour ton info ces langages portés ne respectent pas de conventions dans les type, de conventions dans les appels, n'implémentent pas les generics correctement, ne peuvent utiliser les pointeurs 'celà limite tous les langages bas-niveau)... TOut ça pour dire que celà n'apporte pas beaucoup d'intérêt à l'objectif d'interopérabilité... qui est quand même le but si on écoute MDI.

C'est faux. Va regarder le site halcyon
J'ai regarder. J'ai pas trouvé d'exemple concret.
Et la marmotte... si tu regardes de plus près, Java n'est même pas foutu de pouvoir implémenter les generics correctement sur sa propre VM... Nan, que ça marche sur certains morceau de code je veux bien, mais sur des scénario plus compliquer j'y crois pas... Eclipse tourne sur .NET, trouve moi une appli comme celle là en .NET qui tourne sur une machine Java et là peut être que j'y croirait... Mais franchement y'a des parties du code IL .NET qu'on peut pas transposer en Java...


Et d'un point de vue pratique ?

Ben d'un point de vue pratique, Sun a déjà fait valloir ses droits sur ces brevets, pas Microsoft.

Et tu crois que cela empéchera Microsoft de les modifier selon son bon vouloir. Rien ne les oblige. Faut pas être naif :-)).
Désolé mais Microsoft ne peut pas ne pas respecter la norme ISO sinon bonjour la réputation... De plus ce n'est pas du tout dans leur intérêt de casser la compatiblité avec l'existant...

La base de l'OS sera toujours codé en C, la grosse question c'est de proposer un framework complet d'API pour le maximum de langages, c'est ça le vrai problème. Et c'est pour ça que MDI s'est engagé dans Mono...

PLutôt que de proposer une alternative propriétaire sur un OS propriétaire (Java sur Windows), tu préfèrerais pas proposer une alternative libre (Mono) facilitant le portage sous un OS libre (nux) ?

T'as essayé Mono avant de juger de la qualité du compilateur ?
On ne sait pas ce que peut inventer MS pour nous attaquer.
Tu crois que s'il a voulu normaliser et ISOtifier et porter certaines appli sous nux (wmp par exemple), proposer une version FreeBSD et fait un espace de nom Windows indépendant du reste c'est pour ensuite s'amuser à tout foutre en l'air ?
Pour ce qui est du NetRemoting, attendons Indigo qui a l'air d'être tiptop d'après MDI :)

Et voilà pourquoi faut laisser le choix de la syntaxe au programmeur...

les diffrérentes architectures ? bah ca tourne sur x86, sur ppc, et sur un bon nombre de petite plateforme pour pda et autres phone (cf Compact Framework .NET).
Pour Mono, c'est x86 seulement pour le moment, avec déjà en béta SPARC et PPC.
Pour la question des langages, celà reste la meilleur solution pour proposer des API sans avoir à binder comme un fou. De plus la VM accepte la notion de pointeurs, et donc toutes les fonctionnalités d'une architecture matérielle. Tu peux donc faire ce que tu veux... Après effectivement il faudra s'arranger pour que ton code généré soit "CLSCompliant" si tu veux qu'il soit bien intégré avec les autres langages... reste que c'est moins bidouille que CORBA, BONOBO ou les objets COM.... Tu développes ton appli comme d'hab dans ton langage, c'est juste pour les interfaces externes de tes modules (les parties publiques) que tu es obliger de respecter les conventions, pour le reste tu fais ce que tu veux...

je parles pas de F# (en même temps tu l'as essayé ?), je parles de ce que parles un type plus haut, de OCamIL, qui a pour ambition d'être compatible avec OCaml 3.0x et qui a l'air d'être sur la bonne voie...

y'a plusieurs version en cours : pour le moment c'est winlib qui est utilisé pour afficher les winforms, question simplicité. De l'autre côté ils portent entièrement les WinForms en GTK, mais ça prend forcement plus de temps. De toute façon une appli qui se veut de qualité doit penser à l'intégration, et s'il souhaite avoir une appli portable il fait bien entendu des interfaces différentes suivant la plateforme cible, donc bon... GTK# rulez.