Sun a finalement annoncé le passage prochain de son langage Java, en
Open Source.
L'hésitation porte à l'heure actuelle sur le type exact de licence, Sun
voulant garder la main sur le langage.
Quoiqu'il en soit le code de Java sera ouvert.
Cela va t-il sonner le glas pour les techno .NET ?
Le soucis à l'époque c'était que dans les différentes VM, celle de Microsoft était la plus performante (comparé à celle de Sun ou IBM). Aussi que Visual J++ était plutôt bien (un poil dérriere les produits Borland) ? Je ne saurais pas être aussi affirmatif que toi. La JVM la plus
performante jusqu'à présent est celle d'IBM. Et pourtant, Sun n'en fait pas pour autant un caca nerveux.
Sun n'a pas trop apprécié d'être 20% moins rapide sur leur VM. Il a argumenté que le support de plus que Java (les objets COM en autre), c'était mal. Bref pas touche à la syntaxe Java, même si c'était pour du spécifique Microsoft. Non, le problème de Microsoft avec Java est qu'il a tenté sa bonne vieille
stratégie qui lui a toujours réussi : "adopte le, modifie le, tue le". Le véritable problème de la JVM de Microsoft est qu'elle n'était compatible qu'avec son implémentation de Java ; on ne pouvait pas y faire fonctionner correctement une appli écrite avec autre chose que Visual J++. D'où le procès car Microsoft allait à l'encontre des principes et de l'image même de Java : un environnement multi-plateforme, "write once, run anywhere".
Sinon la VM de Microsoft suivait à 100% la norme Java, pour preuve un .java compilé avec le JDK fonctionnait avec la VM de Microsoft. Non, et c'était bien le problème.
Remi THOMAS wrote:
Le soucis à l'époque c'était que dans les différentes VM, celle de
Microsoft était la plus performante (comparé à celle de Sun ou IBM).
Aussi que Visual J++ était plutôt bien (un poil dérriere les produits
Borland)
? Je ne saurais pas être aussi affirmatif que toi. La JVM la plus
performante jusqu'à présent est celle d'IBM. Et pourtant, Sun n'en fait pas
pour autant un caca nerveux.
Sun n'a pas trop apprécié d'être 20% moins rapide sur leur VM.
Il a argumenté que le support de plus que Java (les objets COM en autre),
c'était mal. Bref pas touche à la syntaxe Java, même si c'était pour du
spécifique Microsoft.
Non, le problème de Microsoft avec Java est qu'il a tenté sa bonne vieille
stratégie qui lui a toujours réussi : "adopte le, modifie le, tue le".
Le véritable problème de la JVM de Microsoft est qu'elle n'était compatible
qu'avec son implémentation de Java ; on ne pouvait pas y faire fonctionner
correctement une appli écrite avec autre chose que Visual J++. D'où le
procès car Microsoft allait à l'encontre des principes et de l'image même
de Java : un environnement multi-plateforme, "write once, run anywhere".
Sinon la VM de Microsoft suivait à 100% la norme Java, pour preuve un
.java compilé avec le JDK fonctionnait avec la VM de Microsoft.
Non, et c'était bien le problème.
Le soucis à l'époque c'était que dans les différentes VM, celle de Microsoft était la plus performante (comparé à celle de Sun ou IBM). Aussi que Visual J++ était plutôt bien (un poil dérriere les produits Borland) ? Je ne saurais pas être aussi affirmatif que toi. La JVM la plus
performante jusqu'à présent est celle d'IBM. Et pourtant, Sun n'en fait pas pour autant un caca nerveux.
Sun n'a pas trop apprécié d'être 20% moins rapide sur leur VM. Il a argumenté que le support de plus que Java (les objets COM en autre), c'était mal. Bref pas touche à la syntaxe Java, même si c'était pour du spécifique Microsoft. Non, le problème de Microsoft avec Java est qu'il a tenté sa bonne vieille
stratégie qui lui a toujours réussi : "adopte le, modifie le, tue le". Le véritable problème de la JVM de Microsoft est qu'elle n'était compatible qu'avec son implémentation de Java ; on ne pouvait pas y faire fonctionner correctement une appli écrite avec autre chose que Visual J++. D'où le procès car Microsoft allait à l'encontre des principes et de l'image même de Java : un environnement multi-plateforme, "write once, run anywhere".
Sinon la VM de Microsoft suivait à 100% la norme Java, pour preuve un .java compilé avec le JDK fonctionnait avec la VM de Microsoft. Non, et c'était bien le problème.
talon
Remi THOMAS wrote:
Sinon la VM de Microsoft suivait ? 100% la norme Java, pour preuve un .java compil? avec le JDK fonctionnait avec la VM de Microsoft.
Tu es vraîment une gourde toi. Le problème c'est pas que le Java de Sun implémentait 100% de la norme de Sun, c'est qu'il en implémentait 110%. Ce qui veut dire que, vu la connerie des développeurs Microsoft dont tu es un honorable représentant, la moitié des applications "Java" sur le marché auraient utilisé les 10% restants, et donc saboté l'interopérabilité qui était le but n°1 de l'introduction de Java. En d'autres termes le but de Java était de rendre le hardware et l'OS sans importance, le but de Microsoft était et est toujours d'obliger les gens à utiliser des machines Intel et des OS Microsoft. Voilà pourquoi J++ c'était mal, .NET c'est mal, C# c'est mal, etc. quoi qu'en disent les décérébrés comme Icaza.
R?mi
--
Michel TALON
Remi THOMAS <remi@xtware.com> wrote:
Sinon la VM de Microsoft suivait ? 100% la norme Java, pour preuve un .java
compil? avec le JDK fonctionnait avec la VM de Microsoft.
Tu es vraîment une gourde toi. Le problème c'est pas que le Java de Sun
implémentait 100% de la norme de Sun, c'est qu'il en implémentait 110%.
Ce qui veut dire que, vu la connerie des développeurs Microsoft dont tu es un
honorable représentant, la moitié des applications "Java" sur le marché
auraient utilisé les 10% restants, et donc saboté l'interopérabilité qui était
le but n°1 de l'introduction de Java. En d'autres termes le but de Java était
de rendre le hardware et l'OS sans importance, le but de Microsoft était et
est toujours d'obliger les gens à utiliser des machines Intel et des OS
Microsoft. Voilà pourquoi J++ c'était mal, .NET c'est mal, C# c'est mal, etc.
quoi qu'en disent les décérébrés comme Icaza.
Sinon la VM de Microsoft suivait ? 100% la norme Java, pour preuve un .java compil? avec le JDK fonctionnait avec la VM de Microsoft.
Tu es vraîment une gourde toi. Le problème c'est pas que le Java de Sun implémentait 100% de la norme de Sun, c'est qu'il en implémentait 110%. Ce qui veut dire que, vu la connerie des développeurs Microsoft dont tu es un honorable représentant, la moitié des applications "Java" sur le marché auraient utilisé les 10% restants, et donc saboté l'interopérabilité qui était le but n°1 de l'introduction de Java. En d'autres termes le but de Java était de rendre le hardware et l'OS sans importance, le but de Microsoft était et est toujours d'obliger les gens à utiliser des machines Intel et des OS Microsoft. Voilà pourquoi J++ c'était mal, .NET c'est mal, C# c'est mal, etc. quoi qu'en disent les décérébrés comme Icaza.
R?mi
--
Michel TALON
Ploc
Michel Talon wrote:
Remi THOMAS wrote:
Sinon la VM de Microsoft suivait ? 100% la norme Java, pour preuve un .java compil? avec le JDK fonctionnait avec la VM de Microsoft.
Tu es vraîment une gourde toi. Le problème c'est pas que le Java de Sun implémentait 100% de la norme de Sun, c'est qu'il en implémentait 110%.
ah, Sun implemente plus que la norme?
Michel Talon wrote:
Remi THOMAS <remi@xtware.com> wrote:
Sinon la VM de Microsoft suivait ? 100% la norme Java, pour preuve un .java
compil? avec le JDK fonctionnait avec la VM de Microsoft.
Tu es vraîment une gourde toi. Le problème c'est pas que le Java de Sun
implémentait 100% de la norme de Sun, c'est qu'il en implémentait 110%.
Tu es vraîment une gourde toi. Le problème c'est pas que le Java de Sun implémentait 100% de la norme de Sun, c'est qu'il en implémentait 110%.
ah, Sun implemente plus que la norme?
Michel voulait évidement dire "Le problème c'est pas que le Java de MS implémentait ..."
--
Shut up, fools, 99+% of you are going to end up using Vista anyway. I think you'll find that the answer is
merely 98.2%. Who's the fool NOW!!
Ploc
Manuel Leclerc wrote:
Michel Talon wrote:
Tu es vraîment une gourde toi. Le problème c'est pas que le Java de Sun implémentait 100% de la norme de Sun, c'est qu'il en implémentait 110%. ah, Sun implemente plus que la norme?
Michel voulait évidement dire "Le problème c'est pas que le Java de MS implémentait ..."
Oui, j'ai bien compris, mais vu qu'il parle de la connerie des developpeurs ms et de la personne a qui il repond, je pense qu'il aurait pu au minimum se relire pour eviter d'en dire une (connerie).
Manuel Leclerc wrote:
Michel Talon wrote:
Tu es vraîment une gourde toi. Le problème c'est pas
que le Java de Sun implémentait 100% de la norme de
Sun, c'est qu'il en implémentait 110%.
ah, Sun implemente plus que la norme?
Michel voulait évidement dire "Le problème c'est pas
que le Java de MS implémentait ..."
Oui, j'ai bien compris, mais vu qu'il parle de la connerie des
developpeurs ms et de la personne a qui il repond, je pense qu'il aurait
pu au minimum se relire pour eviter d'en dire une (connerie).
Tu es vraîment une gourde toi. Le problème c'est pas que le Java de Sun implémentait 100% de la norme de Sun, c'est qu'il en implémentait 110%. ah, Sun implemente plus que la norme?
Michel voulait évidement dire "Le problème c'est pas que le Java de MS implémentait ..."
Oui, j'ai bien compris, mais vu qu'il parle de la connerie des developpeurs ms et de la personne a qui il repond, je pense qu'il aurait pu au minimum se relire pour eviter d'en dire une (connerie).
talon
Ploc wrote:
Michel Talon wrote:
Remi THOMAS wrote:
Sinon la VM de Microsoft suivait ? 100% la norme Java, pour preuve un .java compil? avec le JDK fonctionnait avec la VM de Microsoft.
Tu es vraîment une gourde toi. Le problème c'est pas que le Java de Sun implémentait 100% de la norme de Sun, c'est qu'il en implémentait 110%.
ah, Sun implemente plus que la norme?
Voilà ce que c'est de ne pas se relire! Le problème c'est pas que le Java de Microsoft bien sûr.
--
Michel TALON
Ploc <ploc@clop.invalid> wrote:
Michel Talon wrote:
Remi THOMAS <remi@xtware.com> wrote:
Sinon la VM de Microsoft suivait ? 100% la norme Java, pour preuve un .java
compil? avec le JDK fonctionnait avec la VM de Microsoft.
Tu es vraîment une gourde toi. Le problème c'est pas que le Java de Sun
implémentait 100% de la norme de Sun, c'est qu'il en implémentait 110%.
ah, Sun implemente plus que la norme?
Voilà ce que c'est de ne pas se relire!
Le problème c'est pas que le Java de Microsoft
bien sûr.
Sinon la VM de Microsoft suivait ? 100% la norme Java, pour preuve un .java compil? avec le JDK fonctionnait avec la VM de Microsoft.
Tu es vraîment une gourde toi. Le problème c'est pas que le Java de Sun implémentait 100% de la norme de Sun, c'est qu'il en implémentait 110%.
ah, Sun implemente plus que la norme?
Voilà ce que c'est de ne pas se relire! Le problème c'est pas que le Java de Microsoft bien sûr.
--
Michel TALON
Remi THOMAS
Remi THOMAS wrote:
Sinon la VM de Microsoft suivait ? 100% la norme Java, pour preuve un .java compil? avec le JDK fonctionnait avec la VM de Microsoft.
Tu es vraîment une gourde toi. Le problème c'est pas que le Java de Sun implémentait 100% de la norme de Sun, c'est qu'il en implémentait 110%. Ce qui veut dire que, vu la connerie des développeurs Microsoft dont tu es un honorable représentant, la moitié des applications "Java" sur le marché auraient utilisé les 10% restants, et donc saboté l'interopérabilité qui était le but n°1 de l'introduction de Java. En d'autres termes le but de Java était de rendre le hardware et l'OS sans importance, le but de Microsoft était et est toujours d'obliger les gens à utiliser des machines Intel et des OS Microsoft. Voilà pourquoi J++ c'était mal, .NET c'est mal, C# c'est mal, etc. quoi qu'en disent les décérébrés comme Icaza.
M. Le Mal,
Cela ma toujours bien fait rire les personnes qui pensent qu'il faut développer le plus générique possible, histoire de capitaliser les développements pour changer de plateforme si.... Et la est la question, si quoi? Avec l'expérience on se rend compte que ces développements au final ne sont jamais portés sur une autre plate-forme car: - il faudrait refaire les tests de validation sur la nouvelle plate-forme, pas le temps, ca marche comme cela - quand je veux faire évoluer mon produit il est préférable de le réecrire car les développeurs d'origine sont devenus chef de projet, que personne n'a mis le nez dans le code depuis 2 ans, et surtout que des outils biens plus puissants permettent de faire la même chose plus vite et en mieux.
Maintenant la gourde te demande : est-ce que tu aurais utilisé les 10% supplémentaires de Microsoft sur ton Linux? Non, bon alors. Ces 10% étaient là pour permettre de faire le pont avec l'existant (les objets COM qui existent depuis 1995) et tirer parti des performances de Windows. Et oui désolé il existe Windows et les autres, que chacun choisi son monde et pensez que l'autre c'est le mal est légitime.
Après tu as des dévelopeurs (plutôt universitaire) qui viennent te voir avec leur application Java sur PocketPC et te demande comment rendre cela plus rapide. Je leur demande si c'est du Java "pur" ou si ils ont utilisés des bibliothèques spécifiques pour exploiter les particularités du PocketPC. Bien entendu ils exploitent les particularités du PocketPC. Alors je pose la question qui tue : pourquoi avoir choisi Java pour faire du spécifique? C++ existe depuis des années et permet de faire du portable aussi, mais ces moins lourd que Java. Si tu préféres développer 2 à 3 fois plus rapidement qu'en C++ sur Windows alors Microsoft t'offre .NET et C#, et oui c'est spécifique. Pour ceux que cela amuse CLI et C# sont portable, mais pas le framework, cela serait trop compliqué.
Et la concurrence est positive. Pour preuve Java essaye de suivre .NET depuis quelque temps. Est-ce que Java aurait évolué de la même façon sans Microsoft?
Encore aujourd'hui sur http://www.dotnetguru.org ".NET est décidément un formidable catalyseur pour Java. Durant cette semaine, Sun devrait annoncer lors de JavaOne une quantité impressionnante d'évolutions pour le moins inattendues de Swing à travers SwingLabs. Ce Framework graphique qu'on disait complexe et peu performant dispose désormais d'un Layout Manager "utilisable" en mode WYSIWG, sur le principe du Designer VS.NET. En sus du DataSet, Swing se dote d'un DataBinding similaire à Windows Forms (avec un concept de BindingContext) et proposera bientôt le fameux contrôle Calendar de VS sous l'appellation JDatePicker. La bataille s'annonce serrée. Tous les liens et détails dans la suite ..." Sur dotnetguru ils ne vont pas
Bien cordialement, La gourde Rémi
Remi THOMAS <remi@xtware.com> wrote:
Sinon la VM de Microsoft suivait ? 100% la norme Java, pour preuve un
.java
compil? avec le JDK fonctionnait avec la VM de Microsoft.
Tu es vraîment une gourde toi. Le problème c'est pas que le Java de Sun
implémentait 100% de la norme de Sun, c'est qu'il en implémentait 110%.
Ce qui veut dire que, vu la connerie des développeurs Microsoft dont tu es
un
honorable représentant, la moitié des applications "Java" sur le marché
auraient utilisé les 10% restants, et donc saboté l'interopérabilité qui
était
le but n°1 de l'introduction de Java. En d'autres termes le but de Java
était
de rendre le hardware et l'OS sans importance, le but de Microsoft était
et
est toujours d'obliger les gens à utiliser des machines Intel et des OS
Microsoft. Voilà pourquoi J++ c'était mal, .NET c'est mal, C# c'est mal,
etc.
quoi qu'en disent les décérébrés comme Icaza.
M. Le Mal,
Cela ma toujours bien fait rire les personnes qui pensent qu'il faut
développer le plus générique possible, histoire de capitaliser les
développements pour changer de plateforme si....
Et la est la question, si quoi?
Avec l'expérience on se rend compte que ces développements au final ne sont
jamais portés sur une autre plate-forme car:
- il faudrait refaire les tests de validation sur la nouvelle plate-forme,
pas le temps, ca marche comme cela
- quand je veux faire évoluer mon produit il est préférable de le réecrire
car les développeurs d'origine sont devenus chef de projet, que personne n'a
mis le nez dans le code depuis 2 ans, et surtout que des outils biens plus
puissants permettent de faire la même chose plus vite et en mieux.
Maintenant la gourde te demande : est-ce que tu aurais utilisé les 10%
supplémentaires de Microsoft sur ton Linux? Non, bon alors.
Ces 10% étaient là pour permettre de faire le pont avec l'existant (les
objets COM qui existent depuis 1995) et tirer parti des performances de
Windows.
Et oui désolé il existe Windows et les autres, que chacun choisi son monde
et pensez que l'autre c'est le mal est légitime.
Après tu as des dévelopeurs (plutôt universitaire) qui viennent te voir avec
leur application Java sur PocketPC et te demande comment rendre cela plus
rapide.
Je leur demande si c'est du Java "pur" ou si ils ont utilisés des
bibliothèques spécifiques pour exploiter les particularités du PocketPC.
Bien entendu ils exploitent les particularités du PocketPC. Alors je pose la
question qui tue : pourquoi avoir choisi Java pour faire du spécifique?
C++ existe depuis des années et permet de faire du portable aussi, mais ces
moins lourd que Java.
Si tu préféres développer 2 à 3 fois plus rapidement qu'en C++ sur Windows
alors Microsoft t'offre .NET et C#, et oui c'est spécifique. Pour ceux que
cela amuse CLI et C# sont portable, mais pas le framework, cela serait trop
compliqué.
Et la concurrence est positive. Pour preuve Java essaye de suivre .NET
depuis quelque temps. Est-ce que Java aurait évolué de la même façon sans
Microsoft?
Encore aujourd'hui sur http://www.dotnetguru.org
".NET est décidément un formidable catalyseur pour Java. Durant cette
semaine, Sun devrait annoncer lors de JavaOne une quantité impressionnante
d'évolutions pour le moins inattendues de Swing à travers SwingLabs. Ce
Framework graphique qu'on disait complexe et peu performant dispose
désormais d'un Layout Manager "utilisable" en mode WYSIWG, sur le principe
du Designer VS.NET. En sus du DataSet, Swing se dote d'un DataBinding
similaire à Windows Forms (avec un concept de BindingContext) et proposera
bientôt le fameux contrôle Calendar de VS sous l'appellation JDatePicker. La
bataille s'annonce serrée. Tous les liens et détails dans la suite ..."
Sur dotnetguru ils ne vont pas
Sinon la VM de Microsoft suivait ? 100% la norme Java, pour preuve un .java compil? avec le JDK fonctionnait avec la VM de Microsoft.
Tu es vraîment une gourde toi. Le problème c'est pas que le Java de Sun implémentait 100% de la norme de Sun, c'est qu'il en implémentait 110%. Ce qui veut dire que, vu la connerie des développeurs Microsoft dont tu es un honorable représentant, la moitié des applications "Java" sur le marché auraient utilisé les 10% restants, et donc saboté l'interopérabilité qui était le but n°1 de l'introduction de Java. En d'autres termes le but de Java était de rendre le hardware et l'OS sans importance, le but de Microsoft était et est toujours d'obliger les gens à utiliser des machines Intel et des OS Microsoft. Voilà pourquoi J++ c'était mal, .NET c'est mal, C# c'est mal, etc. quoi qu'en disent les décérébrés comme Icaza.
M. Le Mal,
Cela ma toujours bien fait rire les personnes qui pensent qu'il faut développer le plus générique possible, histoire de capitaliser les développements pour changer de plateforme si.... Et la est la question, si quoi? Avec l'expérience on se rend compte que ces développements au final ne sont jamais portés sur une autre plate-forme car: - il faudrait refaire les tests de validation sur la nouvelle plate-forme, pas le temps, ca marche comme cela - quand je veux faire évoluer mon produit il est préférable de le réecrire car les développeurs d'origine sont devenus chef de projet, que personne n'a mis le nez dans le code depuis 2 ans, et surtout que des outils biens plus puissants permettent de faire la même chose plus vite et en mieux.
Maintenant la gourde te demande : est-ce que tu aurais utilisé les 10% supplémentaires de Microsoft sur ton Linux? Non, bon alors. Ces 10% étaient là pour permettre de faire le pont avec l'existant (les objets COM qui existent depuis 1995) et tirer parti des performances de Windows. Et oui désolé il existe Windows et les autres, que chacun choisi son monde et pensez que l'autre c'est le mal est légitime.
Après tu as des dévelopeurs (plutôt universitaire) qui viennent te voir avec leur application Java sur PocketPC et te demande comment rendre cela plus rapide. Je leur demande si c'est du Java "pur" ou si ils ont utilisés des bibliothèques spécifiques pour exploiter les particularités du PocketPC. Bien entendu ils exploitent les particularités du PocketPC. Alors je pose la question qui tue : pourquoi avoir choisi Java pour faire du spécifique? C++ existe depuis des années et permet de faire du portable aussi, mais ces moins lourd que Java. Si tu préféres développer 2 à 3 fois plus rapidement qu'en C++ sur Windows alors Microsoft t'offre .NET et C#, et oui c'est spécifique. Pour ceux que cela amuse CLI et C# sont portable, mais pas le framework, cela serait trop compliqué.
Et la concurrence est positive. Pour preuve Java essaye de suivre .NET depuis quelque temps. Est-ce que Java aurait évolué de la même façon sans Microsoft?
Encore aujourd'hui sur http://www.dotnetguru.org ".NET est décidément un formidable catalyseur pour Java. Durant cette semaine, Sun devrait annoncer lors de JavaOne une quantité impressionnante d'évolutions pour le moins inattendues de Swing à travers SwingLabs. Ce Framework graphique qu'on disait complexe et peu performant dispose désormais d'un Layout Manager "utilisable" en mode WYSIWG, sur le principe du Designer VS.NET. En sus du DataSet, Swing se dote d'un DataBinding similaire à Windows Forms (avec un concept de BindingContext) et proposera bientôt le fameux contrôle Calendar de VS sous l'appellation JDatePicker. La bataille s'annonce serrée. Tous les liens et détails dans la suite ..." Sur dotnetguru ils ne vont pas
Bien cordialement, La gourde Rémi
Remi THOMAS
Sur dotnetguru ils ne vont pas J'ai oublié de supprimer cette ligne avant de poster.
Rémi
Sur dotnetguru ils ne vont pas
J'ai oublié de supprimer cette ligne avant de poster.
Sur dotnetguru ils ne vont pas J'ai oublié de supprimer cette ligne avant de poster.
Rémi
Manuel Leclerc
Pour ceux que cela amuse CLI et C# sont portable, mais pas le framework, cela serait trop compliqué.
Heu, Mono c'est quand même un sacré bout du framework, je crois.
-- Everyone agrees that Microsoft has big challenges ahead, but we're not talking about quantum physics here. It's software development and delivery. If Microsoft were allowed to pick its battles, this is one it would choose. --John Foley
Pour ceux que cela amuse CLI et C# sont portable, mais pas
le framework, cela serait trop compliqué.
Heu, Mono c'est quand même un sacré bout du framework, je crois.
--
Everyone agrees that Microsoft has big challenges ahead, but we're not
talking about quantum physics here. It's software development and
delivery. If Microsoft were allowed to pick its battles, this is one it
would choose. --John Foley
Pour ceux que cela amuse CLI et C# sont portable, mais pas le framework, cela serait trop compliqué.
Heu, Mono c'est quand même un sacré bout du framework, je crois.
-- Everyone agrees that Microsoft has big challenges ahead, but we're not talking about quantum physics here. It's software development and delivery. If Microsoft were allowed to pick its battles, this is one it would choose. --John Foley
Nicolas George
"Remi THOMAS" , dans le message <446da1b3$0$5154$, a écrit :
Cela ma toujours bien fait rire les personnes qui pensent qu'il faut développer le plus générique possible, histoire de capitaliser les développements pour changer de plateforme si.... <snip>
Le problème avec ton raisonnement, c'est qu'il est circulaire : ça ne sert à rien de développer du code générique parce que la migration coûte trop cher, mais pourquoi la migration coûte-t-elle cher ? Parce que le code n'était pas générique au départ.
Bel exemple de rhétorique sophistique d'une société qui ne survit depuis vingt ans et plus que par l'enfermement de ses clients.
"Remi THOMAS" , dans le message <446da1b3$0$5154$626a54ce@news.free.fr>,
a écrit :
Cela ma toujours bien fait rire les personnes qui pensent qu'il faut
développer le plus générique possible, histoire de capitaliser les
développements pour changer de plateforme si....
<snip>
Le problème avec ton raisonnement, c'est qu'il est circulaire : ça ne sert à
rien de développer du code générique parce que la migration coûte trop cher,
mais pourquoi la migration coûte-t-elle cher ? Parce que le code n'était pas
générique au départ.
Bel exemple de rhétorique sophistique d'une société qui ne survit depuis
vingt ans et plus que par l'enfermement de ses clients.
"Remi THOMAS" , dans le message <446da1b3$0$5154$, a écrit :
Cela ma toujours bien fait rire les personnes qui pensent qu'il faut développer le plus générique possible, histoire de capitaliser les développements pour changer de plateforme si.... <snip>
Le problème avec ton raisonnement, c'est qu'il est circulaire : ça ne sert à rien de développer du code générique parce que la migration coûte trop cher, mais pourquoi la migration coûte-t-elle cher ? Parce que le code n'était pas générique au départ.
Bel exemple de rhétorique sophistique d'une société qui ne survit depuis vingt ans et plus que par l'enfermement de ses clients.
