Dans son histoire, Microsoft a toujours su tres habilement se retourner.
Il a reussi a imposer une interface graphique en partant d'une grosse merde (windows 3), alors qu'il existait des concurrents bien meilleur.
Il a reussi a rentrer dans le lard du marche unix avec Windows NT, pourtant une grosse merde aussi a la base (ca a peut-etre change).
Il a loupe le premier virage internet mais le rattrappe avec IE et IIS.
Il va probablement rentrer dans le lard a Apple avec XP. Il en profite pour degager RealPlayer et Java qui commencaient a lui casser les couilles.
Alors on critique Microsoft pour plein de raisons, mais il ne faut jamais oublier que Microsoft est tres fort. Pas seulement par sa machine marketing et commerciale. Ils savent tres tres bien reagir et corriger leurs erreurs. En general, ils font ca bien avant que ca ne leur soit fatal.
Par exemple, sur les virus les macros, on commence a atteindre un seuil critique. A mon avis, bientot ils feront des vrais produits securises parce que sinon, ils risquent de perdre des clients. Ca ne sera pas parfait mais suffisamment mieux pour justifier de rester a Windows.
D'un point de vue Dev, que peut-on reprocher a la plateforme Microsoft ? En gros pour faire une appli, soit on utilise VB mais ca devient quand meme vite limite, soit on utilise VC++ et les MFC. Mais voila, les MFC datent des annees 80, et c'est un gros tas de boue par dessus des appels systemes en C, melanges avec du pseudo objet et une communication par boucle d'evenement. On peut dire qu'ils ont 5 a 10 ans de retard en terme d'interface graphique.
Si on veut faire du dev en autre chose qu'en C++ sous Windows, on va faire du Delphi ou du Java. On sent bien que Microsoft ne controle pas cette zone.
Donc Microsoft lance .NET . Ils vont repondre aux problemes suivants, tous d'un coup:
- on pourra faire facilement des interfaces graphiques dans un langage avance. Exit les MFC, qui auraient deja du partir depuis longtemp. Ils recuperent les developpeurs en Swing et en Delphi.
- tout comme Java, c'est sense etre portable a mort. Ils touchent directement les gens qui ont toujours ete sensibles au "Write once, run Anywhere" qui malheureusement pour Sun, est un echec.
- ils supportent tous les langages en meme temps. C'est un coup tres fort. Jusqu'a present, pour ne pas faire de microsoft, il suffisait de vouloir faire du perl, du python, du java, du delphi, de l'eiffel. Maintenant, ce n'est plus le cas. C'est a mon avis leur coup le plus fort. Ils font les partenariats qu'il faut et vont les faire marcher jusqu'a pouvoir dire qu'ils supportent tous les langages.
- ils vont plus loin que Java puisqu'ils unifient les plate-formes et les langages. Le nombre de raisons de ne plus faire du microsoft va beaucoup diminuer.
En plus de repondre a des problemes qu'on a sous Windows, microsoft attaque unix aussi directement. Quel est le plus gros probleme de Unix ? La fragmentation:
- aucune appli n'a de methode standard pour parler a une autre. Heureusement, on commence a voir des choses avec Bonobo, DCOP ou SOAP, mais ca reste encore tres fragmente et incompatible.
- aucune appli n'a de methode standard pour reutiliser des composants d'une autre appli. La aussi Gnome et KDE commencent a nous apporter des solutions, mais c'est tardif.
- la diversite des langages se fait a un cout tres eleve. Pour gtk, les binding se font a la main et ont donc beaucoup de retard. Pour Qt, c'est tres complique de faire des bindings (merci le C++).
A cause de tout ca, il y a des milliers d'appli inachevees et concurrentes qui ont du mal a beneficier de l'existant. On est presque toujours obliger de reprendre a la base parce qu'a chaque fois qu'il existe qqch qui pourrait servir au dev d'une autre appli, ce n'est pas comme il faut.
La facon la plus portable de faire un composant reutilisable est aujourd'hui de faire une bilbiotheque. Mais ca veut dire que vous ne pouvez faire de composant qu'en C ou C++. Cela veut dire que les nouveaux langages (perl python, ruby, ...) ne pourront pas en beneficier tout de suite, il faudra wrapper la bibliotheque. En plus, ca ne marche que dans un sens. Une bonne bibliotheque ecrite en perl est inutilisable en python/C/Ada/C++/Ruby/... Il faudra la redevelopper dans pratiquement chacun de ces langages.
Aucun de ces problmes ne se pose avec .NET. Toutes les applis sont capables de communiquer entre elles et de reutiliser en tant que composant, ce quel que soit le langage dans lequel elles ont ete ecrite.
Moi je vois dans .NET une excellente manoeuvre de la part de Microsoft. D'ici 10 ans, Java sera marginalise et Microsoft aura pris une plus grande part encore de developpeurs que ce qu'ils ont actuellement. Ils auront recupere des gens de perl, de python, de ruby, de Eiffel, de Java... Les autres coderont en C# pour Windows mais seront persuade de faire un truc portable.
La question: Microsoft sera-t-il honnete jusqu'au bout avec les specifications de .Net ? A mon avis, non. Un jour, ils vont "craquer" et introduire les petites "ameliorations" Windows et Microsoft. Mais ils le feront tres tard, quand la plateforme aura deja ete adoptee. Et ca ne diminuera qu'un peu l'interet de .NET . Un programme perl.NET pourra toujours communiquer avec un programme python.NET .
Donc il faut bien comprendre que .NET apporte beaucoup de solutions. En plus, cela arrive apres Java, donc ils peuvent tirer des lecons des erreurs et des succes des autres.
Quand on lit la page de MDI, on ressent qu'il "souffre" des problemes d'UNIX que j'ai cite plus haut (en gros, le manque de communication inter-appli). .NET apporte une solution, je comprends qu'il s'y interresse. MDI a lance Gnome pour repondre a ces problemes. Je comprends qu'il soit emballe par .NET et ce n'est pas forcement la chose la plus stupide a faire que de baser Gnome dessus.
En tout cas, vu l'importance que .NET va prendre par la suite, mieux vaut que Unix ne soit pas encore plus marginalise en ayant pas de .NET du tout. Sinon, ca va etre tres dur d'en vendre a des entreprise. Y a qu'a voir comment ca nous coute de ne pas avoir Word et Excel, on a pas besoin de ca en plus.
# Reaction mitigee
Posté par Philippe F (site web personnel) . En réponse à la dépêche Miguel DeIcaza et .NET. Évalué à 10.
Il a reussi a imposer une interface graphique en partant d'une grosse merde (windows 3), alors qu'il existait des concurrents bien meilleur.
Il a reussi a rentrer dans le lard du marche unix avec Windows NT, pourtant une grosse merde aussi a la base (ca a peut-etre change).
Il a loupe le premier virage internet mais le rattrappe avec IE et IIS.
Il va probablement rentrer dans le lard a Apple avec XP. Il en profite pour degager RealPlayer et Java qui commencaient a lui casser les couilles.
Alors on critique Microsoft pour plein de raisons, mais il ne faut jamais oublier que Microsoft est tres fort. Pas seulement par sa machine marketing et commerciale. Ils savent tres tres bien reagir et corriger leurs erreurs. En general, ils font ca bien avant que ca ne leur soit fatal.
Par exemple, sur les virus les macros, on commence a atteindre un seuil critique. A mon avis, bientot ils feront des vrais produits securises parce que sinon, ils risquent de perdre des clients. Ca ne sera pas parfait mais suffisamment mieux pour justifier de rester a Windows.
D'un point de vue Dev, que peut-on reprocher a la plateforme Microsoft ? En gros pour faire une appli, soit on utilise VB mais ca devient quand meme vite limite, soit on utilise VC++ et les MFC. Mais voila, les MFC datent des annees 80, et c'est un gros tas de boue par dessus des appels systemes en C, melanges avec du pseudo objet et une communication par boucle d'evenement. On peut dire qu'ils ont 5 a 10 ans de retard en terme d'interface graphique.
Si on veut faire du dev en autre chose qu'en C++ sous Windows, on va faire du Delphi ou du Java. On sent bien que Microsoft ne controle pas cette zone.
Donc Microsoft lance .NET . Ils vont repondre aux problemes suivants, tous d'un coup:
- on pourra faire facilement des interfaces graphiques dans un langage avance. Exit les MFC, qui auraient deja du partir depuis longtemp. Ils recuperent les developpeurs en Swing et en Delphi.
- tout comme Java, c'est sense etre portable a mort. Ils touchent directement les gens qui ont toujours ete sensibles au "Write once, run Anywhere" qui malheureusement pour Sun, est un echec.
- ils supportent tous les langages en meme temps. C'est un coup tres fort. Jusqu'a present, pour ne pas faire de microsoft, il suffisait de vouloir faire du perl, du python, du java, du delphi, de l'eiffel. Maintenant, ce n'est plus le cas. C'est a mon avis leur coup le plus fort. Ils font les partenariats qu'il faut et vont les faire marcher jusqu'a pouvoir dire qu'ils supportent tous les langages.
- ils vont plus loin que Java puisqu'ils unifient les plate-formes et les langages. Le nombre de raisons de ne plus faire du microsoft va beaucoup diminuer.
En plus de repondre a des problemes qu'on a sous Windows, microsoft attaque unix aussi directement. Quel est le plus gros probleme de Unix ? La fragmentation:
- aucune appli n'a de methode standard pour parler a une autre. Heureusement, on commence a voir des choses avec Bonobo, DCOP ou SOAP, mais ca reste encore tres fragmente et incompatible.
- aucune appli n'a de methode standard pour reutiliser des composants d'une autre appli. La aussi Gnome et KDE commencent a nous apporter des solutions, mais c'est tardif.
- la diversite des langages se fait a un cout tres eleve. Pour gtk, les binding se font a la main et ont donc beaucoup de retard. Pour Qt, c'est tres complique de faire des bindings (merci le C++).
A cause de tout ca, il y a des milliers d'appli inachevees et concurrentes qui ont du mal a beneficier de l'existant. On est presque toujours obliger de reprendre a la base parce qu'a chaque fois qu'il existe qqch qui pourrait servir au dev d'une autre appli, ce n'est pas comme il faut.
La facon la plus portable de faire un composant reutilisable est aujourd'hui de faire une bilbiotheque. Mais ca veut dire que vous ne pouvez faire de composant qu'en C ou C++. Cela veut dire que les nouveaux langages (perl python, ruby, ...) ne pourront pas en beneficier tout de suite, il faudra wrapper la bibliotheque. En plus, ca ne marche que dans un sens. Une bonne bibliotheque ecrite en perl est inutilisable en python/C/Ada/C++/Ruby/... Il faudra la redevelopper dans pratiquement chacun de ces langages.
Aucun de ces problmes ne se pose avec .NET. Toutes les applis sont capables de communiquer entre elles et de reutiliser en tant que composant, ce quel que soit le langage dans lequel elles ont ete ecrite.
Moi je vois dans .NET une excellente manoeuvre de la part de Microsoft. D'ici 10 ans, Java sera marginalise et Microsoft aura pris une plus grande part encore de developpeurs que ce qu'ils ont actuellement. Ils auront recupere des gens de perl, de python, de ruby, de Eiffel, de Java... Les autres coderont en C# pour Windows mais seront persuade de faire un truc portable.
La question: Microsoft sera-t-il honnete jusqu'au bout avec les specifications de .Net ? A mon avis, non. Un jour, ils vont "craquer" et introduire les petites "ameliorations" Windows et Microsoft. Mais ils le feront tres tard, quand la plateforme aura deja ete adoptee. Et ca ne diminuera qu'un peu l'interet de .NET . Un programme perl.NET pourra toujours communiquer avec un programme python.NET .
Donc il faut bien comprendre que .NET apporte beaucoup de solutions. En plus, cela arrive apres Java, donc ils peuvent tirer des lecons des erreurs et des succes des autres.
Quand on lit la page de MDI, on ressent qu'il "souffre" des problemes d'UNIX que j'ai cite plus haut (en gros, le manque de communication inter-appli). .NET apporte une solution, je comprends qu'il s'y interresse. MDI a lance Gnome pour repondre a ces problemes. Je comprends qu'il soit emballe par .NET et ce n'est pas forcement la chose la plus stupide a faire que de baser Gnome dessus.
En tout cas, vu l'importance que .NET va prendre par la suite, mieux vaut que Unix ne soit pas encore plus marginalise en ayant pas de .NET du tout. Sinon, ca va etre tres dur d'en vendre a des entreprise. Y a qu'a voir comment ca nous coute de ne pas avoir Word et Excel, on a pas besoin de ca en plus.