Jb Evain a écrit 120 commentaires

Et voilà ! Maintenant nous savons qui est Clara !

D'ailleurs "bloat language", ça ne veut rien dire. "Bloated language", par contre, ça a du sens.

Pas vraiment. La popularité et l'intérêt technique ne sont pas antagonique.

Il suffit de regarder la nouvelle vague de langages sur la JVM comme Scala, Clojure et Groovy, ou sur la CLI comme F# ou Boo pour s’apercevoir que l'on peut apporter des concepts avancés à une masse importante de développeurs.

C'est le même genre de débat un peu stérile que «Est-ce que Java est orienté objet même si le langage et la VM ne considèrent pas les primitives comme des objets à part entière ?».

JavaScript ne tire clairement pas pleinement profit de son héritage (ahah) côté Self. Pas d'héritage dynamique des prototypes, des structures de contrôles non dynamiques, etc. D'un autre côté il assume bien son héritage et ses compromis vers Java pour la syntaxe principalement.

Après c'est super de se palucher sur la pureté de LISAAC comparé aux affreux compromis de JavaScript, mais il faut pondérer ça avec le nombre de programmeurs de chaque côté. Comme quoi, le bien, le mieux, tout ça...

Le plus hillarant

Bonne chance pour demain.

Je suis content que tu sois d'accord avec toi même. Je me contentais de corriger la phrase:

«Ainsi, il ne sera désormais plus question de parler d'OpenSolaris, mais de OS Oracle Solaris, qui ne sera pas gratuit, mais soumis à 90jours d'essai sans frais, après quoi un contrat de support avec Oracle sera obligatoire pour continuer à l'utiliser.»

Tu confonds Sun Solaris et OpenSolaris. C'est Sun Solaris qui change de nom et dont la licence change et qui sera soumis à 90 jours d'essai.

OpenSolaris lui reste sous CDDL. Mais pas sous de bons augures, c'est sûr.

Android, au contraire de l'OS de l'iPhone, autorise la création de pages où l'on peut écrire et que l'on peut exécuter, donc Mono et son JIT ARM marchent normalement dessus.

Ça marche normalement, mais pour l'instant c'est utile seulement aux personnes qui se servent directement de Mono dans leur propre application, genre Unity3D.

Par contre l'équipe qui bosse sur MonoTouch est en train de bosser sur un produit qui permet d'écrire des applications Android «natives» à partir de C#/Mono.

Non c'est faux. Le code C# est compilé en IL, comme pour du .net traditionnel, mais ce code IL est ensuite compilé directement en code ARM natif, pas en Objective-C.

Mais t'es incroyable toi.

On est bien d'accord, vous avez un joli compilateur, pour un langage intéressant sur le fond. Ok ? Bon.

Et maintenant ?

Moi je dis juste, «je pense que ça ne risque pas de percer tel quel».

Et te voir courir après chaque critique en disant «si si si c'est génial», ça aide vraiment pas :)

On s'habitue à tout. C'est moche mais [..] cela permet d'avoir zéro surprise

Mais va dire ça à ta copine quoi.

Moi perso, vu le temps que je passe devant des lignes de code, je préfère me trouver devant un truc que je trouve élégant aussi bien dans le concept que dans la forme.

Et pour en revenir à la question de la pureté, si des langages comme Java, JavaScript ou C# sont populaires et acceptés, c'est pas seulement parce qu'il y a des énormes boites qui poussent derrière.

C'est aussi parce qu'ils l'ont sacrifié leur pureté pour pouvoir toucher le plus grand nombre de développeurs. Mais c'est une histoire de compromis, et quand c'est fait intelligemment, c'est bien, parce que ça permet d'exposer des concepts à des gens qui n'y auraient pas forcément été exposé forcément.

Je prends deux exemples que je connais bien, que je trouve intelligents et pourtant qui sont opposés, tout en ayant une chance de toucher du monde :

* C#, qui est parti d'un langage complètement Java-like, et qui maintenant a des possibilités de meta-programmation (avec les expression tree) et des possibilités fonctionnelles (delegates, extension methods et LINQ). Donc on part d'un langage bateau a quelque chose de finalement assez couillu.
* F#, en gros OCaml pour .net, mais qui a été adapté pour pouvoir faire de l'impératif. Et donc on a un excellent langage fonctionnel, qui a accès à tout un framework connu par plein de gens, qui vont avoir des facilités pour s'y mettre.

Alors que Lisaac débarque comme une fleur en ne ressemblant à rien de vraiment connu et en criant «ON DÉBOITE DES CACAHOUÈTES». Je dis pas, y a des excellentes idées dans Lisaac. Mais avant que ça se popularise...

Après la question de la lisibilité c'est très personnel et ça dépend de l'expérience et du temps passé avec les langages.

Donc non je n'aime pas lire du smalltalk non plus (encore une fois, outre toutes ses qualités), mais je suis assez habitué à la syntaxe à la OCaml parce que je fais pas mal de F#.

Et pour en revenir à Lisaac, j'ai horreur de ses Section, et j'ai horreur que les types soit TOUT EN MAJUSCULE.

Sinon tu peux aussi réfléchir un peu par toi même plutôt que de te braquer parce qu'on critique ton truc.

C'est évident que des langages comme Lisaac, Self ou io sont plus jusqu'au-boutiste que JavaScript. Ne serait-ce que parce que ce dernier ne prend pas avantage de son mécanisme de prototype pour les structures de contrôle.

Mais du coup il a le bon goût de rester facilement abordable et agréable à l'œil pour la masse de développeurs qui ont programmé dans un langage de la famille du C, contrairement à Lisaac qui me donne envie de me rentrer des fourchettes dans les yeux, outre ses qualités intrinsèques.

Par contre, le type system de JavaScript est basé sur les prototypes, que ça te défrise ou pas.

Oui bien sûr, par exemple, la réutilisation de l'infrastructure de génération de code intermédiaire à la volée pour simplifier les appels vers les bibliothèques non managées (P/Invoke) :

http://www.advogato.org/person/lupus/diary/27.html

De rien.

Non, il dit juste qu'il a la possibilité de piloter Tomboy avec le plugin Gnome Do qui va bien. Et que ça lui plaît.

Tu confonds fondation CodePlex [0] et le service d'hébergement CodePlex [1]. Ce sont deux choses différentes, malgré qu'ils aient réutilisé le nom, ce qui est dommage.

[0] http://www.codeplex.org
[1] http://www.codeplex.com

Pour la première fois en France, un module d'enseignement sur des technologies issues de logiciels libres a été intégré dans un programme universitaire.

Ce qu'il faut pas lire. On avait déjà de la chance que Mozilla sauve le web à lui tout seul. Maintenant Mozilla sauve nos universités. Ouf !

Oui, MonoTouch est un logiciel propriétaire et closed-source, se basant sur Mono, qui est lui complètement libre et open-source.

On peut séparer logiquement MonoTouch en deux parties. Tout d'abord le runtime, très léger, qui est écrit en Objective-C, et qui utilise Mono. Il fait office de glue entre le runtime objective-c et le runtime Mono. Après il y a les bibliothèques de classes en C#, qui wrappent les API de l'iPhone. Concrètement cela permet d'écrire des applications pour iPhone en C#.

Techniquement, MonoTouch compile en code natif l'application en utilisant le compilateur AOT de Mono. Le runtime Mono à l'exécution est toujours nécessaire pour le garbage collector, et toute la partie méta-données, mais le JIT n'est pas utilisé (et n'est même pas incorporé). Du coup pour les performances il y a une légère pénalité au démarrage de l'application, le temps de chauffer la VM, mais ensuite c'est du code natif qui s'exécute, et comme il est pré-compilé et pas jitté, les performances sont sensiblement semblables à du code natif traditionnel.

Ça fait un bout de temps que Mono est déjà utilisé comme ça, des dizaines et des dizaines de jeux disponibles sur l'AppStore utilisent Mono, quand ils sont écrit avec Unity3D, un environnement de développement de jeu. Seulement MonoTouch offre la possibilité d'écrire des applications qui utilisent les APIs de l'iPhone. Après tout, quand l'application est poussée vers Apple pour validation, elle ne contient plus que du code natif et des méta-données. Pas d'interpréteur, pas de JIT compilation, donc pas de problème. Enfin pas plus de problème qu'une autre application, après c'est Apple qui valide. Ou pas.

Donc oui, c'est commercial. Il faut dire qu'Apple interdit de lier dynamiquement des bibliothèques, de sorte que MonoTouch doit lier statiquement Mono. Ce qui fait qu'on ne peut pas appliquer la LGPL, qui est la licence du runtime Mono. Donc il faut passer par la licence propriétaire de Novell.

Personnellement, je ne trouve pas ça choquant de commercialiser un produit pour une plate-forme complètement fermée, tout en gardant Mono complètement libre et open-source. Un commentaire plus haut suggérait que c'était pas sympa pour les contributeurs de Mono, qui ont donné leur copyright à Novell. D'abord tout le monde fait ça, Sun pour MySQL / Java, Red-Hat pour JBoss, etc. C'est même un modèle plutôt familier le couple GPL/LGPL + licence propriétaire. Ensuite, pour les contributeurs de Mono, quand ils touchent au runtime, ils ont le choix de publier leur patch en signant un contributor agreement pour le copyright, ou de garder leur copyright et de publier le patch sous MIT/X11. Surtout, si ils contribuent des patchs, c'est surtout qu'ils ont un intérêt et que pour la plus part, ils utilisent Mono commercialement aussi. Donc je vois pas vraiment où est le problème.

MonoTouch est un produit de niche (pas forcément petite la niche cela dit), pour les développeurs .net expérimentés, qui souhaitent réutiliser leurs compétences et/ou du code pour faire des applications iPhone.

Pardon hein, mais rassurez moi, je suis pas tout seul à trouver ce commentaire pourtant très pertinenté à gerber ?

«Ne semble pas». Tiens donc.

* http://www.videolan.org/press/patents.html
* http://ffmpeg.org/legal.html
* http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Patent_licensi(...)

Et c'est aussi (en partie seulement, ils préfèrent aussi pousser H.264) à cause des brevets qu'Apple et Nokia ne veulent pas de Ogg. Parce qu'ils n'excluent pas que des patents trolls leurs tombent dessus.

Mais c'est vrai, j'oubliais, seul Mono pose des problèmes ;)

Je n'ai jamais dis qu'il n'y avait aucun danger. Et je salue bien bas cette initiative qui au final protège Mono.

Par contre, considérant le danger ambient due à la situation des brevets logiciels, je maintiens que je ne vois pas en quoi Mono posait plus de problèmes de d'autres logiciels de cette envergure.

Ajoutons aussi que le gros avantage de C# et de la CLI est le méchanisme de PInvoke, pour ré-utiliser du code natif existant à partir de C# directement.

Plus facile que de faire des extensions Python en C, et encore plus facile que de faire du JNI.

C'est une des raisons pour laquelle il a été si facile de faire des bindings Mono vers toute la pile native GNOME. Alors que java-gnome a été refait deux ou trois fois entre temps.

C'est rigolo. Après des années à expliquer que Mono n'était pas forcément plus en danger qu'un autre logiciel, à expliquer pourquoi c'est une solution technique viable, les gens admettent enfin leur raison du refus de Mono.

«Ça vient de Microsoft, et en utilisant Mono, on utilise du Microsoft».

Après des années à s'entendre dire, «mais non, on crache pas dessus parce que ça vient de Microsoft», l'ironie de tout ça me fait rire.

Moi je vais t'avouer un autre truc terrible, si on veut être sérieux, on confond pas langage et plate-forme. Et aussi excité qu'on soit à propos d'un langage, on évite de balancer des généralités à la con, genre «C#, c'est toujours du C», en supposant que c'est ce qu'on voulait dire, qui fait preuve d'une connaissance, disons, bien étalée.

Si on est tout agité à la vue d'une accolade, «aahhh du C, tous les mêmes je vous dis, tous les mêmes!», on peut faire marcher IronPython sur Mono, comme ça les enfants de maternelle ils pourront même faire des applications multithreadés sans être gênés par l'interpréteur.