Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Le framework Mono 3.0 propose désormais le développement asynchrone

Un alignement sur l'environnement .NET 4.5

Le framework Mono 3.0 propose désormais le développement asynchrone

Le 23 octobre 2012 à 08h31

Le framework Mono est une implémentation libre de l’environnement .NET de Microsoft. Miguel de Icaza, son principal développeur, vient d’annoncer la disponibilité de la version 3.0.

mono

Un alignement important avec .NET 4.5

Mono 3.0 est tout d’abord aligné avec la dernière révision de .NET, à savoir la mouture 4.5 fournie notamment avec Windows 8. Cela lui permet de récupérer la nouveauté la plus importante de .NET,  le développement asynchrone. Utilité ? Il permet par exemple à une application de différer une réponse attendue pour attendre avant la fin d'un calcul particulier. Ladite application peut donc continuer à effectuer d’autres actions pendant ce temps. Le compilateur de Mono utilise d’ailleurs par défaut le profil .NET 4.5 Async API, bien que les autres restent disponibles.

 

À propos, le compilateur C# est maintenant unifié pour l’ensemble des profils. En outre, et bien qu’il soit lui-même 32 bits, il permet maintenant de compiler des applications 64 bits pour OS X. Sur le système d’Apple, les développeurs pourront se servir également du langage fonctionnel F# en version 3.0, tandis que les applications iOS pourront enfin utiliser les API de chiffrement du système pour le stockage sécurisé des données.

 

Mono 3.0 intègre également la pile open source de Microsoft pour le développement web. Cela inclut :

  • ASP.NET MVC 4
  • ASP.NET WebPages
  • Entity Framework
  • Razor
  • System.Json

Ce dernier remplace officiellement la propre implémentation de Mono présente dans les versions précédentes de l’environnement.

Un garbage collector largement amélioré

De nombreuses améliorations ont en outre été portées au ramasse-miettes (garbage collector) SGen. Rappelons tout d’abord qu’un ramasse-miettes sert à collecter les zones de mémoire qui ne sont plus utilisées par les applications afin de les libérer. Il s’agit donc d’un composant essentiel dans l’environnement .NET et d’autres.

 

Avec Mono 3.0, plusieurs ajouts importants font leur apparition :

  • SGen peut distribuer ses tâches sur les cœurs supplémentaires du processeur quand il y a en a, ce qui peut mener à une hausse importante des performances
  • Une amélioration du support des plateformes déjà prises en charge, avec par exemple sous OS X l’utilisation des API kernel Mach pour accélérer certaines opérations
  • Un portage vers les plateformes Windows 32 bits et MIPS

Miguel de Icaza évoque aussi d'autres améliorations générales. Parmi les grands chantiers initiés dans Mono 3.0, on notera cependant que les développements futurs devraient être accélérés. Puisque l’environnement est basé sur .NET, il existe toujours en effet un décalage avec la « source ». Les nouveautés devraient en théorie prendre moins de temps à implémenter.

 

Mono 3.0 est toujours proposé pour Windows, OS X, les distributions Linux ainsi que Solaris. Attention cependant : la nouvelle mouture n’est pour l’instant disponible que sous la forme d’une archive de 40 Mo contenant les sources. Les environnements précompilés en sont toujours à la mouture 2.10 et seule une version OS X bêta de Mono 3.0 est accessible. Ceux qui ne sont pas intéressés par les sources devront donc attendre encore un peu.

 

Pour découvrir d'avantage les nouveautés de Mono 3.0, on consultera les notes complètes de version depuis le site officiel.

Commentaires (47)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

Dans la famille usine à gaz méga-brain fuckage… on a déjà java, merci on souffre suffisamment.

votre avatar







rFlex a écrit :



Je développe une application sur MonoTouch au boulot (Mono implémenté sur iPhone) et j’aime beaucoup. Les applications sont très rapide, et je trouve ça bien plus agréable à dev que l’Objective C.







MonoTouch… j’ai essayé de m’y mettre pour développer sur iPhone, en pensant pouvoir réutiliser mes compétences en C#. Mais aucune doc, et il faut quand même avoir des notions du framework sous-jacent. La loose. <img data-src=" /> C’est toujours le point faible des projets libres / open-source, à croire qu’ils ne sont utilisés que par leurs développeurs.



En tout cas je suis bien content d’avoir Mono pour faire exécuter quelques programmes en ligne de commandes que je développe et que je compile avec VS. C’est beaucoup plus rapide que de faire ça à la façon homme des cavernes en C avec vim.


votre avatar



En tout cas je suis bien content d’avoir Mono pour faire exécuter quelques programmes en ligne de commandes que je développe et que je compile avec VS. C’est beaucoup plus rapide que de faire ça à la façon homme des cavernes en C avec vim.



Si c’est un IDE que tu cherches, il y en a un paquet sous Linux. Rien ne t’oblige à faire “l’homme des cavernes”…

votre avatar







Vagdish a écrit :



Si c’est un IDE que tu cherches, il y en a un paquet sous Linux. Rien ne t’oblige à faire “l’homme des cavernes”…







Ya vim comme IDE justement et au moins c’est pas une usine à gaz comme le reste


votre avatar

Modo Alert:

Risque de fight pro/anti vim <img data-src=" />

votre avatar







levhieu a écrit :



Modo Alert:

Risque de fight pro/anti vim <img data-src=" />





surtout quand on sait que nano est bien meilleur <img data-src=" />


votre avatar







ff9098 a écrit :



Pas grand chose donc





Pas grand chose par rapport à quoi?







dfiad77pro a écrit :



Tant qu’il seront pas foutu de porter WPF, je ne serai pas intéressé ( je conçois que c’est assez hard de faire un WPF portable )





Tourne le début de ta phrase autrement du coup…


votre avatar







ff9098 a écrit :



Mono. Cites moi de projets l’utilisant ?





Unity3D, un moteur de jeux 3D qui s’est vendu a des dizaines de milliers d’exemplaires, fonctionnant sur des smartphones aussi bien que sur des consoles, utilise Mono pour son moteur de script. C’est l’un des plus gros client de Mono a qui il reverse d’ailleurs de belles royalties sur le CA.







brazomyna a écrit :



L’implémentation de l’asynchrone à la mode .net est pour moi au contraire une belle façon de brouiller les pistes à la relecture du code et donc de complexifier la relecture, le dénicheage de bugs et plus gloabelemnt la compréhension du code déjà écrit.





Un code écrit en async C# est bien plus lisible que le même code (a fonctionnalité équivalente) écrit en n’utilisant pas les keywords async/await, car vous devez gérer vous même une machine a état avec les exceptions, la sauvegardes de toutes les variables locales a chaque branchement d’async…etc. Async est justement la pour simplifier grandement la création de code asynchrone (un exemple:http://msmvps.com/blogs/jon_skeet/archive/2011/05/29/eduasync-part-8-generated-c…


votre avatar







unixorn a écrit :



En tout cas je suis bien content d’avoir Mono pour faire exécuter quelques programmes en ligne de commandes que je développe et que je compile avec VS. C’est beaucoup plus rapide que de faire ça à la façon homme des cavernes en C avec vim.







Y’a pas que le C, c’était pas possible d’utiliser Python (ou Ruby ou meme Java) ?


votre avatar

Ce genre d’amélioration dans le code sont appréciables à utiliser mais le problème c’est que chacun les proposent un peu à leur sauce, du coup, utiliser massivement ces astuces permettant une meilleure lecture enferme le développeur dans sa techno.



C’est vraiment flagrant dans les langages où l’introspection est aisée : on peut créer des comportements via des mots clé ou des annotations de toutes sortes qui vont agir profondément en plus du code de telle sorte qu’il devient difficile d’en suivre la logique sans être un expert ou un vieux de la vieille qui a tout mis en place.



Selon moi, ce genre d’améliorations relèvent du genre de bidouilles simplificatrices que certains ont cru apporter à coup de ‘goto’.

votre avatar







batoche a écrit :



Ce genre d’amélioration dans le code sont appréciables à utiliser mais le problème c’est que chacun les proposent un peu à leur sauce, du coup, utiliser massivement ces astuces permettant une meilleure lecture enferme le développeur dans sa techno.



C’est vraiment flagrant dans les langages où l’introspection est aisée : on peut créer des comportements via des mots clé ou des annotations de toutes sortes qui vont agir profondément en plus du code de telle sorte qu’il devient difficile d’en suivre la logique sans être un expert ou un vieux de la vieille qui a tout mis en place.



Selon moi, ce genre d’améliorations relèvent du genre de bidouilles simplificatrices que certains ont cru apporter à coup de ‘goto’.







Faute de les avoir essayées, je ne sais pas si ces fonctionnalités sont bonnes ou non, mais comparer ça à la bidouille du goto, ça me parait abusé.



On a à faire là à de nouvelles abstractions (ou du moins de nouveaux mots clés pour les mettre en oeuvre), alors que goto, c’est le contraire d’une abstraction : c’est la transposition brute des instructions de branchement des assembleurs. Et ce sont justement des abstractions comme les boucles et les fonctions qui ont permis de s’en passer.



Bref, on a d’un côté une nouvelle solution (bonne ou pas, je ne sais pas) à un problème existant, et de l’autre le péché originelle de la programmation. Rien de comparable.


votre avatar







tanguy_k a écrit :



Y’a pas que le C, c’était pas possible d’utiliser Python (ou Ruby ou meme Java) ?







Non. Parce que je ne connais pas Python et que Java est un language de *, surtout comparé à C#.

(remarque, une partie du projet est en C parce que c’est adapté pour ce cas là)


votre avatar







liukahr a écrit :



J’ai googlé 2 minutes, c’est pas “juste” le fait de te cacher un IAsyncResult derrière deux nouveaux mots clé ?







Non, c’est beaucoup plus compliqué que ça… en fait c’est une réécriture du code de la méthode sous forme d’une machine d’états, un peu comme ce qui est fait pour les blocs itérateurs. Si ça t’intéresse tu peux jeter un coup d’oeil à cette série d’articles (attention c’est assez ardu…)


votre avatar







Arona a écrit :



Question peut-être bête:

Cela permettra - t-il une meilleure implémentation des applis en .NET sous Linux?





Non et je pense même que cela va empirer : sur les quatre API pour l’UI, Mono support WinForms (l’ancêtre sur le déclin) et Silverlight (le plugin web sur le déclin) mais pas WPF (l’API de référence pour le desktop) ni son successeur à partir de W8.



Malheureusement tout cela demanderait autrement plus de boulot que la mise à niveau du langage lui-même, la partie la plus rapide. Aujourd’hui Mono se concentre sur les serveurs, les plateformes mobiles dépourvues de dotnet et comme plateforme intégrée (Unity par ex). Il n’y en revanche aucune ambition sur le client desktop.







batoche a écrit :



C’est vraiment flagrant dans les langages où l’introspection est aisée : on peut créer des comportements via des mots clé ou des annotations de toutes sortes qui vont agir profondément en plus du code de telle sorte qu’il devient difficile d’en suivre la logique sans être un expert ou un vieux de la vieille qui a tout mis en place.





Attention, il n’est pas du tout question de méta-programmation ici ou de modification du code à la volée, ton argument tombe à plat. Et puis, qu’est-ce qui est le plus compliqué ? Comprendre l’utilisation de primitives concurrentes ou écrire un code massivement parallèle en se passant de celles-ci ? C’est c’est bien vers le massivement parallèle que se dirige dotnet depuis quelques années avec diverses API, essentiellement bâties sur les tasks.


votre avatar







batoche a écrit :



Selon moi, ce genre d’améliorations relèvent du genre de bidouilles simplificatrices que certains ont cru apporter à coup de ‘goto’.





J’avais oublié celle-ci…

Goto n’a jamais été introduit comme “simplification”, goto est ce qui apparu avant les “while”, “for” et compagnie. C’est tout simplement la transposition au niveau du langage de l’instruction de saut dans le CPU, du pur bas-niveau donc. Et il est tombé en disgrâce lorsque les boucles de plus haut niveau se sont répandues.


votre avatar

La v3.0 est sorti, ok.

Mais pourquoi sur la page download, seul une version BETA OSX est disponible ? Trop fatigué après avoir dev pour mettre à jour le site ?

votre avatar







le podoclaste a écrit :



Faute de les avoir essayées, je ne sais pas si ces fonctionnalités sont bonnes ou non, mais comparer ça à la bidouille du goto, ça me parait abusé.



On a à faire là à de nouvelles abstractions (ou du moins de nouveaux mots clés pour les mettre en oeuvre), alors que goto, c’est le contraire d’une abstraction : c’est la transposition brute des instructions de branchement des assembleurs. Et ce sont justement des abstractions comme les boucles et les fonctions qui ont permis de s’en passer.



Bref, on a d’un côté une nouvelle solution (bonne ou pas, je ne sais pas) à un problème existant, et de l’autre le péché originelle de la programmation. Rien de comparable.





Oui bon, la comparaison avec le goto n’est peut être pas très heureuse. J’aurais du prendre comme exemple les expression lambda qui sont typiquement .net, sont parfaitement transposable en un code pas tellement plus compliqué, mais bien plus lisibles car usuel (et compréhensible par quelqu’un ayant plutôt de l’xp en java ou c++).



Un autre exemple, les implementations anonymes d’interface inline en java (avec des raccourcis de dingos pour atteindre des propriétées protégées de l’instance d’une classe dans laquelle cette classe anonyme est déclarée (d’ailleurs, si quelqu’un voit de quoi je parle, j’aimerais savoir si ce genre de truc a un nom)).


votre avatar







batoche a écrit :



J’aurais dû prendre comme exemple les expression lambda qui sont typiquement .net





Tu sais que les expressions lambda arrivent dans Java 8 ? ;-)


votre avatar







batoche a écrit :



Oui bon, la comparaison avec le goto n’est peut être pas très heureuse. J’aurais du prendre comme exemple les expression lambda qui sont typiquement .net, sont parfaitement transposable en un code pas tellement plus compliqué, mais bien plus lisibles car usuel (et compréhensible par quelqu’un ayant plutôt de l’xp en java ou c++).



Un autre exemple, les implementations anonymes d’interface inline en java (avec des raccourcis de dingos pour atteindre des propriétées protégées de l’instance d’une classe dans laquelle cette classe anonyme est déclarée (d’ailleurs, si quelqu’un voit de quoi je parle, j’aimerais savoir si ce genre de truc a un nom)).







Les lambda expressions ne sont pas une exclusivité de .NET. Elle proviennent de Lisp, qui est très antérieur à .NET.



Pour leur lisibillité, ça dépend de l’usage qu’on en fait. J’ai un collègue qui en abuse, et c’est pénible (surtout à déboguer, car c’est impossible de les modifier en cours de débogage ou même de les espionner).



Mais en paramètre d’une fonction Linq, c’est top : lisible et économe en ligne de code. Sans ça, soit tu dois écrire une boucle qui traite chaque élément de ta liste, soit tu dois déclarer une méthode pour chaque usage.



Autre avantage, ça compile vite, et ça nous sert bien pour un moteur de décision maison qui extrait des expressions de fichiers de configuration.


votre avatar







Olipla a écrit :



Tu sais que les expressions lambda arrivent dans Java 8 ? ;-)





Et elles étaient déjà dans beaucoup de langages multi-paradigmes et viennent de débarquer dans le C++. ^^

Les lambdas à la conquête du Monde. Ce qui est une bonne chose d’ailleurs, c’est tellement commode ces petites bêtes, et la syntaxe utilisée par dotnet est tellement bien choisie.


votre avatar

Beeuark !



Le fait que ça vienne de Lisp ne m’étonne pas, finalement. Ça explique pourquoi la syntaxe est tellement décalée par rapport au reste du langage.



Je cite wikipedia



Le langage LISP dispose d’une syntaxe très simple et élégante, utilisant un minimum de concepts. Cette économie de concepts mène Gregory Chaitin à qualifier cette syntaxe de « joyau de splendeur mathématique et de beauté intellectuelle austère »4.





Bah voilà, lorsqu’on me promet une syntaxe issue d’un joyau de splendeur mathématique et de beauté intellectuelle austère, je me prédit que la lecture du code va être une partie de plaisir.



Surtout lorsqu’elle est mélangée à une autre syntaxe, beaucoup plus verbeuse et terre à terre, et probablement pas élégante mathématiquement pour deux sous.

votre avatar







unixorn a écrit :



Java est un language de *, surtout comparé à C#.







MEGA LOL TROLL

Java serait de la merde et C# génial ? j’ai jamais vu deux langages aussi proche ! même paradigme, même syntaxe, même principes…



C’est comme dire que ma Renault Clio 2012 est mieux que ta Peugeot 207 2010. C’est bonnet blanc et blanc bonnet.


votre avatar







batoche a écrit :



Beeuark !



Le fait que ça vienne de Lisp ne m’étonne pas, finalement. Ça explique pourquoi la syntaxe est tellement décalée par rapport au reste du langage.





Résiste tant que tu le veux mais tu finiras comme les autres: assimilé.

Toute résistance est futile.

<img data-src=" />


votre avatar







HarmattanBlow a écrit :



Résiste tant que tu le veux mais tu finiras comme les autres: assimilé.

Toute résistance est futile.

<img data-src=" />





Non mais le lisp en sois c’est pas trop mauvais, c’est plus la tournure d’esprits que ça donne au gens qui l’utilise qui est mauvais.


votre avatar

Ça intéresse encore des gens ce truc ?

votre avatar

Question peut-être bête:

Cela permettra - t-il une meilleure implémentation des applis en .NET sous Linux?

votre avatar







ff9098 a écrit :



Ça intéresse encore des gens ce truc ?



Tu dis ça pour rire non ?


votre avatar

Chapeau <img data-src=" />



Ils font vraiment du bon boulot sur ce projet, ils arrivent toujours à suivre les versions de .NET avec très peu de retard. Et sur cette version, c’était clairement pas évident, l’implémentation de async/await dans le compilateur est loin d’être triviale

votre avatar







Cacao a écrit :



Tu dis ça pour rire non ?







Vu que c’est un gros bide non


votre avatar







tom103 a écrit :



l’implémentation de async/await dans le compilateur est loin d’être triviale





J’ai googlé 2 minutes, c’est pas “juste” le fait de te cacher un IAsyncResult derrière deux nouveaux mots clé ?

Si oui, ça ressemble à une simple tâche de preprocessing.

(vraie question, j’ai pratiqué le C# mais pas tant que ça)


votre avatar

Donc Mono fonctionne sous Windows XP et Vista, mais .NET 4.5 non ? où est la logique là dedans ?


votre avatar







liukahr a écrit :



J’ai googlé 2 minutes, c’est pas “juste” le fait de te cacher un IAsyncResult derrière deux nouveaux mots clé ?

Si oui, ça ressemble à une simple tâche de preprocessing.

(vraie question, j’ai pratiqué le C# mais pas tant que ça)







Plus exactement ça permet d’écrire du code asynchrone de manière séquentielle, comme on écrirait un code synchrone.



Par exemple, quand on avait à écrire quelque chose du genre :



void Mafonction()

{

GetResultAsync(callback);

}



void callback(string result)

{

Console.WriteLine(result);

}



On peut désormais écrire :



async void Mafonction()

{

var result = await GetResultAsync();

Console.WriteLine(result);

}



(vite fait, c’est juste pour montrer le concept)



Au final, quand on a plusieurs appels asynchrones chainés, ça simplifie énormément l’écriture et la compréhension du code.


votre avatar

J’ai pas compris. C’est




  • Avec Mono, on peut utiliser le F# que sur OSX,

  • ou Avec cette version de Mono, on peut enfin utiliser F# sur OSX comme ailleurs



    <img data-src=" />

votre avatar







ff9098 a écrit :



Vu que c’est un gros bide non







source ? qu’est-ce qui te permets d’affirmer que c’est un gros bide ?

Tu parles de mono spécifiquement, ou de .Net globalement ou dans ses portages hors Windows ?


votre avatar







baldodo a écrit :



source ? qu’est-ce qui te permets d’affirmer que c’est un gros bide ?

Tu parles de mono spécifiquement, ou de .Net globalement ou dans ses portages hors Windows ?







Mono.

Cites moi de projets l’utilisant ?


votre avatar









ff9098 a écrit :



Ça intéresse encore des gens ce truc ?







Tu dois te dire la meme chose pour linux etant donné qu’avoir le choix semble te poser problème…


votre avatar







ff9098 a écrit :



Mono.

Cites moi de projets l’utilisant ?





http://www.mono-project.com/Software


votre avatar







azerothl a écrit :



Tu dois te dire la meme chose pour linux etant donné qu’avoir le choix semble te poser problème…







C’est dangereux pour Linux ce truc


votre avatar

Cool <img data-src=" />

votre avatar







guildem a écrit :



http://www.mono-project.com/Software







Pas grand chose donc


votre avatar

Tant qu’il seront pas foutu de porter WPF, je ne serai pas intéressé ( je conçois que c’est assez hard de faire un WPF portable )

votre avatar

Il faut arrêter de dire que Mono suit (de près ou de loin) les version de .Net.

Ils n’en sont même pas à une implémentation complète de .Net 1.0 (sortie en quoi, 2002 ? 2003 ?).



Ils font le tri dans ce qui les intéresse et l’implémente. Tout le reste, ils s’en balance. En gros, 80% part à la poubelle à chaque nouvelle version, et 20% est implémenté (avec un retard comprit entre 6 mois et 2 ans… tu m’étonnes qu’ils veulent accélérer !). Ceci rend Mono quasi inutilisable en entreprise, ou on doit pouvoir répondre à tous les besoins. Avec .Net de MS c’est pas toujours super évident (y a toujours des trucs qu’ils n’ont pas prévu et où il faut un peu tordre la plateforme), avec Mono c’est un gageur…



Donc oui, des projets utilise Mono, mais non, ça n’est pas rentable (en tout cas dès qu’on sort des clous décidé par Miguel, ce qui arrive rapidement quand on a de vrai clients en face qui ont toujours au moins un besoin tordu dans leur outil), donc seule une volonté inébranlable de faire du 100% libre justifie l’utilisation de Mono, et la frustration que cela va engendrer (ou chez le client qui n’aura pas sa fonctionnalité tordue, ou chez l’équipe de développement qui va se faire allumé pour avoir mit 3 mois à implémenter une petite fonctionnalité de rien du tout, ou qui aura des problèmes de perfs qui nécessitera une upgrade du parc de machines de l’entreprise…).



Bref, Mono c’est cool pour un projet d’étude, mais dès le premier stage en entreprise, tu comprends ta douleur :)

votre avatar

async await est une super fonctionnalité de .NET 4.5 Dire Pour moi, ca en fait un des meilleurs langages pour faire des applications web non bloquantes coté serveur, devant node.js, parce que les promises, ben c’est gentil mais:




  1. c’est verbeux

  2. ca ne gêre pas du tout la jointure.



    avec MVC4/WebAPI, tu peux faire des Actions asynchrones, SignalR est aussi conçu pour être entièrement non bloquant:



    public async Task GetTruc(int id)

    {

    return await repository.Get(id);

    }

    ne bloquera pas un thread de requête pendant l’appel à la Base de donnée distante. Et vu que dans une appli normale, les threads passent quasiment tout leur temps à attendre que des requêtes IO style base de donnée, cela decuple les capacités du serveur web.



    Coté client, ca simplifie fortement l’ecriture de logiques complexes qui ne font pas bloquer l’interface utilisateur. (genre des requêtes web parallelles suivies d’un travail intensif sur un thread de fond )



    Pour ce qui est de la complexité d’implementation, il faut gerer des choses comme celle-ci:



    while(true)

    {

    await Task.Delay(1000);

    }

    Il faut bien comprendre que dans le cas ci-dessus, le thread executant le programme est bien relaché pendant l’attente de 1000ms. Il n’est pas bloqué, contrairement à un thread.Sleep(1000);

votre avatar

En fait, Mono est fait pour:





  1. Faire des appli web .NET sur Apache

  2. Faire du monogame portable Windows/Linux/Android/IPhone/NaCl

  3. Faire du Unity (eh oui, le moteur de script .NET d’Unity marche en Mono)

  4. Developper pour IPhone/Android sans avoir besoin de faire l’ObjectiveC/Java (en plus d’après eux, Mono sur Android est plus rapide que Davlik)

votre avatar







Laere a écrit :



async await est une super fonctionnalité de .NET 4.5 Dire Pour moi, ca en fait un des meilleurs langages pour faire des applications web non bloquantes coté serveur, devant node.js, parce que les promises, ben c’est gentil mais





L’implémentation de l’asynchrone à la mode .net est pour moi au contraire une belle façon de brouiller les pistes à la relecture du code et donc de complexifier la relecture, le dénicheage de bugs et plus gloabelemnt la compréhension du code déjà écrit.



Donc si c’est pour gagner 20 caractères mais perdre 2 jours pour lever un bug qui n’aurait pas été écrit dès le départ avec une syntaxe plus ‘verbeuse’, ça ne rend pas forcément service.



Après, chacun ses goûts, mais pour moi l’approche à la .net devient dangereuse.



votre avatar







brazomyna a écrit :



L’implémentation de l’asynchrone à la mode .net est pour moi au contraire une belle façon de brouiller les pistes à la relecture du code et donc de complexifier la relecture, le dénicheage de bugs et plus gloabelemnt la compréhension du code déjà écrit.



Donc si c’est pour gagner 20 caractères mais perdre 2 jours pour lever un bug qui n’aurait pas été écrit dès le départ avec une syntaxe plus ‘verbeuse’, ça ne rend pas forcément service.



Après, chacun ses goûts, mais pour moi l’approche à la .net devient dangereuse.





Pourquoi? Cite-moi concrètement un exemple, par rapport à une promise?


votre avatar

Je développe une application sur MonoTouch au boulot (Mono implémenté sur iPhone) et j’aime beaucoup. Les applications sont très rapide, et je trouve ça bien plus agréable à dev que l’Objective C.

Le framework Mono 3.0 propose désormais le développement asynchrone

  • Un alignement important avec .NET 4.5

Fermer