Journal Mono pour Android en version 1.0

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
3
6
avr.
2011

Mono (re-implementation de .NET sous license libre) est désormais dispo pour Android cf http://tirania.org/blog/archive/2011/Apr-06.html

Mono était deja disponible pour iOS via MonoTouch (en version 4.0 actuellement).

Attention ! MonoTouch et Mono for Android sont des produits commerciaux (400$ pour les versions pro). Le code source est base sur Mono (MIT/LGPL/GPL) mais monotouch.dll est par exemple closed source.

MonoTouch et Mono for Android permettent d'utiliser les API natives. Comme l'indique de Icaza, le mieux est donc de séparer le noyau de son application de l'interface graphique.
Le noyau est alors identique sur toutes les plateformes, en revanche la GUI est spécifique a chaque plateforme :

  • MonoTouch pour iOS
  • Mono for Android pour Android
  • Silverlight/Mobile pour Windows Phone 7
  • MonoMac pour MacOS X
  • Gtk# pour Linux
  • WPF pour Windows
  • ASP.NET MVC pour les sites web

Dommage que ca ne soit pas open source (ca le sera peut être dans le futur ?) mais je trouve qu'ils ont trouve un bon business plan.
Dommage également que Qt pour Mono ne soit pas supporte de façon officiel au meme titre que Gtk+, ca permettrait de limiter le nombre de GUI differentes a développer.

Attention aux trolls, on n'est pas encore vendredi...

  • # Mouais

    Posté par  . Évalué à 8.

    C'est dommage de faire du closed source. Un modèle mixte à la Qt, c'est quand même mieux.

    Il doit avoir des raisons que je ne devines pas. Mais là comme ça, je dirais que c'est juste des vilains pas beaux.

    Envoyé depuis mon lapin.

  • # Je tiendrai jusqu'à demain

    Posté par  . Évalué à 10.

    Attention aux trolls, on n'est pas encore vendredi...

    Je tiendrai jusqu'à demain
    Je tiendrai jusqu'à demain
    Je tiendrai jusqu'à demain

    Ça pue c'est pas libre et bourré jusqu'à la gueule de brevets!

    J'ai pas tenu jusqu'à demain
    J'ai pas tenu jusqu'à demain
    J'ai pas tenu jusqu'à demain

    • [^] # Re: Je tiendrai jusqu'à demain

      Posté par  . Évalué à -4.

      Je vais me faire moinsser mais tant pis : parce que le noyau Linux n'est pas bourré de brevets ?

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: Je tiendrai jusqu'à demain

        Posté par  . Évalué à 1.

        Lesquels? Microtruc a prentendu cela il y a plusieurs annees et on attend encore de savoir lesquels et dernierement lorsqu'ils ont decrit les quelques soit disant violation de brevet (5) cela n'a strictement rien avoir avec le kernel.

        http://linuxfr.org/users/albert_/journaux/le-retour-des-methodes-mafieuses

        • [^] # Re: Je tiendrai jusqu'à demain

          Posté par  . Évalué à 9.

          Pareil pour Mono : lesquels ?

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Je tiendrai jusqu'à demain

            Posté par  (site web personnel) . Évalué à 3.

            Pas mal la démonstration en 2 étapes :)
            AHMA La menace des brevets sur Mono s'amenuise avec le temps

          • [^] # Re: Je tiendrai jusqu'à demain

            Posté par  . Évalué à -5.

            Je te laisse chercher c'est un sujet qui ne m'interesse pas vu que mono degage de mon ordi. Mais bon vu que Microsoft brevete la moindre pisse sortant de chez lui, C# est bourre de brevet et il me semble bien que seul la version ECMA, une tres vieille version de ce truc, a la promesse de non utilisation des brevets. Il me semble bien que mono ne se limitant pas du tout a cette version, il est a peu pres certains que des brevets microtruc sont utilise dedans.

            Et vu que microtruc a bien affirme recemment son cote "gros connard de cours de recreation qui tape sur les plus petit pour les racketter" ca m'etonnerait pas qu'ils attendent juste le bon moment pour attaquer sur ce sujet. Pour le moment ils s'abstiennent car ils veluent tenter de faire croire que ce sont des gentils mais il faut vraiment etre un bisounours (ou etre paye par cette boite) pour leur faire confiance.

            • [^] # Re: Je tiendrai jusqu'à demain

              Posté par  . Évalué à 5.

              Ah ben c'est facile de critiquer sans avoir de source. C'est bien simple : pas de preuve, pas d'accusation plausible.

              Pour le noyau Linux, il y en eu au moins une : l'implémentation des doubles noms de fichiers dans FAT32. Il me semble que ça a été corrigé, mais c'est arrivé (même si c'est complètement con).

              Rien ne dit que c'est encore le cas, mais c'est alors la même chose pour Mono. Et je ne crois pas que l'OIN existe juste pour faire joli.

              Pour ce qui est de ces assertions de brevet violés, je te copie cet extrait de la page Wikipédia de Mono :

              Mono consiste en quatre groupes de composants :
              - les composants principaux [...] construits selon les normes Ecma-334 et Ecma-335;
              - la couche de développement Mono/Linux/GNOME ;
              - la couche de compatibilité Microsoft ;
              - les outils.

              Seule la couche de compatibilité pourrait éventuellement poser problème, mais pas le reste. Il suffit de ne pas l'installer, d'autant que sous Linux elle n'est pas nécessaire et n'a pas vraiment d'utilité.

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: Je tiendrai jusqu'à demain

                Posté par  . Évalué à 2. Dernière modification le 09 avril 2011 à 13:24.

                Donc tu es en train de dire:

                • Il n'y a pas de preuves que le kernel linux ne viole pas des brevets microtrucs

                et en meme temps:

                • Il n'y a pas de preuves que mono viole des brevets microtruc

                Tu ne penses pas que ton attitude est "tres" legerement incoherente?

                Donc pour linux, ca fait plus de deux ans que microtruc a fait son FUD sur les 200 brevets viole par linux, en fait cela s'est resolu en un seul qui a ete corrige en une journee... Les 199 autres ont attend toujours la liste. Il y a une semaine une nouvelle attaque de microtruc contre linux (sous la forme d'android) ne concerne pas le kernel.

                Donc deux solutions :

                • microtruc garde les 199 brevets dans sa manche pour faire chier un autre jour
                • les 199 brevets n'ont jamais existe.

                Personnellement je me tape de savoir lesquels brevets mono viole. Le risque que mono viole des brevets de microtruc est tres tres tres important (montre moi une analyse de mono qui valide par microtruc prouve que pas un seul brevet de microtruc ne sont dedans).

                Le benefice d'avoir mono par rapport au risque est tellement en sa defaveur que c'est totalement ridicule de s'obstiner sur ce truc.

                • [^] # Re: Je tiendrai jusqu'à demain

                  Posté par  . Évalué à 6.

                  Il n'y a pas de preuves que le kernel linux ne viole pas des brevets microtrucs et en meme temps:

                  Il n'y a pas de preuves que mono viole des brevets microtruc
                  Tu ne penses pas que ton attitude est "tres" legerement incoherente?

                  Non, je voudrais seulement comprendre : en quoi utiliser Mono serait plus risqué juridiquement que le noyau Linux ?

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: Je tiendrai jusqu'à demain

                    Posté par  . Évalué à 1.

                    Probablement parceque en utilisant des technologies microtruc, vu que microtruc brevete toute pisse sortant de chez eux, tu es a peu pres sur qu'il y a donc des brevets dessus.

                    Jusqu'a preuve du contraire linux n'est pas une technologie microtruc et les 199 autres brevets n'ont toujours pas ete prouves. Cela ne veut naturellement pas dire qu'il y a pas un ou deux brevets que linux violeraient mais bon vu le niveau d'avance de linux pour sortir un brevet innovant sans que cela soit deja depuis longtemps soit implemente, soit dans les mails lists ca va etre rigolo.

                    Au passage, le brevet viole par linux dont tu as parle montre bien le probleme de mono vu que justement ce brevet implique une technologie microtruc et donc concerne un outil qui permet de communiquer avec le monde windbidule et non pas quelque chose de fondamental a linux.

                    • [^] # Re: Je tiendrai jusqu'à demain

                      Posté par  . Évalué à 5.

                      Jusqu'a preuve du contraire linux n'est pas une technologie microtruc

                      Jusqu'à preuve du contraire, Mono n'est pas une technologie Microsoft.

                      C'est l'implémentation d'une norme standardisée ECMA et ISO, accompagnée d'outils propres et d'outils de compatibilité non nécessaires à son fonctionnement et pouvant être écartés.

                      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                      • [^] # Re: Je tiendrai jusqu'à demain

                        Posté par  . Évalué à -1.

                        Ah tiens C# n'est pas une technologie microtruc. Je ne savais pas. Tu peux me donner le nom et le lien de l'entite qui a pondu cela?

                        J'ai deja repondu en ce qui concernait ECMA (il me semble pas que cela soit passe a l'ISO meme si je pense que microtruc peut payer encore quelques personnes pour faire passer un truc ou tout est a faire), la version C# de l'ECMA, et donc celle concerne par les promesses de non agression est tres ancienne et ne correspond plus du tout a l'etat actuel de mono.

                        • [^] # Re: Je tiendrai jusqu'à demain

                          Posté par  . Évalué à 4.

                          Ah tiens C# n'est pas une technologie microtruc

                          C# n'est pas la technologie mais un langage. Mono et .Net en sont des implémentations.
                          Oui je joue sur les mots, mais le vocabulaire est important si on veut jouer dans le domaine juridique.

                          J'ai deja repondu en ce qui concernait ECMA (il me semble pas que cela soit passe a l'ISO meme si je pense que microtruc peut payer encore quelques personnes pour faire passer un truc ou tout est a faire), la version C# de l'ECMA, et donc celle concerne par les promesses de non agression est tres ancienne et ne correspond plus du tout a l'etat actuel de mono.

                          Ben tu n'oublieras pas de corriger Wikipédia alors :

                          Les composants principaux incluent le compilateur C#, la machine virtuelle et les bibliothèques de classes de base. Ces composants sont construits selon les normes Ecma-334 et Ecma-335, permettant à Mono de fournir une machine virtuelle en ligne de commande compatible avec les normes établies, libre et ouverte.

                          Et :

                          Le C♯ a été normalisé par l'ECMA (ECMA-334) en décembre 2001 et par l'ISO/CEI (ISO/CEI 23270) en 2003.

                          Et en citant tes sources, pour changer.

                          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: Je tiendrai jusqu'à demain

                Posté par  (site web personnel) . Évalué à 5.

                Seule la couche de compatibilité pourrait [...] poser problème [...] sous Linux elle n'est pas nécessaire et n'a pas vraiment d'utilité.

                LINQ, ADO.Net, WCF, WF, XML, HTTP... Si tu fais du C# t'es pratiquement obligé d'utiliser des composants de .NET (même sous Linux) qui donc ne font pas partie des normes ECMA (sauf a re-inventer la roue évidemment).
                ECMA couvre seulement le langage lui même, pire C# 3 et 4 ne sont pas couvert, la dernière norme date de 2006 -> une éternité !

                Il a un risque plus important que pour d'autres logiciels libres. Mais Microsoft ne peut pas non plus 10 ans après les faits se plaindre de la violation d'un brevet. Il me semble qu'il est du devoir du détenteur d'un brevet de le faire valoir dans un délais "raisonnable".
                Mon avis est donc qu'il ne se passera rien ou au pire des représailles anecdotiques.

                Les développeurs de Mono ne sont pas idiots, ils ont bien conscience des risques de brevets. Cf Icaza en 2006 http://tirania.org/blog/archive/2006/Nov-04.html

                I do not know of any patents which Mono infringes.

                Et s'ils en rencontraient :

                [...] (1) work around the patent by using a different implementation [...] if that is not possible, we would (2) remove the pieces of code that were covered by those patents, and also (3) find prior art that would render the patent useless.

                La FAQ de Mono est également assez clair sur le sujet http://www.mono-project.com/FAQ:_Licensing#Patents

                Conclusion : le risque n'est pas nul mais assez faible a mon avis

                • [^] # Re: Je tiendrai jusqu'à demain

                  Posté par  . Évalué à 1.

                  Il a un risque plus important que pour d'autres logiciels libres. Mais Microsoft ne peut pas non plus 10 ans après les faits se plaindre de la violation d'un brevet. Il me semble qu'il est du devoir du détenteur d'un brevet de le faire valoir dans un délais "raisonnable".
                  Mon avis est donc qu'il ne se passera rien ou au pire des représailles anecdotiques.

                  Ca c'est ton souhait, le probleme c'est que la loi ne dit pas cela et donc il n'y a strictement aucune garantie sur le sujet, au contraire.

                  Si tu parles avec des avocats americains sur les brevets, le truc c'est justement l'inverse. Avoir des brevets dit dormants que tu ressorts lorsque que tu peux faire cracher quelqu'un ou que tu veux t'en debarasser (comme dans le cas de microtruc).

                • [^] # Re: Je tiendrai jusqu'à demain

                  Posté par  (site web personnel) . Évalué à 6.

                  ECMA couvre seulement le langage lui même

                  Non. ECMA couvre bien plus : la VM, le runtime et toutes les libs de base (IO, XML, HTTP, etc.).
                  Les briques non standardisées sont les briques de haut niveau : WCF (c'est Novell qui a les brevets clés), WF (pas implémenté par Mono), WPF (non plus), ASP.NET (deprecated, remplacé par ASP.NET MVC, sous licence libre).

                  Il a un risque plus important que pour d'autres logiciels libres

                  Contrairement à d'autres logiciels libres, Mono est une implémentation conforme, et est donc couvert par les engagements de Microsoft, tout le contraire des plateformes très proches et avec des concepts clairement identiques, type Java/Dalvik ou encore Vala.

                  • [^] # Re: Je tiendrai jusqu'à demain

                    Posté par  (site web personnel) . Évalué à 3.

                    ECMA couvre bien plus

                    Effectivement, il y a 2 normes ECMA (334 et 335).
                    ECMA 335 couvre la CLI et apparemment tout System.* (notamment XML, HTTP, IO...)
                    http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-335.pdf et la dernière mise a jour date de décembre 2010 !

                  • [^] # Re: Je tiendrai jusqu'à demain

                    Posté par  . Évalué à 2.

                    Je vois pas ce que vala pourrait violer, sauf à interdire à des gens d'écrire ...

                    Quant à Mono, moi, je sais pas, mais là, le mec , il demande 400$ , et à ce prix, j'ai un ordinateur sous Windows, Visual Express, le SDK pour WP7, Eclipse et le SDK pour Android.
                    Ou un-demi MacBook et le SDK pour l'Iphone+ Eclipse et le SDK Android.
                    Franchement, ça donne pas envie...

                    Sedullus dux et princeps Lemovicum occiditur

                    • [^] # Re: Je tiendrai jusqu'à demain

                      Posté par  (site web personnel) . Évalué à 0.

                      Je vois pas ce que vala pourrait violer, sauf à interdire à des gens d'écrire ...

                      http://linuxpatents.blogspot.com/2010/05/language-envy.html

                      Franchement, ça donne pas envie...

                      Pour un particulier on est d'accord. La cible, c'est les entreprises : 400$, c'est le tarif d'une journée d'ingénieur de base. C'est très largement rentabilisé si ca permet d'économiser une montée en compétence sur Objective-C, ou mieux, une journée d'installation d'Eclipse ;)

                      • [^] # Re: Je tiendrai jusqu'à demain

                        Posté par  . Évalué à 2.

                        Je vois pas ce que vala pourrait violer, sauf à interdire à des gens d'écrire ...

                        http://linuxpatents.blogspot.com/2010/05/language-envy.html

                        Tiré du blogpost :

                        A quick look through the patent system reveals Vala is infringing happily left and right on Microsoft property. Let us see what our Google-fu renders:
                        A visual development system is described which provide "method pointers" allowing a developer/user to achieve delegation between objects programmatically as well as visually. Delegation "binds" an event source with an event handler. This binding is directly supported within the programming of the system.
                        The Vala Tutorial:
                        Delegates represent methods, allowing chunks of code to be passed around like objects.

                        Donc ce que ce "brevet" couvre :

                        typedef void (*delegatetype)(int);
                        
                        void apply(delegatetype d, int p) {
                            (*d)(p);
                        }
                        
                        (c'est du C)

                        C'est une blague ? T'en as beaucoup d'autres des brevets aussi "novateurs" ?

                        • [^] # Re: Je tiendrai jusqu'à demain

                          Posté par  . Évalué à 2.

                          ouais, c'est ce que je dis, Vala est juste un compilateur capable de compiler un programme construit selon un langage qui ressemble à C# en langage machine . Et mis à part le fait de toucher au contenu du développeur lui-même , il n'y a qu'une coquille vide. Rien.
                          D'ailleurs les brevets couvrant les objets, va falloir qu'on m'explique en quoi un binaire compilé par ValaC puis par GCC enfreint un brevet sur dotnet.
                          Et en quoi un développeur qui utilise vala lorsqu'il écrit, peut utiliser un outil qui enfreint ce brevet ?

                          Alors que Mono, c'est une implémentation libre , par Manu de dotnet.
                          Et le fait de se réjouir du rachat de Nokia par Microsoft comme il l'a fait dans son blog m'incite à ne pas regarder ce qu'il produit.

                          Sedullus dux et princeps Lemovicum occiditur

                        • [^] # Re: Je tiendrai jusqu'à demain

                          Posté par  (site web personnel) . Évalué à 0.

                          Donc ce que ce "brevet" couvre : [...]

                          Non, ton n'exemple n'est pas bon, et le brevet ne couvre pas les classiques pointeurs de fonction. Les "delegates" en C# pointent vers une méthode dans le contexte d'un objet particulier.

                          Concrêtement si je fais en C# :

                          button1.Click += OnClickMethod;

                          où OnClickMethod est une méthode d'instance (et non pas une fonction "static" ou "globale" comme ton exemple en C). Le compilateur rattache automatiquement l'instance de l'objet qui fait l'action pour former un couple instance+pointeur_methode.

                          Tu as voulu copier l'exemple Vala et le traduire en C, en fait il fallait plutôt que t'essai de traduire le 2ème exemple. Forcement t'aurais pas réussi sans faire une référence explicite à une structure pour simuler un objet, là où le brevet concerne justement une référencement implicite et automatique.

                          Après je vais pas dire que c'est une révolution ou même une invention, juste une petite évolution qui permet à C# d'avoir une façon simple de passer une méthode d'instance en tant qu'objet. (Exemple : abonnement/désabonnement à un événement).

                          • [^] # Re: Je tiendrai jusqu'à demain

                            Posté par  . Évalué à 3.

                            Ok ok, tu veux parler de ça ?

                            % ./python 
                            Python 1.2 (Apr  9 2011) [GCC 4.3.3]
                            Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
                            >>> class A:
                            ... 	def m(self):
                            ... 		print self.foo
                            ... 
                            >>> a=A()
                            >>> a.foo=42
                            >>> a.m()
                            42
                            >>> a.m
                            <method A.m of A instance at 9491258>
                            >>> def call(f):
                            ... 	f()
                            ... 
                            >>> call(a.m)
                            42
                            

                            (Oui, je suis allé chercher python 1.2 (1995 selon wikipedia, déjà antérieur au brevet), je n'ai pas essayé avec python 1.0 mais je soupçonne que ça fonctionnait déjà)

                            • [^] # Re: Je tiendrai jusqu'à demain

                              Posté par  (site web personnel) . Évalué à 1.

                              Non plus, tu explicites toujours l'objet dans l'expression a.m (a est la référence explicite)

                              • [^] # Re: Je tiendrai jusqu'à demain

                                Posté par  . Évalué à 2.

                                Alors, je ne comprends toujours pas, dans le deuxième exemple Vala, je lis "DelegateType d1 = foo.f1;" donc bien une référence à "foo". Dans ton exemple C#, où se trouve la "OnClickMethod" ? Dans la classe où la ligne que tu donnes se trouve ?

                                • [^] # Re: Je tiendrai jusqu'à demain

                                  Posté par  (site web personnel) . Évalué à 1.

                                  Effectivement le OnClickMethod se trouve dans la même classe que la ligne que je donne.

                                  Après vérification, la différence avec ton exemple Python n'est pas la référence implicite mais dans la notion même de Delegate : c'est une signature de méthode (d'instance ou non). Forcement en Python une signature n'a aucun sens vu que y'a pas de typage fort et statique par le compilateur.
                                  Le titre du brevet est assez explicite :

                                  "Development system with methods for type-safe delegation of object events"

                                  Il n'y a ce besoin de sécurité de type en Python, donc pas de notion de Delegate comme en C# ou en Vala.

                                  • [^] # Re: Je tiendrai jusqu'à demain

                                    Posté par  . Évalué à 3.

                                    En bref, ce brevet est ridicule, le passage de contexte, on savait le faire (cf. python), et le type-safe on savait le faire (cf. C)...

                                    • [^] # Re: Je tiendrai jusqu'à demain

                                      Posté par  (site web personnel) . Évalué à 0.

                                      le type-safe on savait le faire (cf. C) C'est une blague j'espère ? Le C type-safe... Tu cast sans que ca pose le moindre problème au compilateur.

                                      Bref, dans tous les cas, juger le brevet "ridicule" ne changera rien au fait que tu n'es pas trouvé d'antériorité pour un "type-safe delegation of object" tel que détaillé dans le brevet. Et puis tu n'as pris que le premier brevet cité : on est pas juriste, ni l'un ni l'autre, mais si on en revient à la discussion initiale, il est clair que des langages comme Vala ou Java implémentent des "fonctionnalités" issues de C#, et qu'à ce titre ces langages sont au moins aussi dangereux que l'implémentation C# de Mono, pour ne pas dire plus.

                                      • [^] # Re: Je tiendrai jusqu'à demain

                                        Posté par  . Évalué à 2.

                                        Le C type-safe... Tu cast sans que ca pose le moindre problème au compilateur.

                                        C'est un pléonasme, le cast (quel que soit le langage) n'a jamais servi à rien d'autre qu'à permettre au développeur de rendre le compilateur content, soit en lui forçant la main (cast C), soit en lui disant de la fermer et de ne vérifier qu'au runtime (dynamic_cast, casts Java). Si tu veux être type-safe, tu n'utilises pas de casts, et ça tombe bien, c'est possible pour les pointeurs de fonctions en C.

                                        • [^] # Re: Je tiendrai jusqu'à demain

                                          Posté par  (site web personnel) . Évalué à -1.

                                          Ok, changeons de troll et partons sur le côté type-safe de C :)

                                          Moi j'entend par type-safe le fait de t'empêcher de faire des cast idiots justement. En C tu peux passer l'adresse une zone mémoire contenant de la donnée en tant pointeur de fonction... Une hérésie source de bugs/failles que C# ne t'autorise pas : impossible de transformer de la donnée en code exécutable, même avec un cast, et dès la compilation.

                                  • [^] # Re: Je tiendrai jusqu'à demain

                                    Posté par  . Évalué à 3.

                                    En gros, si j'ai bien compris, c'est la même chose que boost::bind en C++ ? Sachant que boost::bind n'est qu'une généralisation de fonctions de la STL (bind1st, mem_fun...), qui datent de 1994 ?

                                    • [^] # Re: Je tiendrai jusqu'à demain

                                      Posté par  (site web personnel) . Évalué à 1.

                                      Ce n'est pas du tout la même chose : Bind est une "fonction" là où un Delegate est un "type", type qui défini une méthode (d'instance ou non).

                                      • [^] # Re: Je tiendrai jusqu'à demain

                                        Posté par  . Évalué à 2.

                                        Dans le cas de boost::bind, le type c'est boost::function<int(char,float)> (fonction prenant un char et un float et retournant un int). boost::bind permet de généraliser et d'utiliser par exemple une méthode de tel objet, ou une fonction à trois paramètres en disant que le deuxième est NULL, ou une combinaison des deux. Je ne vois pas en quoi ça n'a "rien à voir".

                                        Ou si on utilise que la STL, on est limité au méthodes ne prenant qu'un argument, et le type est template <T> binder1st<T,Argument>, il faut juste effacer le type T avec du type erasure.

                                        • [^] # Re: Je tiendrai jusqu'à demain

                                          Posté par  (site web personnel) . Évalué à 1.

                                          Changeons de méthode parcque là on va pas y arriver.
                                          Traduit en C++ avec boost le code C# suivant (suffisament explicite je pense) :

                                          delegate int OperationDelegate(int a, int b);
                                          
                                          public class Console
                                          {
                                            public void Print(OperationDelegate del){
                                              var res = del(42, 3); //appel sans crainte, del est type-safe.
                                              printf(res + 5);
                                            }
                                          }
                                          
                                          public class Exemple
                                          {
                                            int i = 42;
                                          
                                            public void Test(){
                                              var c = new Console();
                                              c.Print(add);
                                              c.Print((a,b) => a - b); //variante avec code inline.
                                            }
                                          
                                            public int add(int a, int b){ return a + b + i; } //méthode d'instance
                                          }
                                          
                                          • [^] # Re: Je tiendrai jusqu'à demain

                                            Posté par  . Évalué à 3.

                                            #include <boost/function.hpp>
                                            #include <boost/bind.hpp>
                                            #include <iostream>
                                            
                                            typedef boost::function<int(int,int)> OperationDelegate;
                                            
                                            struct Console {
                                                 void Print(OperationDelegate del) {
                                                      int res = del(42,3); // appel safe pasque gnagnagna
                                                      std::cout << res << std::endl;
                                                 }
                                            };
                                            
                                            class Exemple {
                                                int i;
                                            public:
                                                Exemple() : i(42) {}
                                                int add(int a, int b) { return a + b + i; }
                                                int add3(int a, int LOL, int b) { return (a + b + i)*LOL; }
                                                void Test() {
                                                     Console c;
                                                     c.Print(boost::bind(&Exemple::add, this, _1, _2));
                                                     c.Print(boost::bind(&Exemple::add3, this, _1, 1 /* valeur de LOL */, _2));
                                                     // variante inline pour c++11
                                                     c.Print([](int x, int y) { return x + y; });
                                                }
                                            };
                                            

                                            Oui, et ensuite ?

                                            • [^] # Re: Je tiendrai jusqu'à demain

                                              Posté par  (site web personnel) . Évalué à 1.

                                              Oui, et ensuite ? Merci, t'as mis en avant tout ce qu'apporte le brevet.

                                              il te faut écrire :

                                              c.Print(boost::bind(&Exemple::add, this, _1, _2));
                                              

                                              là où moi j'écris simplement :

                                              c.Print(add).
                                              

                                              Différences :

                                              • tu passes un pointeur de fonction en paramètre : un pointeur foireux et tu exploses méthode print.

                                              • tu es obligé de passer des trucs sans intérêts que le compilateur C# déduit automatiquement : l'objet cible (this dans ton exemple) et les paramètres (on s'en cogne s'est l'appelé qui les remplis.

                                              • t'as variante inline est beaucoup trop récente pour servir de prior-art ;)

                                              • en l'occurence boost::bind n'apporte rien par rapport au simple typedef en C pour déclarer une signature de méthode : même inconvénients, une syntaxe toujours aussi lourde pour l'appelant et toujours aussi peut type-safe.

                                              • [^] # Re: Je tiendrai jusqu'à demain

                                                Posté par  . Évalué à 3.

                                                • Il faudra m'expliquer en quoi &Exemple::Add est un pointeur foireux. Parce que pour le reste, les pointeurs sur méthodes sont chiants à déclarer et manipuler, et donc personne le fait.
                                                • Ce n'est pas sans intérêt, je rappelle ici qu'on est en C++. Ce pointeur ne sert pas tant à dire quel objet ça s'applique mais surtout comment est la relation de propriété (qui va s'occuper de l'objet, qui va le détruire). bind pourrait très bien être propriétaire de l'objet ou avoir une propriété partagée. Et non, il n'y a pas de relation de propriété qui convient dans tout les cas.
                                                • Je ne vois rien d'inline dans les brevets.
                                                • La syntaxe n'est pas lourde, comparé à d'autres aspects du C++. Et elle est surtout bien plus puissante. Si tu à deux événements et que tu doit faire la même chose à un paramètre près, tu n'est pas obligé de te farcir deux méthodes qui en appelle une troisième. Tiens vais faire un brevet :) ...
                                                • [^] # Re: Je tiendrai jusqu'à demain

                                                  Posté par  (site web personnel) . Évalué à 1.

                                                  • Il faudra m'expliquer en quoi &Exemple::Add est un pointeur foireux.

                                                  Cet exemple précis n'est pas foireux. Mais en tant que rédacteur de la méthode Print, je n'ai aucune garantie que l'appelant fasse comme toi : on peut imaginer qu'il fasse un gros cast bien crade pour obtenir un pointeur de fonction, on peut imaginer qu'il utilise même pas la fonction bind, bref c'est pas type-safe. Il peut aussi se louper pour le 2ème paramètre de bind, re big explosion.

                                                  D'où le brevet déposé : fournir un mécanisme type-safe, directement intégré dans le langage, qui empêche ce genre de problème.

                                                  • Ce n'est pas sans intérêt,

                                                  C'est sans intérêt par rapport au brevet qui nous intéresse. Nul doute que Bind a d'autres intérêts.

                                                  • Je ne vois rien d'inline dans les brevets.

                                                  http://www.google.com/patents/about?id=iT-ZAAAAEBAJ

                                                  De rien.

  • # Closed???

    Posté par  (site web personnel) . Évalué à 2.

    Si il y a vraiment du code GPL dans Mono (comme c'est dit dans la dépêche), comment on peut faire une dll closed source en ce basant dessus (comme c'est dit dans la dépêche) ?

    Qu'en pense http://gpl-violations.org/ ?

    • [^] # Re: Closed???

      Posté par  (site web personnel) . Évalué à 7.

      Parcque c'est les mêmes auteurs qui font Mono et MonoDroid. Ils ont le droit de publier leur code sous toutes les licences qu'ils veulent, MIT/GPL/Proprio.

      La question se serait effectivement posée différement si MonoDroid était réalisé par un tiers.

      • [^] # Re: Closed???

        Posté par  (site web personnel) . Évalué à 3.

        La question se serait effectivement posée différement si MonoDroid était réalisé par un tiers.

        Même pas, la licence MIT (concerne les librairies et le compilo) est quasi-identique a la BSD donc tu fais ce que tu veux.

        c'est les mêmes auteurs qui font Mono et MonoDroid

        Oui et non, il y a des contributeurs externe a Novell sur Mono...
        Mais Novell demande l'assignement du copyright pour certaines parties de Mono (de plus en plus désuet j'imagine avec le basculement vers la licence MIT).

  • # L'eternelle question

    Posté par  . Évalué à -2.

    Euh mais en vrai ça sert à quoi mono.
    Si il y a une chose qui ne manque pas sous linux ce sont les langages de programmation.
    Certes il y a des trucs genre banshee qui utilise ce truc mais est ce que vous avez déjà dans votre vie professionnelle eu des projets/appli qui tournent sous mono ? Si on veux faire du .net autant prendre carrément du windows non ? Avec mono on n'est on pas de toute façon limité par rapport à ce que l'on a sous windows ? Ca me semble vraiment douteux comme solution et de plus c'est un piège trop flagrant (Embrace, extend and extinguish).

    • [^] # Re: L'eternelle question

      Posté par  . Évalué à 3.

      C'est vrai, ça.

      À quoi sert Ruby, puisqu'on a Python ?
      À quoi sert Python, puisqu'on a Perl ?
      À quoi sert Perl, puisqu'on a C ?
      À quoi sert C, puiqu'on a l'assembleur ?

      Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

      • [^] # Re: L'eternelle question

        Posté par  . Évalué à -2.

        Et a quoi ca sert d'avoir android et linux puisqu'on a deja ios et macos?

        Et, oh, c'est 'dredi, hein!

        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

    • [^] # Re: L'eternelle question

      Posté par  (site web personnel) . Évalué à 4.

      vous avez déjà dans votre vie professionnelle eu des projets/appli qui tournent sous mono ?

      oui.

      Si on veux faire du .net autant prendre carrément du windows non ?

      Ben non justement.

      Avec mono on n'est on pas de toute façon limité par rapport à ce que l'on a sous windows ?

      Non, on a même des choses non dispo sous Windows.

      En l'occurence MonoDroid sert à avoir un socle technique commun pour iPhone/Android/WindowsPhone.

      • [^] # Re: L'eternelle question

        Posté par  . Évalué à 0.

        En l'occurence MonoDroid sert à avoir un socle technique commun pour iPhone/Android/WindowsPhone.

        Ah ah ah la vielle excuse a la con de Elop (Nokia).

        • [^] # Re: L'eternelle question

          Posté par  . Évalué à 4.

          Bah si tu as un autre moyen, n'hésite pas à partager. Ça aidera sûrement TImaniac dans son boulot.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: L'eternelle question

            Posté par  . Évalué à 0.

            Je m'en moque d'aider la vie de Timaniac, pbpg etc

            Je suis plus concerne par ma liberte a moi mais sinon Qt aurait tres bien pu faire l'affaire sauf que .... microtruc a interdit l'installation sur son bousin. Tiens ne serait ce pas pour tenter de forcer les gens a utiliser leur bousin a eux tout bourres de leur brevet a eux?

            • [^] # Re: L'eternelle question

              Posté par  . Évalué à 1.

              C'est loin d'être aussi poussé chez Qt. Avec Mono/.Net, c'est comme en Java, tu compile une fois tu execute partout => pas de cross-compilation.

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

              • [^] # Re: L'eternelle question

                Posté par  . Évalué à 4.

                C'est loin d'être aussi poussé chez Qt. Avec Mono/.Net, c'est comme en Java, tu compile une fois tu execute partout => pas de cross-compilation.

                D'apres l'auteur du journal, avec Mono l'API pour l'interface graphique etant propre a chaque plate-forme, il faut meme recoder l'interface graphique pour chaque plate-forme avant de la recompiler...

                Autant dire que ca semble bien plus couteux qu'avec Qt, qui a une API unique pour toutes les plateformes, utilisant elle-meme les API natives du systeme.

                Excusez l'absence d'accents dans mes commentaires, j'habite en Australie et n'ai pas de clavier francais sous la main.

                • [^] # Re: L'eternelle question

                  Posté par  (site web personnel) . Évalué à 0.

                  Autant dire que ca semble bien plus couteux qu'avec Qt

                  C'est juste pas les mêmes objectifs : l'intérêt n'est surtout pas d'avoir la même IHM partout, mais d'avoir une IHM dédiée parfaitement intégrée sur toutes les plateformes.

                  Si c'est pour faire la même interface partout, autant faire du web mobile.

                • [^] # Re: L'eternelle question

                  Posté par  . Évalué à -1.

                  tant mieux s'il faut reecrire l'interface!!

                  Ca eviteras d'avoir des interfaces pourries concues pour un point'n'click sur un telephone tactile ou autres affreusetes que les frameworks "portables" generent.

                  If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

              • [^] # Re: L'eternelle question

                Posté par  . Évalué à 2.

                Avec Mono/.Net, c'est comme en Java, tu compile une fois tu execute partout

                Non, tu exécutes là où un environnement d’exécution est disponible, ce qui est très différent de « partout ».

                Je n’ai rien contre Java (enfin, si, mais c’est pas le jour), mais le slogan mensonger « write once, run everywhere » me fait voir rouge depuis que je n’ai pas réussi à trouver une JVM qui fonctionne sur un GNU/Linux sur Mac PPC.

            • [^] # Re: L'eternelle question

              Posté par  . Évalué à -3.

              Clair que Qt sur iphone, ca doit poutrer copieux.
              De meme l'utilisation a travers java pour android, ca doit etre super sexy.

              If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

      • [^] # Re: L'eternelle question

        Posté par  . Évalué à 0.

        Meme si je comprends bien l'idee derriere, a savoir un core ecrit une fois et ensuite interface avec une gui native, je me pose des questions sur l'interet de la chose.

        D'une part, une appli mobile c'est generalement essentiellement de la gui quand meme. Ya bien evidemment des applis qui ont domaine complique necessitant un reel effort d'ingenierie (les jeux notamment?) mais ca reste souvent "choppes ton json sur le serveur, assembles le, donne ca a manger a l'interface et si le product manager s'est lache, persiste le sur disque.".

        Je me demande quel est le gain compare aux inconvenients, le plus gros etant le fait de melanger plusieurs langages et de se taper un compilation des plus relou a chaque modif du core, et donc de jongler entre ide et chaines de compiles pour ajouter un pauvre champ a une classe.

        Le deuxieme inconvenient, on perd (enfin, j'imagine) la possibilite d'utiliser des api natives pourtant bien utiles.
        iOS et GCD pour les traitements asynchrones/en arriere plan, c'est foutrement efficace. CoreData est bien pratique aussi. J'imagine qu'android a ses specificites qu'aucun dev android ne veut lacher.

        Quid de trucs tres tres specifiques a la platforme, genre api geo localisation, gyroscope, camera et tout le tralala?

        If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

        • [^] # Re: L'eternelle question

          Posté par  (site web personnel) . Évalué à 3.

          mais ca reste souvent "choppes ton json sur le serveur, assembles le, donne ca a manger a l'interface et si le product manager s'est lache, persiste le sur disque.".

          Ca fait déjà la moitié qui est indépendant du toolkit graphique. C'est déjà ca.

          le plus gros etant le fait de melanger plusieurs langages

          Justement c'est l'inverse : un projet multi-OS mobile "classique" conduit à faire de l'objective-C, du Java, du C#. Mono propose un unique langage pour toutes les plateformes.

          se taper un compilation des plus relou a chaque modif du core

          Pas plus relou qu'avec un projet classique multi-OS mobile.

          Le deuxieme inconvenient, on perd (enfin, j'imagine) la possibilite d'utiliser des api natives pourtant bien utiles.

          T'imagine justement très mal : ils ont justement fait le choix de ne pas avoir une API qui soit un dénominateur commun, mais de créer des bindings pour l'intégralité des API de la plateforme cible. L'objectif est clairement de ne rien perdre en terme de fonctionnel.

          • [^] # Re: L'eternelle question

            Posté par  . Évalué à -1.

            Ca fait déjà la moitié qui est indépendant du toolkit graphique. C'est déjà ca.

            Plutot 15-20%, a la louche ;)

            Justement c'est l'inverse : un projet multi-OS mobile "classique" conduit à faire de l'objective-C, du Java, du C#. Mono propose un unique langage pour toutes les plateformes.

            Donc en fait, tu fait tout en mono, c'est ca? Ce que j'en avais comprit, c'est que mono pondait un lib statique avec le core, et qu'apres il restait plus qu'a linker avec le projet natif.

            Comment vous contournez la limitation de l'app store ou l'appli doit avoir ete ecrite en c/c++/objc?

            Mais du coup, les auteurs se sont tapes l'integralite des bindings vers cocoa par exemple?

            If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

    • [^] # Re: L'eternelle question

      Posté par  . Évalué à 4.

      Le seul truc c'est que mono n'est pas un langage. C'est une plateforme au dessus tu peut utiliser pleins de langages C#, F#, etc... et ils peuvent tous communiquer entre eux.

      Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: L'eternelle question

        Posté par  . Évalué à 1.

        J'ai la même chose à la maison, ça s'appelle Linux, il y a plein de langage qui communique entre eux dessus ! Pipe, socket et tout.

        De quoi j'ai pas compris et c'est pas pareil ?

        • [^] # Re: L'eternelle question

          Posté par  . Évalué à 2.

          Et comment puis-je utiliser une bibliothèque python en ocaml (par exemple) ?

          • [^] # Re: L'eternelle question

            Posté par  . Évalué à 5.

            Avec PyCaml.
            Sinon via le module Unix ou Sys, suivant ce que tu veux faire exactement.

            De rien.

          • [^] # Re: L'eternelle question

            Posté par  . Évalué à 1.

            Pourquoi est-ce que tous les langages auraient le devoir d'interagir entre eux ? Ils peuvent avoir des concepts tellement différents que la couche d'adaptation sera non négligeable.
            Comment un langage sans classes (C) pourrait appeler "facilement" des méthodes d'un langage à classes uniquement (Java) ? Comment faire interagir des langages à évaluation lazy et des langages non-lazy ? Etc...

            • [^] # Re: L'eternelle question

              Posté par  . Évalué à 1.

              Par "couche d'adaptation", j'entends le prix que le dev qui voudra faire communiquer 2 langages, devra payer dans son code : l'overhead en terme de code et de syntaxe, pas l'overhead à l'exécution.

              Si l'on fait une bibliothèque dans un langage et qu'on vise l'utilisation dans un autre langage précis, on pourra obtenir quelque chose de quasi-natif en terme de code, par exemple pas mal de la lib standard de python est implémentée en C, et cette lib s'utilise très facilement. (Si par contre on a une lib C, conçue pour du C, et qu'on veut l'utiliser en Python, il faudra un wrapper, un peu chiant à écrire mais il y a pire). Si l'on veut que la lib soit utilisable dans plein de langages, même avec ce magnifique "machin" qu'est .net, je doute que l'interaction entre différents langages supportés (sans parler de langages vraiment très différents) soit gratuite en terme de code.

        • [^] # Re: L'eternelle question

          Posté par  . Évalué à 7.

          Et c'est les même qui crient comme des gorets quand on leur parle de XML ou JSON.
          Les IPC c'est génial, mais pouvoir garder la sémantiques objets des données sans se farcir une sérialisation XMl ou JSON, c'est pas désagréable non plus.

          Faut arrêter de cracher sur une techno sans y avoir jamais touché et dire que tu as déjà. Oui tu as déjà tout. Tu as un interpréteur sur ta machine qui est turing complet ? He ben potentiellement tout les programmes possibles tu les as sur ta machine, c'est pas beau ça ?

          La différence c'est l'effort que tu dois produire pour obtenir un résultat et le goùut de chacun. Tu préfère utiliser des IPC ? Génial ! Personne ne t'oblige à changer tes habitudes. Pouvoir avoir des interactions fortement couplet entre deux code en deux langages différents ça plaît à certains (comme c'est fait avec swig, JNI ou autre), sauf que là c'est encore plus simple à mettre en place et tu le fait de la même façon pour tout les langages de la plateforme (comme avec Java, Scala et Groovy).

          Au passage, la commutation de contexte faut pas en abuser si tu veut garder tes perfomances de ouf dans ton programme en C (que c'est même pour ça que les langages de haut niveau c'est de la merde).

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: L'eternelle question

            Posté par  . Évalué à 1.

            À l'occasion je me souviendrait de crier comme un gorets (sic) quand on me parlera de JSON ou de XML, j'aime pas décevoir les gens même si je sais pas bien quand est ce que je me suis insurgé à ce propos. Et j'ai pas non plus cracher sur Mono (ou alors on parle pas la même langue).

            My point, comme dise non voisin d'outre-manche, c'est que le fait d’être une plateforme n'est en rien un avantage pour Mono par rapport à l'existant, et que déjà, être une "plateforme", ça veut un peu tout dire. C'est du bullshit marketing quoi.

            Mais bon je te laisse crier comme un goret que vraiment le monde est top injuste, parce que oui, le monde est vraiment trop injuste.

            • [^] # Re: L'eternelle question

              Posté par  . Évalué à 1.

              À l'occasion je me souviendrait de crier comme un gorets (sic) quand on me parlera de JSON ou de XML, j'aime pas décevoir les gens même si je sais pas bien quand est ce que je me suis insurgé à ce propos. Et j'ai pas non plus cracher sur Mono (ou alors on parle pas la même langue).

              Oh ! Comme je suis désolé de t'avoir vexé. Ce que j'aime pas c'est quand les gens viennent avec des préjugés et affirme des choses sans avoir étudié plus que ça de quoi il en retournait.

              My point, comme dise non voisin d'outre-manche, c'est que le fait d’être une plateforme n'est en rien un avantage pour Mono par rapport à l'existant, et que déjà, être une "plateforme", ça veut un peu tout dire. C'est du bullshit marketing quoi.

              Merci de m'apprendre que les mots n'ont pas de sens hors de leur contexte. Là j'ai expliqué que je voulais dire par là qu'il n'est pas lié à un langage précis mais au contraire prévu pour faire communiquer et exécuter différent langage. Si tu veut que je parle de manière plus simple .Net, c'est : une série de langages + un ensemble de bibliothèque + une machine virtuelle + une série d'outils, tous conçu pour travailler ensemble et donc cohérent entre eux.

              Mais bon je te laisse crier comme un goret que vraiment le monde est top injuste, parce que oui, le monde est vraiment trop injuste.

              C'est moi ou tu ne savais pas quoi dire pour réutiliser mon expression ? Parce que là je ne vois vraiment pas ce que tu cherche à dire (peut être que tu regarde Dr House en même temps :) ).

              Bref tout ça pour te dire que faire communiquer des langages entre eux c'est important. Unix a commencé avec tout pleins d'IPC et quelque chose de simple : la sérialisation. On écris dans un format textuel dans un pipe, une socket ou je ne sais quoi et derrière on lis ce que l'autre programme a écris. C'est génial ! Mais quand on veut faire des programmes qui utilisent le paradigme objet, on se retrouve à faire des choses très rébarbatives. Une possibilité est arrivé après c'est d'utiliser des bibliothèques qui vont s'occuper de la serialisation et de la desarialisation d'objets, ça c'est génial, mais généralement pour être portable il faut utiliser XML ou JSON qui ajoutent un temps important dans le "parsage" de ce qui arrive. Là dessus .Net propose une solution qui s'appuie sur une machine virtuelle et l'envoie d'objet directe en binaire.

              Donc voila j'ai pas dis que les IPC ça pue, je te montre juste une fonctionnalités qui est bien différente de "ce que tu as" et qui est intéressant (même si c'est estampillé "mal absolue").

              Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

      • [^] # Re: L'eternelle question

        Posté par  . Évalué à 2.

        C'est bien tu as cite a peu pres les deux seuls langage encore supporte par .Net et tu ne cites pas, curieusement, les ironpython et ironruby. Peut etre que ceux ci ont ete abandonne par Microtruc?

        • [^] # Re: L'eternelle question

          Posté par  . Évalué à 2.

          Je peux citer en plus le VisualBasic, pour le reste très franchement je ne sais pas la liste de langages encore supportés ou non.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: L'eternelle question

            Posté par  . Évalué à 2.

            J'etais ironique lorsque je posais la question. Apres avoir fait tout un buzz (pour reprendre les mots a la mode) sur le cote multilangage de .Net les langages que microtruc ne controlent pas sont degage du framework. Alors oui officiellement c'est de Icaza qui reprend le truc mais bon entre mono/moonlight (qui est encore et toujours 2 versions en retard)/ironpython/ironruby/monodroid/monoiphone etc ils ont enormement de choses a maintenir et a developper alors qu'ils sont tres peu (en comparaison des equipes de microtruc qui n'ont qu'une version reduite de .Net et des trucs associes et tres peu de plateformes a supportes.

            Donc il ne faut pas trop rever sur le developpement de mono et des trucs associes. Cela va etre de plus en plus a la bourre comme l'est moonlight (toujours incapable de permettre d'utiliser netflix il me semble).

    • [^] # Re: L'eternelle question

      Posté par  . Évalué à 2.

      Un autre point important à prendre en compte, est que C# et .Net sont des outils très intéressant pour le développement d'applications.

      Le langage est agréable et efficace, l'API est complète et plutôt bien fichue, et les outils sont de bonne qualité. Il y a le risque des brevets, qui est inexistant pour un projet qui reste en france, mais pourquoi se priver de quelque chose qui est bien ?

      Surtout que le concurrent direct est Java, produit par Oracle.

      Envoyé depuis mon lapin.

      • [^] # Re: L'eternelle question

        Posté par  (site web personnel) . Évalué à 3.

        mais pourquoi se priver de quelque chose qui est bien ?

        • Parce la France, c'est petit. Il y a un truc qui s'appelle "le reste du monde", avec un peu plus de monde...
        • Que le jour ou Microsoft décide de faire pareil que pour J# (pour prendre un exemple parmi d'autres de langages abandonné par Microsoft, on peut aussi parler de VB6 "pas .net" dont Microsoft a cassé complètement la compatibilité et a dit aux développeurs "vos projets VB6, vous pouvez les mettre à la poubelle"), t'es dans la merde (et c'est pas les quelques dev' Mono qui vont pouvoir continuer le support et l'évolution)

        Bref, C#/Mono, c'est mignon pour des projets à court termes, mais je ne mettrais pas mes oeufs dans un truc dont je ne connais pas le support dans 10 ans... (oui, il y a des projets informatiques qui ont pour cible dans 10 ans)

        • [^] # Re: L'eternelle question

          Posté par  (site web personnel) . Évalué à 6.

          et c'est pas les quelques dev' Mono qui vont pouvoir continuer le support et l'évolution

          et c'est pas les quelques dev' de Linux qui vont pouvoir développer un OS

          Pour info les devs de Mono ont implémenté tout .NET + ajouté pas mal de librairies et applications dont Gtk#, MonoDevelop (IDE), Moonlight, MonoDroid, MonoTouch, MonoMac, Gecko#, WebKit#...

        • [^] # Re: L'eternelle question

          Posté par  (site web personnel) . Évalué à 5.

          Que le jour ou Microsoft décide de faire pareil que pour J# [...] , t'es dans la merde

          Tu critiques le problème de la pérénité des solutions proprio avec 1 seule implémentation. Mono n'est pas proprio.

          Si aujourd'hui tu choisis C#, t'as Mono, qui reste un logiciel libre avec une forte communauté derrière : la pérénité semble au moins similaire à une plateforme comme Ruby ou Python par exemple. Bref, Microsoft peut changer de stratégie, il ne se passera pas du tout la même chose qu'avec J# ou VB6 pour les utilisateurs actuels.

          • [^] # Re: L'eternelle question

            Posté par  . Évalué à 5.

            Tu vas quand même avoir du mal à me faire croire que tu aurais tenu le même discours avant que MS ne les abandonnent: "MS va abandonner le J# et tous les développeurs qui travaillaient dessus vont l'avoir dans l'os!"

            Si le même fil avait eu lieu à l'époque, excuse-moi pour le procès d'intention, mais je suis à peu près certain que tu aurais également expliqué en quoi J# et VB6 sont des situations complètement différentes et qu'il n'y a rien à craindre.

            Bref: quand on créé un tel antécédent, il ne faut pas s'étonner que le niveau de confiance en prenne un coup!

            • [^] # Re: L'eternelle question

              Posté par  (site web personnel) . Évalué à 4.

              Tu vas quand même avoir du mal à me faire croire que tu aurais tenu le même discours avant que MS ne les abandonnent

              Et pourquoi ? Je suis un fervent défenseur des logiciels libres (c'est pourquoi je traîne par là), et c'est pourquoi j'ai toujours soigneusement évité VB6 ou J#.

              Bref: quand on créé un tel antécédent, il ne faut pas s'étonner que le niveau de confiance en prenne un coup!

              Justement, Mono a pris les devant en créant une version libre, et on devient indépendant de la stratégie de Microsoft. D'ailleurs la FSF a eu la même idée en lançant un projet similaire. Bon ils ont fédérés personne vu que tout le monde était sur Mono, mais l'intention y était.

        • [^] # Re: L'eternelle question

          Posté par  . Évalué à 3.

          On est pas obligé de coder des choses pour le monde entier et pour dix ans. Une application peux très bien être utilisée uniquement dans un cadre restreint.

          Et on ne fait pas tous de l'informatique dans des multinationales. Imaginons que je développe une application libre en C#. Si les utilisateurs états-uniens ne peuvent pas l'utiliser légalement, j'en ai rien à faire. C'est leur problème, et je ne pense pas qu'ils se gêneront beaucoup à l'utiliser malgré l’illégalité…

          Pour J#, VB6, et certainement beaucoup d'autres, il me semble normal que certaines technologies soient abandonnées par une entreprise telle que Microsoft. Il y a toujours une part de recherche et développement qui mène à rien, même avec des langages de programmation.

          Ensuite, dire que Microsoft pourrait arrêter le support de C# dans moins de 10 ans, c'est comme dire que Oracle pourrait arrêter le support de Java dans moins de 10 ans.

          Envoyé depuis mon lapin.

    • [^] # Re: L'eternelle question

      Posté par  . Évalué à 5.

      étant donné que Java (le langage) et C# sont vraiment très très similaires,

      étant donné que Java (la JVM, le bazar autour, y compris d'autres langages) est très très similaire à .NET et le bazar autour,

      il faudrait surtout se demander, maintenant qu'on a un peu de recul, ce qui a donc bien pu merder avec Java, enfin Sun, pour en arriver là.

      • [^] # Re: L'eternelle question

        Posté par  (site web personnel) . Évalué à 4.

        Il y a plusieurs éléments je penses :

        • JSR XXX : si tu n'a pas ton dictionnaire des JSR tu comprends rien.
        • Ecosystème Multi-éditeurs/Multi-décideurs : trop de choix pour la même JSR (oui faut suivre). T'es bloqué dès le début du projet par le fait de devoir faire des choix.
        • Ecosystème trop vaste : c'est un métier à part entière de le maîtriser.
        • Une philosophie "write once, run everywhere" qui nivelle par le bas : pendant que l'autre propose des toolkits d'IHM sexy et propose différents niveau de compatibilité avec l'existant (natif), Java tente péniblement de sortir un JavaFX et propose JNI pour la compatibilité (sic).
        • Le language est passé d'un mode "leader" à un mode "suiveur" par rapport à C#
          • pas d'innovation qui ne soit un repompage du concurrent direct.
          • C# a largement pris ses distances en terme de similitudes depuis l'inclusion de l'inférence, des lambda et LINQ : le langage devient fonctionnel.
        • [^] # Re: L'eternelle question

          Posté par  . Évalué à -4.

          JSR XXX : si tu n'a pas ton dictionnaire des JSR tu comprends rien.

          Allez, je te met dans la confidence. C'est a cause de bob. Il est con bob! Il a lance l'idee comme ca, a une des premieres editions de Java One, ya un con de journaliste qui y a cru et la sauce a prit. En vrai ca veut rien dire et c'est juste un code pour se reconnaitre entre nous.
          Les JSR pair c'est pour ceux qui ont compris la vanne, les impairs c'est les autres (generalement, ils portent des costards eux).

          pendant que l'autre propose des toolkits d'IHM sexy et propose différents niveau de compatibilité avec l'existant (natif), Java tente péniblement de sortir un JavaFX et propose JNI pour la compatibilité (sic).

          Et AWT alors? Non mais!

          pas d'innovation qui ne soit un repompage du concurrent direct.

          Certes, mais vu la cible, c'est pas un mal. Des closures dans un projet entreprise ecrit a moitie par un presta ukrainien alcoolique et un autre presta indien qui parle pas vraiment anglais mais qui trouve que c'est vachement mieux de taper au clavier que de vendre des grigris au touriste, perso ca me fait peur.
          Je prefere de tres tres loin limiter le langage, ca reste simple, c'est facile a relire (meme quand les commentaires sont en sanskrit sud oriental) et de toutes facons, ces features sexy sont loin d'etre primordiales dans la plupart des projets ou Java est un bon candidat.
          Apres c'est sur que cote client, je fuit, mais beaucoup ne se rendent pas compte que ce reproche fait a Java est en fait en partie responsable de son succes.

          If you can find a host for me that has a friendly parrot, I will be very very glad. If you can find someone who has a friendly parrot I can visit with, that will be nice too.

        • [^] # Re: L'eternelle question

          Posté par  . Évalué à 3.

          Je suis pas d'accord sur tout. Les JSR c'est génial, si je ne me trompe pas c'est plus ou moins équivalent aux PEP de python. C'est une volonté de standardisation et de définitions précise de normes.

          Par contre je suis d'accord pour le nivellement par le bas. .Net se fout plus ou moins de la compatibilité (tant que ça marche sous Windows).

          En critique à Java, je pense que Java n'a pas était pensé comme une plateforme à la base et Scala et groovy n'ont pas le même support que Java.

          Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # Mono et ses petits problemes...

    Posté par  (site web personnel) . Évalué à 3.

    Je viens de passer hier soir a bidouiller un peu Mono sous Windows et il y a pas mal de trucs qui me déplaisent...

    • Ils utilisent encore les autotools pour compiler !
    • L'organisation du repository fait que pour compiler un petit composant (dans mon cas XSP, un petit serveur web) et non l’intégralité de Mono, il faut bidouiller les scripts
    • MonoDevelop et autres applications utilisent Gtk+ et sous Windows c'est vraiment horrible : thème qui s’intègre mal et surtout la boite de dialogue pour les fichiers anti-ergonomique
    • Le package Mono pour Windows dans la page de téléchargement contient tout, vraiment tout ! Gtk, XulRunner, IKVM... plus de modularité n'aurait pas fait de mal
    • ASP.NET MVC 3 sous Windows est censé être corrigé dans la 2.10.1, en fait non :/
  • # quel intérêt ?

    Posté par  . Évalué à 1.

    Zut, j'ai loupé le sujet!
    J'apporte quand même mon expérience en tant que dev Android...
    Quand on voit que l'on doit faire appel à une classe JAVA pour lancer la Map ... https://github.com/mono/monodroid-samples/blob/master/GoogleMaps/Activity1.cs

    => Les API ne seront jamais complètes ni à jour. Elles seront buggées, non performantes, instables.

    Si on prend ce code là : https://github.com/conceptdev/RestaurantGuide/blob/master/RestGuide_Android/Activities/MainListAdapter.cs

    Franchement vu les différences minimes qu'il y a, à coder en JAVA, je comprends vraiment pas l'intérêt (A part pour Novell, qui veut vendre son produit)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.