La stratégie de Microsoft

Je ne comprends pas l'intérêt de .NET pour Microsoft. Il y a quelques années Sun à lancé Java qui a répondu aux attentes des entreprises, à savoir une plateforme qui permet de développer rapidement des logiciels. A cette époque Microsoft n'avait pas d'alternative. Non seulement Microsoft ne pouvait pas utiliser Java comme il le voulait, mais Java représentait une menace pour le groupe, en effet, java permet d'élaborer rapidement des applications multiplateformes et ce sur 4 plateformes (Windows, Linux, Mac OS et Solaris), les applications développées en Java n'ont plus besoin de Windows. Microsoft à donc élaboré sa solution, très proche de Java : .NET. Là ou Sun dit « si vous écrivez en Java, vous pourrez l'exécuter sur n'importe quelle plateforme (ou presque) », Microsoft répond « si vous l'exécutez sur Windows, vous pourrez l'écrire dans n'importe quel langage (ou presque) ». Les deux approches sont amusantes dans la mesure où techniquement, rien n'empêche quelqu'un de créer un langage et de le compiler en Byte-Code (langage intermédiaire de Java) et rien n'empêche quelqu'un de prendre un code IL (langage intermédiaire de .NET) et de le faire tourner sur une autre plateforme que Windows (le projet Mono en est la preuve). Même si les développeurs changent rarement de plateforme de développements et qu'il leur arrive rarement d'avoir besoin d'écrire des applications multiplateformes, l'initiative est intéressante, car elle permet de ne pas se fermer sur une seule plateforme. D'un autre coté s’il arrive rarement à un développeur de changer de langage de programmation, il peut être intéressant dans certains cas d'utiliser des langages qui leur permettent d'écrire certaines instructions plus facilement (je pense par exemple aux types inductifs qui existent dans très peu de langages impératifs orientés objets).
La stratégie de Microsoft c'est quoi ? Depuis très longtemps la stratégie du groupe de Redmond consiste à promouvoir le système d'exploitation Windows et les suites bureautiques Office. Il est bon de rappeler que Windows et Microsoft Office représentent à peu près 80 % des revenus de la firme. Par exemple, si Visual Studio est un excellent environnement de développement intégré c'est très certainement pour inciter les développeurs à développer sous Windows des applications qui pourront dans la plupart des cas ne s'exécuter que sous Windows. Est-ce que cette stratégie est dans l'intérêt de l'utilisateur ? Oui et non, certes étant donné que la plateforme d'exécution est figée on peut penser que l'éditeur peut se permettre des optimisations impossibles à mettre en œuvre si l'on ne connait pas à l'avance la plateforme d'exécution du logiciel. D' un autre coté, on enferme l'utilisateur sur une plateforme qu'il a choisi au départ mais sur laquelle il n'a pas forcément envie de passer le reste de ses jours. Il existe évidemment des marchés satellites comme le jeu vidéo et la recherche en ligne qui n'ont que peu d'influences sur les ventes de Windows et des suites Microsoft Office.
Vous l'avez compris le but de Microsoft avec .NET est d'offrir une plateforme de développement aussi facile d'utilisation que Java (voir plus) tout en « obligeant » les développeurs à développer des applications qui ne s'exécuteront que sous Windows. Au vu de la stratégie de Microsoft on n’est pas surpris de l'apparition de .NET.

Pourquoi Java est privilégié par les entreprises ? Parce que Java est une plateforme qui gère automatiquement la mémoire et évite donc aux développeurs les erreurs de segmentations et autre fuites mémoires. Java dispose en plus d'une grosse libraire très riche et fort bien documentée. Les développeurs Java sont très actifs et sortent régulièrement des cadriciels permettant de faciliter le développement des logiciels. .NET propose les mêmes avantages.
Pourquoi Java est compilé en langage intermédiaire ? C'est pour ne pas être dépendant d'une plateforme particulière et ainsi être portable. Cette semi-compilation couplé à l'utilisation d'un ramasse-miette rend les exécutables compilés en Java assez lents, parce que non seulement le JIT (le compilateur « juste à temps ») devra finir la compilation en cours d'exécution mais en plus le ramasse-miette devra faire son travail tout au long de l'exécution du logiciel. Un programme compilé en Java est donc théoriquement fatalement plus lent qu'un programme compilé en langage machine et à fortiori plus lent qu'un programme compilé en langage machine s'exécutant sans ramasse miette. J'entends d'ici les Javaïstes et les .NETistes hurler qu'aujourd'hui les JIT sont très rapides (et ils n'ont pas tord) et que les ramasse-miettes sont de nos jours très rapides (ils ont raisons) et qu'aujourd'hui les programmes écrit en C# ou en Java sont aussi rapides que des programmes écrit en C/C++ voir plus. En effet, il est possible de bricoler un benchmark en faveur des langages disposant de ramasse-miettes, la gestion de la mémoire en C/C++ est statique voir déterministe et à donc peu de chance d'être intelligente. Alors que le ramasse-miettes fait son travail méticuleusement, sans erreur, il s'arrange pour libérer la mémoire au moment ou ça gênera le moins l'utilisateur de l'application. Pour ces raisons là il arrive que les langages disposant de ramasses miettes produisent des exécutables plus rapides que les exécutables ne nécessitant pas de ramasse-miettes. Pour qu'un exécutable disposant d'un ramasse miette soit plus rapide qu'un exécutable ne disposant pas d'un ramasse miette, il faut que la gestion de la mémoire par le ramasse-miettes soit tellement intelligente qu'elle « gomme » le temps d'exécution du ramasse-miettes. C'est possible, des benchmarks le prouvent, mais c'est difficile à faire, et je ne suis pas persuadé que c'est toujours possible. De plus, n'en déplaise aux fans de Java et .NET, rares sont les applications légères écrites en Java ou en .NET (je préfère dire .NET que C# ou VB.NET ou F# etc.) elles sont souvent bien plus lourdes (en mémoire et en CPU) et moins réactives que leurs alternatives compilées en langage machine. Bref, Java nous offre une portabilité et une facilité de développement qui se paye au prix d'une certaine lourdeur, lourdeur qui est loin d'être gênante pour la plupart des entreprises, d'où le succès de Java. Dans le cas de .NET bien qu'étant considéré comme étant un brin plus performant que son concurrent libre (Java), il offre les mêmes inconvénients que ce dernier sans pour autant offrir la portabilité. Alors oui, Mono existe et le projet avance, mais il n'avance pas aussi vite que le .NET de Microsoft et la portabilité des exécutables .NET n'est pas garanti (ni même prétendu) par Microsoft. Alors oui, Microsoft n'a stratégiquement pas intérêt à ce que .NET soit portable, sinon son alternative n'a aucun intérêt si ce n'est de plagier la solution de Sun. Mais pourquoi permettre cette portabilité ? .NET aurait été tout aussi agréable pour les développeurs si les exécutables étaient compilés directement en langage machine (en gardant bien sûr le ramasse-miettes). Il aurait évité l'apparition de projets comme Mono, qui sont très intéressants pour les utilisateurs et les développeurs mais pas pour la firme. Certes Mono à un train de retard sur Microsoft, mais ces derniers temps les choses se sont accélérées et le rêve de voir un .NET portable dans un avenir proche devient de plus en plus réaliste.

Des benchmarks ont montré que les langages compilés en langage machine disposant d'un ramasse miettes peuvent avoir des performances équivalentes aux C/C++, bien que je doute qu'en dehors du cadre du benchmarking ces résultats soient confirmés, il est clair que même en gardant le ramasse miette, compiler directement un langage en langage machine permet à un exécutable de s'exécuter beaucoup plus rapidement qu'un exécutable compilé en langage intermédiaire.

De plus, Microsoft semble mettre de coté les langages ne disposant pas de ramasse-miettes comme C/C++ (pourtant très utilisés pour écrire des clients lourds) au profit de sa plateforme .NET. Il parait même que des morceaux de Windows Vista seraient faits en .NET (en dehors du framework bien entendu), ce qui pourrait expliquer pourquoi ce système d'exploitation est aussi lourd. Dans les laboratoires de recherche de Microsoft un nouveau système d'exploitation est en cours de développement : Midori (à ne pas confondre avec le navigateur web) un système d'exploitation fait entièrement en .NET, certes ce projet est technologiquement intéressant et montre qu'on à pas besoin de langages comme C et C++ pour développer des OS. Mais qu’en est-il des performances de ce système ? On a vu récemment avec Windows Vista que la lourdeur d'un système d'exploitation peu être rédhibitoire, et que l'arrivée des ordinateurs ultra-portables va pousser à revoir la conception des applications afin de les rendre plus légères. En effet, pendant longtemps les éditeurs disait « si Monsieur X n'a pas assez de RAM pour faire tourner notre application il achètera des barrettes »; dans un marché ou la plupart des PC vendu sont des ordinateurs portables est-ce que cette attitude est encore crédible ? En période de récession économique et de crise du pouvoir d'achat, combien d'utilisateurs de PC (portables ou de Bureau ou même de Macintosh) seraient prêt à mettre à jour leur machine juste pour quelques logiciels ? Bref, si Java et .Net facilitent la vie des développeurs, les applications qui en résultent (lorsqu’il s’agit de clients lourds destiné au grand public) s’apparentent à des boulets accrochés aux pieds des utilisateurs finaux. Je trouve d’ailleurs quelques développeurs un peu égoïstes, ils ne se soucient guère du confort d’utilisation de leur logiciel, ils ne pensent qu’a leur confort. Ils préfèrent un programme agréable à développer qu’un programme agréable à utiliser, c’est étrange dans la mesure où les programmes sont avant tout fait pour être utilisés, l’informatique pour l’informatique ne sert à rien (c’est de la branlette intellectuelle). Microsoft semble adopter un comportement similaire en privilégiant .NET, ainsi il n’est pas impossible que plus tard, la plupart des clients lourds pour Windows soient écrit en .NET.
Un client lourd écrit en .NET est client qui porte trop bien son nom (lourd…) et qui donc n’est pas nécessairement bénéfique pour les utilisateurs, c’est de plus un logiciel potentiellement portable, qui pourra donc si le projet Mono le permet tourner sous Linux, Mac OS etc. Bref, un programme qui n’arrange pas les affaires de Microsoft, donc quel est l’intérêt de .NET pour Microsoft (et les utilisateurs….) ? Si les applications étaient directement compilé en langage machine, elles seraient moins pénibles pour les utilisateurs finaux, elles seraient, à priori, tout aussi agréable pour les développeurs, et elles rendraient plus difficile le portage des applications .NET sur d’autres plateforme, ce qui est mauvais pour les utilisateurs, mais bon pour la firme de Redmond. J’ai l’impression qu’avec .NET, Microsoft va droit dans le mur, si tous les logiciels Microsoft et les clients lourds pour Windows sont écrit en .NET les utilisateurs petit à petit fuiront ces logiciels comme ils le font avec Windows Vista (qui à aujourd’hui pour seul défaut sa lourdeur), Windows Vista qui ne peut pour l’instant être utilisé sur les ultra-portables justement à cause de sa lourdeur, ceci à obligé la firme a maintenir le vieillissant Windows XP afin de ne pas laisser Linux s’accaparer tout le marché.

Je pense qu’encore aujourd’hui, le C et le C++ ont encore de l’avenir, même si d’autres langages compilé en langage machines mais disposant de ramasse-miettes pourraient bien leur faire de l’ombre. Pour les applications Web, je pense que Java suffit largement, et je ne pense pas que les lacunes de Java soient assez rédhibitoires pour privilégier .NET.