Discussion :

[Nathanael Marchand]

Le C# c'est du C like, je dirais à ce niveau qu'ils sont passé à coté de leur objectif : Le langage de .Net c'est pas C# mais VB... et c'est beaucoup trop verbeux à mon goût.

Oh ben oui, c'est bien pour ca que toutes les nouvelles fonctionnalités sortent sur VB.Net avant de sortir sur C#.

Seul un langage comme le JS permet de faire des appli réactives et des librairies lisibles à la volée de manière performante. Voilà

Oh pinaise, j'en ai encore une crampe à ma machoire

Pour être allé au DevCamp Windows8 chez Microsoft, je peux vous dire que le message est de ne surtout pas abandonner .Net (ni C# d'ailleurs)!
Ceux qui ont fait du HTML5 pour des applis Metro c'était soit:
-Pour s'essayer à l'HTML5 et voir ce que ca donne;
-Parceque c'est une migration d'application existance en HTML5;
-Parceque c'est pour un client et qu'après le client à des ressources en HTML5 dans ses équipes et pas en XAML.

Par ailleurs, si si, il est possible de faire du JS propre, découpé, modulable, avec des patterns comme le MVC, etc.
Perso, non je ne suis pas fan du html5 sauce metro: tous les controles sont des div, je trouve qu'on s'y perd completement à la lisibilité. En xaml, un textbox c'est un textbox, un bouton est un button. En HTML5 tout est div

D'ailleurs il est à souligner que les seuls languages ou il est possible de faire des libraires de controles sont le C# et le C++. Impossible en Javascript.

[GuruuMeditation]

Pour être allé au DevCamp Windows8 chez Microsoft, je peux vous dire que le message est de ne surtout pas abandonner .Net (ni C# d'ailleurs)!

Heureux de l'apprendre. Ça devrait être un peu plus dit, je pense. Mais vu que HTML5 c'est LE truc du moment (Tout le monde en parle, mais personne n'en a jamais fait) je comprends que MS met en avant cette facette sous peine de passer pour ringard.

HTML5 à ses plus et ses moins. Comme C#. Et je pense que C# à toujours sa place et reste le langage le plus productif pour Metro. En tout cas, j'y crois

[zulad]

Là, ça mérite que tu détaille tes arguments quand même, parce que parler de mauvaise conception pour .Net, on en le fait pas sans argumentation solide.

C'est simple pourtant. A la base les langages microsoft, à moins qu'ils aient des langages propriétaires tenus secrets, ... ne sont pas extensible via le code source. Des librairies sont à développer pour l'étendre : cf la machinerie .Net.

Je prends pour exemple un langage objet plus ancien le Lisp qui lui permet de le faire.

Je passe de là à JQuery pour exemple qui constitue une avancée significative en terme de développement. La couche est logicielle, on ne parle pas de librairies ou d'add on. Tout est portable et natif ici.

J'entends par là que C# ET VB.NET sont malheureusement voués à disparaître.

La spécificétés du .Net c'est l'informatique de Gestion
Le C++ : L'ingéniérie
Le JS, et dart, ... des langages mieux "conçu" pour le Multimédia, et comme le multimédia est l'huile dans le développement, c'est normal qu'il relègue le C# et VB.net à la postérité.

Attention que je ne parle pas des librairies .Net qui elles migreront vers un plus noble langage.

[MiaowZedong]

C'est simple pourtant. A la base les langages microsoft, à moins qu'ils aient des langages propriétaires tenus secrets, ... ne sont pas extensible via le code source. Des librairies sont à développer pour l'étendre : cf la machinerie .Net.

Je prends pour exemple un langage objet plus ancien le Lisp qui lui permet de le faire.

Vraiment, tu plaisantes j'éspère?

Pour ta gouverne, le LISP est un language fonctionnel à la base. Pour programmer objet en LISP il faut utiliser une extension du language, la plus établie est je pense le CLOS (Common LISP Object System); mais le CLOS ou d'autres extensions objet ne sont pas disponibles dans de nombreux dialectes de LISP, comme Scheme ou Clojure.

De plus tu ne sembles pas bien saisir ce qu'est une librairie ou un framework, car ce sont justement des extensions du language, comparables au CLOS de LISP. Étendre monj interpréteur LISP ou rajouter des librairies pour mon environnement .Net, c'est du pareil au même. D'ailleurs, il est possible d'écrire du code LISP .Net (avec e.g. Clojure).

.Net c'est avant tout un framework d'API accessible à partir du CLR. En ce sens, je dirais que le .Net est plus important que le language utilisé, car c'est le .Net qui t'apporte tes fonctionnalités prêtes à l'emploi qui peuvent être appellées avec n'importe quel language, du moment que as un compilateur qui puisse en faire du CIL. Cependant, le C# qui est un Java-like (mieux structuré, dixit les devs C#) demeure le language de référence pour programmer pour le .Net.

Je passe de là à JQuery pour exemple qui constitue une avancée significative en terme de développement. La couche est logicielle, on ne parle pas de librairies ou d'add on. Tout est portable et natif ici.

Le JQuery est une librairie
Comme tout code JavaScript, jQuery est interpreté

Et niveau portabilité le JavaScript n'est pas une référence, à cause de la multiplicité des moteurs JavaScript (contrairement à Java ou .Net où tu connais la machine virtuelle qui va executer ton code).

[DonQuiche]

@Zulad
Je reprends d'abord quelques assertions en vrac:

• Le C# ne pourrait pas être étendu faute d'accès au code source. JS non plus puisque tu dois te conformer au standard. Certes les code source de certains navigateurs est dispo, tout comme celui de Mono pour dotnet.
• VB serait le langage de prédilection. Pas du tout, c'est C# : le plus utilisé et celui que MS bichonne le plus.
• C# serait trop proche du C et trop bas-niveau. Voici qui révèle une totale méconnaissance de ce langage. C# possède notamment à peu près tout ce qui existe dans JS et davantage (typage statique par défaut et support intégré des types dynamiques, closures, lambdas, événements en standard p/invoke, énumérables, méthodes d'extension, etc). C'est un des langages les plus riches qui soit en fonctionnalités de haut niveau.
• Par "faire du multimédia" tu désignes improprement la création d'interfaces riches.
• Il faudrait rajouter des tonnes de framework en dotnet. C'est une blague ? Aucun dév JS ne travaille plus sans JQuery (un framework) et beaucoup utilisent en plus des ExtJS & co (d'autres frameworks) puisque html n'offre pas de briques UI de base dignes de ce nom.

Maintenant, il serait impossible de faire du JQuery en C# ? Exemples de code, certains possibles en JS, d'autres non, certains dispos en standard, d'autres réclamant 5 lignes de code en amont. A l'exception du premier exemple qui n'est valable que sur des noeuds XML, le reste s'applique à n'importe quel ensemble d'objets : ils n'ont pas à définir de méthodes "First", "Where", "Recursive", "OrderBy", etc (c'est ce qu'on appelle des méthodes d'extension). En revanche une DB pourrait aussi "surcharger" ces méthodes pour offrir un code optimisé. Pour la comparaison, seul le premier exemple serait aussi aisé à écrire en JS mais ce dernier n'a pas de syntaxe assez souple pour les suivants ni de support pour les méthodes d'extension (il faudrait une indirection de plus, comme le $() de JQuery). Je précise enfin que tout ce qui suit utilise exclusivement le typage statique, preuve qu'il n'est pas aussi limitatif que tu sembles le penser et avec tous les avantages que cela implique (vérifications par le compilateur, performances, intellisense, découvrabilité des API - bref, productivité).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
// Sélectionner le premier élément <a> ayant la classe "truc" dans un doc html.
var result = root.SelectNodes("//a[@class='truc'"]).First();
// Prendre les 5 premiers éléments sélectionnés dans la hiérarchie UI descendante et les trier par leurs noms. Puis changer leur couleur de fond.
var result = node.DescendantsAndSelf().Where(x => x.IsSelected).Take(5).OrderBy(x => x.Name);
foreach(var selected in result) selected.Background = Brushes.Red;
// Sélectionner le premier enfant de type ForLoop dans le DOM d'un langage.
var result = node.Descendants().FirstAs<ForLoop>();
// Afficher le chemin "a>b>c>d" dans une hiérarchie ascendante sur un système de fichiers.
var result = node.Recursive(x= > x.Folder).Reverse().Implode(x => x.Name, ">");
// Obtenir le premier élément correspondant dans une liste, ou null sinon
var result = list.FirstOrDefault(x => x.IsSelected);

Les seuls cas où un langage dynamique comme JS est plus adapté pour l'UI sont :

• Le prototypage ou les logiciels de petite taille.
• L'inclusion de morceaux de codes très courts (typiquement une seule ligne) au sein d'un langage déclaratif pour l'UI, par exemple pour définir des bindings avec conversions de données. En html malheureusement tu ne peux inclure que des déclarations de handlers en JS. Regarde plutôt ce qui se fait du côté de Qt Quick où JS y est utilisé intelligemment mais uniquement pour une petite part de l'appli, le reste relevant du C++.

Dynamique != plus puissant != plus adapté à l'UI.

[ptah35]

@zulad,

corrigez-moi si je me trompe, mais il me semble que derrière votre discours à propos des défauts des "languages microsoft" et de la supériorité de l'ECMAScript ou de dart se cache en fait simplement l'expression de votre préférence pour les langages à typage dynamique.

Or rien dans la machine virtuelle de .NET n'empêche l'utilisation d'un langage dynamique, et il n'a pas été nécessaire de modifier ou d'étendre le MSIL pour compiler ces langage pour elle. L'ajout de la DLR a seulement permis de simplifier l'implémentation de ces compilateurs.

Cela n'a d'ailleurs rien d'étonnant, le premier compilateur LISP a été implémenté pour un IBM 704 -- un ordinateur électronique à tube et à mémoire torique -- dont le jeux d'instruction n'avait sans doute pas grand-chose à voir avec celui des x86, pourtant on retrouve LISP sur nos machines à base d'Intel. MSIL ou Bytecode sont les jeux d'instructions de machines virtuelles, mais ces machines virtuelles ne sont pas plus différente d'un microprocesseur x86 que ce dernier l'est du processeur de l'IBM 704. On retrouve d'ailleurs des compilateur LISP pour ces deux jeux d'instructions.

Ensuite, si par "machinerie de .NET" vous entendez la bibliothèque de classes, elle est essentiellement écrite en C#; en ce sens .NET permet donc d'étendre .NET.

De façon très subjective, j'ai une préférence pour les langage fortement typé mais j'apprécie la souplesse et la puissance de langage dynamique (comme beaucoup, j'ai appris la programmation avec Scheme), de là à dire que les uns sont plus "nobles" que les autres, c'est une chose que je ne ferais pas. En outre, c'est une chance C#permet d'avoir en quelque sort le meilleur des deux mondes.

[zulad]

@ptah35

Oui je préfère l'Ecmascript et de loin ce qui nécessite le moins de verbes de code pour faire la même chose.

@MiaowZedong

pour la librairie je plusoy sorry. En fait en programmation tout est librairie, mea culpa

@DonQuiche

C'est ok, je plussoy aussi.
Mais pour le jQuery en C# c'est loin d'être aussi optimal mais cependant c'est peut-être plus performant à l'exécution... Est-il possible d'avoir une syntaxe en JSON en C#, ce serais aussi une extension ??? :lil: Laissez moi rire...

Ici @MiaowZedong le C# contre Lisp (peut importe qu'il soit fonctionnel ou objet) ne permet pas de redéfinir le langage ou sa syntaxe...

Structurellement je maintiens, les langages MS sont des langages trop coincés et beaucoup moins souples que le js.

De ce point de vue, @ptah35 les langages dynamique sont de loins plus élégants. Les autres paradigmes apparaissent comme de proto-langages à cotés...

Edit : De plus, c'est dommage qu'il n'y ai pas de pointeur en .NET, j'espère que ça reviendra. Ainsi que l'héritage multiple

[tomlev]

Edit : De plus, c'est dommage qu'il n'y ai pas de pointeur en .NET, j'espère que ça reviendra. Ainsi que l'héritage multiple

Il y a des pointeurs en .NET, bien qu'on en ait rarement besoin

Quant à l'héritage multiple, pour ma part je n'ai aucun regret. Ça menait généralement à des "architectures" totalement immondes

[ptah35]

@zulad,

Je ne discute pas les goûts et les couleurs et j'apprécie aussi l'élégance de Scheme.

Cependant, vous confondez encore .NET et les langages pour lesquelles il existe un compilateur permettant de générer du code pour cette plateforme. Le MSIL, C# et VB.NET, ne supportent pas l'héritage multiple. Pour autant, il rien n'empêche d'implémenter un compilateur pour un langage qui le supporte. Est-il nécessaire que l'ISA x86 supporte l'héritage multiple pour pouvoir implémenter un compilateur C++? De la même manière, on peut le faire pour le CLR et cela a été fait pour le langage Eiffel.

Quant au pointeurs, ils ne sont pas supporter en tant que tels, mais si on considère les pointeurs du C, ils servent avant tout à référencer des données ou des fonctions. Dans .NET les instances des objets sont toujours accédé par référence, et les "delegate" permettent de référencer des fonctions. Que voudriez-vous de plus? En outre, si on considère le langage C# lui-même, en utilisant du code "unsafe" on peut manipuler des pointeurs directement.

Non, il n'existe pas de moyen de d'évaluer un syntaxe à la JSON pour C# à l'aide d'un "eval", ce qui pour autant n'empêche pas l'utilisation du JSON à l'aide d'un peu de code, ce qui revient plus ou moins au même que pour l'ECMAScript ou l'on utilise plus depuis belle lurette le eval pour cette application.

Le framework .NET est une machine virtuelle tout à fait assimilable à un processeur physique et une bibliothèque de classe. Pour le langage, vous utilisez celui que vous préférez et/ou celui qui convient le mieux.

[DonQuiche]

Mais pour le jQuery en C# c'est loin d'être aussi optimal mais cependant c'est peut-être plus performant à l'exécution...

C'est vrai que la syntaxe est un poil rallongée dans ce cas précis mais rien n'empêcherait de la rendre semblable à celle de jquery. Qui plus est les autres exemples étaient à l'avantage de C# et ne pouvaient tout simplement pas être faits en JS.

Est-il possible d'avoir une syntaxe en JSON en C#, ce serais aussi une extension ??? :lil: Laissez moi rire...

Non, c'est dispo en standard, on appelle ça les types anonymes.
C'est toujours du typage statique, le type est implicitement déduit et créé à la compilation.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

var truc = { ID = 12, Children = { { ID = 5}, { ID = 6 } } };

Mais si on veut du typage dynamique...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
dynamic MyFunc(dynamic a)
{
   a.Truc = 5;
   return new ExpandObject { Bidule = 6 };
}

Edit : De plus, c'est dommage qu'il n'y ai pas de pointeur en .NET, j'espère que ça reviendra. Ainsi que l'héritage multiple

Bien sûr qu'il y a des pointeurs.
Pour l'héritage multiple, en revanche, je ne nie pas et je le déplore... Mais la seule chose qui me manque vraiment au quotidien dans le langage lui-même ce sont des possibilités intégrées d'AOP (il faut aujourd'hui passer par des outils externes assez lents qui réécrivent l'assembly en fonction des métadonnées qui décorent les membres et types), ça devrait être pour la v6 toutefois. Et peut-être un plus grand contrôle sur la compilation (attributs d'inlining, vecteur simd de Mono, etc).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
byte* ptr = &a;
for(int i = 0; i < 100; ++i) { *ptr = 5;  ++ptr; }

Structurellement je maintiens, les langages MS sont des langages trop coincés et beaucoup moins souples que le js.

Attention, JS, Lua & co sont des langages objet à typage dynamique, tandis que C++, C#, VB, Pascal & co sont des langages objet à typage statique. Mais il existe aussi des langages dotnet dynamiques, comme IronPython.
Et, oui, un langage dynamique est souple dans le bon sens mais il est aussi lâche dans le mauvais sens : quand tu manipules un objet dans un langage statique, tu sais quel contrat il respecte, alors que dans un langage dynamique cet objet pourrait être n'importe quoi.

Si ton code est de petite taille, tu sais parfaitement qui est connecté à quoi et comment il procède, ce n'est donc pas gênant. Mais pour un code de plus grande taille, non seulement l'augmentation du volume du code accroît exponentiellement le temps perdu en examen du code existant et le nombre de bugs, mais tu finis en réalité par définit des types, au moins sur le papier, afin de t'y retrouver. Et une fois que tu as dû coucher sur le papier une architecture avec des types définis, tu n'as plus que des inconvénients à utiliser un langage dynamique, sauf peut-être pour des rustines de dernière minute.

L'opposition statique/dynamique se résume vraiment à une simple question de taille et de complexité de code. Rien d'autre et certainement pas une question de préférence personnelle, ou alors c'est davantage une question de méconnaissance d'un de ces outils et de familiarité avec l'autre. Pour ma part je n'hésite pas à me tourner vers des langages dynamiques pour du prototypage. Bon, pas du JS, faut pas déconner, c'est vraiment trop crade.

[GuruuMeditation]

Quant à l'héritage multiple, pour ma part je n'ai aucun regret. Ça menait généralement à des "architectures" totalement immondes

+1.
Ma première réaction quand j'ai commencé C#(venant du c++) : quoi? Pas d'héritage multiple?
Mais je me suis vite rendu du compte que ce n'étais pas nécessaire et que, effectivement, ça trahissait plus un problème d'architecture qu'autre chose....

[stailer]

Comparer C# et JS c'est n'importe quoi : leur similitude s'arrête sur le fait que ce sont 2 langages de programmation... Mais alors après leur "destination" n'est pas du tout la même !!

Tant qu'à :

Les seuls cas où un langage dynamique comme JS est plus adapté pour l'UI sont :

Le prototypage ou les logiciels de petite taille.

Genre ExtJS 4 quoi.... Un petit projet à l'état de maquette

J'ai déjà développé 2 projets sur ce framework destiné à l'UI et je vais attaquer le 3ème.. C'est une tuerie et oui : c'est bien du JAVASCRIPT

EDIT : concernant les types dynamiques en c# , j'ai eu un problème mais peut être que l'un de vous pourra me donner la solution :

en JS ou PHP si je fais :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
$t = new stdClass();
$t->propA = 'toto';
 
// ici du code
 
// puis je décide de rajouter des propriétés à $t 
$t->propB = 'AA'
 
 
En c# je ne peux pas faire ça :
 
var x = { propA = "test" };
 
/// ici du code
 
// Et la :
x.propB = 'test2'  // -> ne peut évidemment pas marcher !

Donc je ne peux à priori pas rajouter des propriétés à la volée comme en PHP ou Javascript..

[BenoitM]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$t = new stdClass();
$t->propA = 'toto';
 
// ici du code
 
// puis je décide de rajouter des propriétés à $t 
$t->propB = 'AA'

Ca me fait penser à mes erreurs quand j'ai developper en VB6 , a tiens le compilateur qui ralle pas parce que j'ai fait une faute de tappe dans mon code part contre au run

[DonQuiche]

@Stailer
J'ai déjà exposé mes arguments : un langage dynamique te fait perdre en productivité quand le code croît en taille du fait de l'impossibilité de définir des contraintes sur les objets échangés, ce qui t'oblige à avoir une carte mentale très précise du code de tout le projet, chose impossible au-delà d'un certain point. Si tu crois le contraire, libre à toi. Cela dit je t'invite à compter, passé six mois de développement, combien de temps tu passes chaque jour à relire du code existant pour vérifier le nom d'une variable ou qui ajoute quel champ, et celui perdu à déboguer des problèmes qu'un compilateur aurait relevé avec un langage statique. Mesure et à mon avis tu rejoindras mon opinion.

Sur ta question, ce que tu montres n'est pas un usage du typage dynamique mais du typage implicite. Le mot "var" sert soit à déclarer un type statique anonyme, soit à demander au compilateur de déduire lui-même le type de la variable pour éviter de l'écrire.

Avant de te montrer un code dynamique en C# il faut d'abord que tu saisisses une nuance : langage dynamique signifie simplement que les données de l'objet peuvent être obtenues à l'exécution via une syntaxe transparente, pas forcément que tous les types peuvent se voir ajouter n'importe quoi à n'importe quel moment, ce n'est qu'une option. Option que C# supporte également. Ceci étant dit, rentrons dans les détails :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
// Commençons avec l'ExpandoObjet, c'est un objet au sens JS, auquel on peut ajouter n'importe quoi n'importe quand.
dynamic obj = new ExpandoObject();
obj.a = "a";
 
// Maintenant un exemple de typage dynamique sur un objet qui peut être n'importe quoi, y compris un type statique.
bool myFunction(dynamic arg)
{
   return arg.a == "a";
}

En résumé tu peux utiliser du typage dynamique avec n'importe quel objet mais tu ne peux pas étendre à volonté n'importe quel objet, tout dépend de son type sous-jacent (la différence étant qu'en JS tout dérive en interne d'un type équivalent à ExpandoObject).

PS : Si on voulait être rigoureux il faudrait faire le distinguo entre "langage dynamique" et "typage dynamique". La plupart des langages dynamiques ont un typage dynamique mais pas tous.

[MiaowZedong]

Ici @MiaowZedong le C# contre Lisp (peut importe qu'il soit fonctionnel ou objet) ne permet pas de redéfinir le langage ou sa syntaxe...

Tu parles des macros là, me semble-t-il. C'est vrai que le LISP te permet en fait de définir un autre language, qui sera transposé en LISP avant d'être interpreté/compilé. Le C# ne le fait pas mais ce n'est pas dans la philosophie du language et, franchement, pas nécessaire pour l'utilisation qu'on en fait.

Petit rappel, dans le LISP Code is Data et tout, absolument tout, passe par la fonction eval--en fait, un programme LISP c'est une suite de linked lists passées dans la Read-Eval-Print loop. C'est utile. C'est aussi très dangereux: il est très facile de créer un programme au comportement imprévu et non-désiré (SkyNet est sûrement programmé en LISP ).

Si tu as vraiment besoin de tout redéfinir en C# rien ne t'empêche d'écrire ton propre interpreteur en C# pour un language que tu définiras. Il n'empeche que de façon générale, aujourd'hui, l'on privilégie les composants standards pour faciliter le travail en équipe.

[stailer]

@DonQuiche : merci pour le ExpandoObject... je pense que ça va rapidement me servir pour un outil que je développe actuellement.

Pour le reste, c'est n'importe quoi et je ne suis toujours pas d'accord.
Mais c'est vrai, je me souviens de toi, en fait on se prend la tête à chaque fois.

Donc en effet, inutile de continuer ici on sera jamais d'accord.

[tomlev]

Pour le reste, c'est n'importe quoi et je ne suis toujours pas d'accord.

Dommage que tu n'expliques pas pourquoi...

[stailer]

J'ai déjà expliqué ! A chaque fois c'est toujours la même histoire.

Je trouve stupide de comparer PHP et C# ou C# et Java .
J'ai déjà développé et je connais déjà des développeurs ayant réalisé de très gros projets avec PHP et javascript.

Il y a des dizaines de facteurs à prendre en compte avant de juger un langage ou même avant de savoir sur quoi on va partir selon le besoin du client etc.

Personnellement j'ai fais pas mal de trucs en Flex4, Silverlight4, PHP/Zend Framework, ASP.NET MVC3 ....

Je suis très content de toutes ces technos. J'adore ASP.Net MVC mais il y a pas mal de trucs en faveur de ZF.. Par contre dans ZF Linq m'a clairement manqué etc etc...

Bref, j'ai déjà expliqué. on va pas y repasser 20 ou 30 réponses la dessus.

[alex_vino]

Le sujet s'écarte un peu du topic...

On va dire pour résumer que chaque language a ces points forts et points faibles (+ adeptes et réticents)

Merci @tomlev pour ton lien précédent concernant Win8 et .Net, je trouve qu'il récapitule bien.

[zulad]

Non, pas du tout. WinRT est l'API qui permet le développement d'applications Metro. C'est basé sur COM, et c'est utilisable depuis différentes technos (C++, .NET, Javascript...). Ça ne remplace absolument pas le .NET Framework.

Ca veux dire que pour implémenter sous Win8 on pourra le faire dans le "framework" de WinRT et faire du .NET, le tout en même temps ?