je sors agréablement surpris d'une semaine de formation sur .NET en
environnement M$.
J'y ai découvert la programmation en C++.NET (je développe en C/C++
traditionnel sur Mac au boulot et je bidouille sous GNU/Linux à la
maison).
Déjà voir que .NET faisait usage d'un compilo JIT m'a un peu fait revoir
mon appréciation négative sur .NET que je considérais (mal) comme Java
avec son code interprété.
Ensuite la surprise vient que le formateur (qui ne pratique pas Linux) a
su m'indiquer qu'il existait une implémentation pour Linux. Deux en fait
après avoir creusé le sujet : Mono (sponsorisé par Ximian/Novell) et
dotGNU.
Et l'agréable vient qu'après avoir bataillé avec des paquetages un peu
expérimentaux (tout n'est pas encore finalisé) j'ai pu voir que mes
programmes de test fonctionnaient directement sous Linux _et_ sous Win
avec le même exécutable (qui d'ailleurs est aussi un .exe sous Linux).
Tiens d'ailleurs pour ajouter à la surprise, le VB.NET est aussi en
cours de portage, ça fait un peu bizarre :)
Sinon on peut pour le moment partager du C# et de l'assembleur IL en
plus de VB (je pense que d'autres suivront mais je n'ai pas vu de c++)
et l'IDE que j'ai testé (MonoDevelop) bien qu'en v0.5 a l'air pas mal.
J'aime bien la complétion intelligente à la Visual Studio (qui àma est
la seule application vraiment valable chez M$ ;).
D'autres ont-il aussi testé .NET en cross-plateforme et qu'en
pensent-ils ?
Crosspost & Suivi prudent vers fr.comp.os.linux.debats
--
Sébastien Kirche
On Sun, 29 May 2005 17:42:40 +0000, Irvin Probst wrote:
On 2005-05-29, Emmanuel Florac wrote:
Aujourd'hui ils ont avoué qu'ils étaient infoutus d'implémneter Longhorn en .NET (Longhorn ressemble de plus en plus à winXP SP3...)
Oui et c'est bien dommage, j'attendais beaucoup de Longhorn. Pour une fois on avait l'impression qu'ils voulaient faire un OS avec les technologies actuelles et pas celles d'il y a dix ans. Tant pis. Et puis de toute manière je suis sous OS X maintenant, l'OS morderne je l'ai déjà :)
Oui, mais basé sur les technologies d'il y a 15 ans ;-)
(c'est toujours plus à jours que Linux, qui serait plutôt basé sur les dernières découvertes d'il y a 35 ans !)
On Sun, 29 May 2005 17:42:40 +0000, Irvin Probst wrote:
On 2005-05-29, Emmanuel Florac <eflorac@imaginet.fr> wrote:
Aujourd'hui ils ont avoué qu'ils étaient infoutus d'implémneter
Longhorn en .NET (Longhorn ressemble de plus en plus à winXP SP3...)
Oui et c'est bien dommage, j'attendais beaucoup de Longhorn. Pour une
fois on avait l'impression qu'ils voulaient faire un OS avec les
technologies actuelles et pas celles d'il y a dix ans. Tant pis.
Et puis de toute manière je suis sous OS X maintenant, l'OS morderne je
l'ai déjà :)
Oui, mais basé sur les technologies d'il y a 15 ans ;-)
(c'est toujours plus à jours que Linux, qui serait plutôt basé sur les
dernières découvertes d'il y a 35 ans !)
On Sun, 29 May 2005 17:42:40 +0000, Irvin Probst wrote:
On 2005-05-29, Emmanuel Florac wrote:
Aujourd'hui ils ont avoué qu'ils étaient infoutus d'implémneter Longhorn en .NET (Longhorn ressemble de plus en plus à winXP SP3...)
Oui et c'est bien dommage, j'attendais beaucoup de Longhorn. Pour une fois on avait l'impression qu'ils voulaient faire un OS avec les technologies actuelles et pas celles d'il y a dix ans. Tant pis. Et puis de toute manière je suis sous OS X maintenant, l'OS morderne je l'ai déjà :)
Oui, mais basé sur les technologies d'il y a 15 ans ;-)
(c'est toujours plus à jours que Linux, qui serait plutôt basé sur les dernières découvertes d'il y a 35 ans !)
Emmanuel Florac
Le Sun, 29 May 2005 17:32:15 +0000, JKB a écrit :
Très sérieusement, le GOTO possède bien des avantages pour alléger le code (et n'est pas pire qu'un break ou un continue en C).
Oui mais seulement pour un programmeur très rigoureux qui saura l'utiliser uniquement à bon escient.
-- Ne pas savoir de quoi on parle est un avantage dont il ne faut pas abuser. R.Debray
Le Sun, 29 May 2005 17:32:15 +0000, JKB a écrit :
Très sérieusement, le GOTO possède bien des avantages pour alléger
le code (et n'est pas pire qu'un break ou un continue en C).
Oui mais seulement pour un programmeur très rigoureux qui saura
l'utiliser uniquement à bon escient.
--
Ne pas savoir de quoi on parle est un avantage dont il ne faut pas
abuser.
R.Debray
Pour une fois on avait l'impression qu'ils voulaient faire un OS avec les technologies actuelles et pas celles d'il y a dix ans.
Si ils veulent garder des choses "compatible windows", ils sont limités coté innovation...
Parles en à Apple. Ils sont passés du Motorola 680x0 (dit 68k) au PPC radicalement incompatible, puis d'un système très ergonomique mais ayant des bases horribles (ceux qui ont programmé sous MacOS 9 et avant savent) à un système Unix dérivé de NeXT step.
Techniquement un programme correctement programmé sous System 6 (donc 68k) peut fonctionner sous Tiger (10.4) (forcément PPC G3).
Et je ne pense pas qu'Apple ai un jour cessé d'innover depuis 1978 (Apple I puis II, Macintosh, Newton, iPod, MacOS X, etc.)
Régis
-- Beuvez beuvez, mais bourré jamais
Le Sun, 29 May 2005 20:53:08 +0200, Rakotomandimby (R12y) Mihamina a
écrit :
Pour une fois
on avait l'impression qu'ils voulaient faire un OS avec les technologies
actuelles et pas celles d'il y a dix ans.
Si ils veulent garder des choses "compatible windows", ils sont limités
coté innovation...
Parles en à Apple. Ils sont passés du Motorola 680x0 (dit 68k) au PPC
radicalement incompatible, puis d'un système très ergonomique mais ayant
des bases horribles (ceux qui ont programmé sous MacOS 9 et avant savent)
à un système Unix dérivé de NeXT step.
Techniquement un programme correctement programmé sous System 6 (donc
68k) peut fonctionner sous Tiger (10.4) (forcément PPC G3).
Et je ne pense pas qu'Apple ai un jour cessé d'innover depuis 1978 (Apple
I puis II, Macintosh, Newton, iPod, MacOS X, etc.)
Pour une fois on avait l'impression qu'ils voulaient faire un OS avec les technologies actuelles et pas celles d'il y a dix ans.
Si ils veulent garder des choses "compatible windows", ils sont limités coté innovation...
Parles en à Apple. Ils sont passés du Motorola 680x0 (dit 68k) au PPC radicalement incompatible, puis d'un système très ergonomique mais ayant des bases horribles (ceux qui ont programmé sous MacOS 9 et avant savent) à un système Unix dérivé de NeXT step.
Techniquement un programme correctement programmé sous System 6 (donc 68k) peut fonctionner sous Tiger (10.4) (forcément PPC G3).
Et je ne pense pas qu'Apple ai un jour cessé d'innover depuis 1978 (Apple I puis II, Macintosh, Newton, iPod, MacOS X, etc.)
Régis
-- Beuvez beuvez, mais bourré jamais
Sam Hocevar
On Sat, 28 May 2005 13:46:09 +0000 (UTC), Michel Talon wrote:
Je ne comprends pas. Comment font-ils pour discréditer les autres tout en se faisant ridiculiser par la JVM d'IBM ?
Je parle des machines virtuelles "libres". Tu me montreras le benchmark où la machine virtuelle IBM ridiculise celle de Sun depuis la jdk-1.4 ou 1.5.
Par exemple SPEC JVM98 (http://www.spec.org/osg/jvm98/) sur http://www.shudo.net/jit/perf/SPECJVM98-P4.png ou le crible d'Ératosthène sur http://www.shudo.net/jit/perf/Sieve-P4.png .
Sam. -- Sam Hocevar <http://sam.zoy.org/> Software should be free -- http://www.debian.org/ Media access should be free -- http://www.videolan.org/ Knowledge must be free -- http://www.wikipedia.org/
On Sat, 28 May 2005 13:46:09 +0000 (UTC), Michel Talon wrote:
Je ne comprends pas. Comment font-ils pour discréditer les autres
tout en se faisant ridiculiser par la JVM d'IBM ?
Je parle des machines virtuelles "libres". Tu me montreras le benchmark où
la machine virtuelle IBM ridiculise celle de Sun depuis la jdk-1.4 ou 1.5.
Par exemple SPEC JVM98 (http://www.spec.org/osg/jvm98/) sur
http://www.shudo.net/jit/perf/SPECJVM98-P4.png ou le crible
d'Ératosthène sur http://www.shudo.net/jit/perf/Sieve-P4.png .
Sam.
--
Sam Hocevar <sam@zoy.org> <http://sam.zoy.org/>
Software should be free -- http://www.debian.org/
Media access should be free -- http://www.videolan.org/
Knowledge must be free -- http://www.wikipedia.org/
On Sat, 28 May 2005 13:46:09 +0000 (UTC), Michel Talon wrote:
Je ne comprends pas. Comment font-ils pour discréditer les autres tout en se faisant ridiculiser par la JVM d'IBM ?
Je parle des machines virtuelles "libres". Tu me montreras le benchmark où la machine virtuelle IBM ridiculise celle de Sun depuis la jdk-1.4 ou 1.5.
Par exemple SPEC JVM98 (http://www.spec.org/osg/jvm98/) sur http://www.shudo.net/jit/perf/SPECJVM98-P4.png ou le crible d'Ératosthène sur http://www.shudo.net/jit/perf/Sieve-P4.png .
Sam. -- Sam Hocevar <http://sam.zoy.org/> Software should be free -- http://www.debian.org/ Media access should be free -- http://www.videolan.org/ Knowledge must be free -- http://www.wikipedia.org/
talon
Sam Hocevar <sam+ wrote: a jdk-1.4 ou 1.5.
Par exemple SPEC JVM98 (http://www.spec.org/osg/jvm98/) sur http://www.shudo.net/jit/perf/SPECJVM98-P4.png ou le crible d'Ératosthène sur http://www.shudo.net/jit/perf/Sieve-P4.png .
Sam.
www.shudo.net je l'ai cité moi même et tu as des benchs qui montrent la VM de Sun meilleure que celle de IBM et d'autres ou c'est le contraire. Dans tous les cas il ne s'agit pas d'écarts qui justifient le terme "ridiculiser". Ce sont deux VM à peu prés au même niveau de performance. L'intérêt de celle de Sun est que le code source est disponible, et a été porté au moins sur FreeBSD, pour IBM je n'en sais rien, mais je ne crois pas qu'il y ait le même genre de ports. Donc je n'ai aucune raison de m'y intéresser plus.
--
Michel TALON
Sam Hocevar <sam+news@zoy.org> wrote:
a jdk-1.4 ou 1.5.
Par exemple SPEC JVM98 (http://www.spec.org/osg/jvm98/) sur
http://www.shudo.net/jit/perf/SPECJVM98-P4.png ou le crible
d'Ératosthène sur http://www.shudo.net/jit/perf/Sieve-P4.png .
Sam.
www.shudo.net je l'ai cité moi même et tu as des benchs qui montrent
la VM de Sun meilleure que celle de IBM et d'autres ou c'est le contraire.
Dans tous les cas il ne s'agit pas d'écarts qui justifient le terme
"ridiculiser". Ce sont deux VM à peu prés au même niveau de performance.
L'intérêt de celle de Sun est que le code source est disponible, et a été
porté au moins sur FreeBSD, pour IBM je n'en sais rien, mais je ne crois pas
qu'il y ait le même genre de ports. Donc je n'ai aucune raison de m'y
intéresser plus.
Par exemple SPEC JVM98 (http://www.spec.org/osg/jvm98/) sur http://www.shudo.net/jit/perf/SPECJVM98-P4.png ou le crible d'Ératosthène sur http://www.shudo.net/jit/perf/Sieve-P4.png .
Sam.
www.shudo.net je l'ai cité moi même et tu as des benchs qui montrent la VM de Sun meilleure que celle de IBM et d'autres ou c'est le contraire. Dans tous les cas il ne s'agit pas d'écarts qui justifient le terme "ridiculiser". Ce sont deux VM à peu prés au même niveau de performance. L'intérêt de celle de Sun est que le code source est disponible, et a été porté au moins sur FreeBSD, pour IBM je n'en sais rien, mais je ne crois pas qu'il y ait le même genre de ports. Donc je n'ai aucune raison de m'y intéresser plus.
--
Michel TALON
Remi Thomas
"Richard Delorme" écrivit
doit en conclure que python est mieux que .net et java réunis ?
Il manque encore pas mal de choses a Python, principalement concernant le typage et le declaratif obligatoire.
Non. Python utilise le typage dynamique qui est, à mon avis, une notion plus avancée que le typage statique à déclaration obligatoire.
VB6 utilise le typage dynamique, ce qui pose pas mal de problème à la longue. Le typage statique à déclaration est maintenant la norme dans .NET et donc dans VB.NET.
Rémi
"Richard Delorme" écrivit
doit en conclure que python est mieux que .net et java réunis ?
Il manque encore pas mal de choses a Python, principalement concernant
le typage et le declaratif obligatoire.
Non. Python utilise le typage dynamique qui est, à mon avis, une notion
plus avancée que le typage statique à déclaration obligatoire.
VB6 utilise le typage dynamique, ce qui pose pas mal de problème à la
longue.
Le typage statique à déclaration est maintenant la norme dans .NET et donc
dans VB.NET.
doit en conclure que python est mieux que .net et java réunis ?
Il manque encore pas mal de choses a Python, principalement concernant le typage et le declaratif obligatoire.
Non. Python utilise le typage dynamique qui est, à mon avis, une notion plus avancée que le typage statique à déclaration obligatoire.
VB6 utilise le typage dynamique, ce qui pose pas mal de problème à la longue. Le typage statique à déclaration est maintenant la norme dans .NET et donc dans VB.NET.
Rémi
Remi Thomas
"Michel Talon" écrivit
Sauf que là n'importe qui peut faire son Common Language Runtime, la jvm de .NET. Et c'est normalisé.
Je te signale que n'importe qui peut développer une JVM pour Java, d'ailleurs les gens ne s'en sont pas privés. Dommage que les gens de Sun aient fait une JVM suffisamment meilleure pour discréditer les autres.
Cela n'a pas toujours était le cas. Avant le procès Microsoft-Sun la meilleur JVM sur Windows était celle de Microsoft. Ceci plus l'ouverture de cette JVM au modèle objet de Windows (COM) à produit le procès. Sans ceci C# n'aurait jamais existé, Java était initiallement prévu.
Rémi
"Michel Talon" écrivit
Sauf que là n'importe qui peut faire son Common Language Runtime, la jvm
de .NET. Et c'est normalisé.
Je te signale que n'importe qui peut développer une JVM pour Java,
d'ailleurs les gens ne s'en sont pas privés. Dommage que les gens de Sun
aient fait une JVM suffisamment meilleure pour discréditer les autres.
Cela n'a pas toujours était le cas. Avant le procès Microsoft-Sun la
meilleur JVM sur Windows était celle de Microsoft. Ceci plus l'ouverture de
cette JVM au modèle objet de Windows (COM) à produit le procès. Sans ceci C#
n'aurait jamais existé, Java était initiallement prévu.
Sauf que là n'importe qui peut faire son Common Language Runtime, la jvm de .NET. Et c'est normalisé.
Je te signale que n'importe qui peut développer une JVM pour Java, d'ailleurs les gens ne s'en sont pas privés. Dommage que les gens de Sun aient fait une JVM suffisamment meilleure pour discréditer les autres.
Cela n'a pas toujours était le cas. Avant le procès Microsoft-Sun la meilleur JVM sur Windows était celle de Microsoft. Ceci plus l'ouverture de cette JVM au modèle objet de Windows (COM) à produit le procès. Sans ceci C# n'aurait jamais existé, Java était initiallement prévu.
Rémi
Richard Delorme
"Richard Delorme" écrivit
doit en conclure que python est mieux que .net et java réunis ?
Il manque encore pas mal de choses a Python, principalement concernant le typage et le declaratif obligatoire.
Non. Python utilise le typage dynamique qui est, à mon avis, une notion plus avancée que le typage statique à déclaration obligatoire.
VB6 utilise le typage dynamique, ce qui pose pas mal de problème à la longue. Le typage statique à déclaration est maintenant la norme dans .NET et donc dans VB.NET.
Pas vraiment. Si je ne m'abuse, tout est objet et dérive du type Object, ce qui permet de maintenir un typage dynamique, avec tous ses défauts et une certaine lourdeur. En outre une nouvelle syntaxe ("Of ...") a été ajouté pour obtenir une généricité plus propre, là aussi au prix d'une certaine lourdeur syntaxique. Le typage dynamique permet la généricité sans sa lourdeur syntaxique, le prix à payer étant une relative baisse de performance.
-- Richard
"Richard Delorme" écrivit
doit en conclure que python est mieux que .net et java réunis ?
Il manque encore pas mal de choses a Python, principalement concernant
le typage et le declaratif obligatoire.
Non. Python utilise le typage dynamique qui est, à mon avis, une notion
plus avancée que le typage statique à déclaration obligatoire.
VB6 utilise le typage dynamique, ce qui pose pas mal de problème à la
longue.
Le typage statique à déclaration est maintenant la norme dans .NET et donc
dans VB.NET.
Pas vraiment. Si je ne m'abuse, tout est objet et dérive du type Object,
ce qui permet de maintenir un typage dynamique, avec tous ses défauts et
une certaine lourdeur. En outre une nouvelle syntaxe ("Of ...") a été
ajouté pour obtenir une généricité plus propre, là aussi au prix d'une
certaine lourdeur syntaxique. Le typage dynamique permet la généricité
sans sa lourdeur syntaxique, le prix à payer étant une relative baisse
de performance.
doit en conclure que python est mieux que .net et java réunis ?
Il manque encore pas mal de choses a Python, principalement concernant le typage et le declaratif obligatoire.
Non. Python utilise le typage dynamique qui est, à mon avis, une notion plus avancée que le typage statique à déclaration obligatoire.
VB6 utilise le typage dynamique, ce qui pose pas mal de problème à la longue. Le typage statique à déclaration est maintenant la norme dans .NET et donc dans VB.NET.
Pas vraiment. Si je ne m'abuse, tout est objet et dérive du type Object, ce qui permet de maintenir un typage dynamique, avec tous ses défauts et une certaine lourdeur. En outre une nouvelle syntaxe ("Of ...") a été ajouté pour obtenir une généricité plus propre, là aussi au prix d'une certaine lourdeur syntaxique. Le typage dynamique permet la généricité sans sa lourdeur syntaxique, le prix à payer étant une relative baisse de performance.
-- Richard
Antonio Bravo
On Tue, 31 May 2005 09:08:30 +0200, Remi Thomas wrote:
Cela n'a pas toujours était le cas. Avant le procès Microsoft-Sun la meilleur JVM sur Windows était celle de Microsoft. Ceci plus l'ouverture de cette JVM au modèle objet de Windows (COM) à produit le procès. Sans ceci C# n'aurait jamais existé, Java était initiallement prévu.
CQFD. Il y a de plus dans le set de CDROMs Visual Studio Net Enterprise, le 7eme je crois qui contient J#. Toute une maitrise de la typographie chez MS: il y avait Visual C++ et Visual J++ (c'est "visual", sinon on ne saurait voir), proces, puis maintenant Visual C# et Visual J#. Ah ces creatifs du milieu de la pub, tout de meme!
-- "Men alt dette er ikke begyndelsen.", Knut HAMSUN,"Mysterier"- 1892 ____________________GPG/PGP key ID:0x24ADF724______________________
On Tue, 31 May 2005 09:08:30 +0200, Remi Thomas wrote:
Cela n'a pas toujours était le cas. Avant le procès Microsoft-Sun la
meilleur JVM sur Windows était celle de Microsoft. Ceci plus l'ouverture de
cette JVM au modèle objet de Windows (COM) à produit le procès. Sans ceci C#
n'aurait jamais existé, Java était initiallement prévu.
CQFD.
Il y a de plus dans le set de CDROMs Visual Studio Net Enterprise, le 7eme
je crois qui contient J#.
Toute une maitrise de la typographie chez MS: il y avait Visual C++ et
Visual J++ (c'est "visual", sinon on ne saurait voir), proces, puis
maintenant Visual C# et Visual J#.
Ah ces creatifs du milieu de la pub, tout de meme!
--
"Men alt dette er ikke begyndelsen.", Knut
HAMSUN,"Mysterier"- 1892
____________________GPG/PGP key ID:0x24ADF724______________________
On Tue, 31 May 2005 09:08:30 +0200, Remi Thomas wrote:
Cela n'a pas toujours était le cas. Avant le procès Microsoft-Sun la meilleur JVM sur Windows était celle de Microsoft. Ceci plus l'ouverture de cette JVM au modèle objet de Windows (COM) à produit le procès. Sans ceci C# n'aurait jamais existé, Java était initiallement prévu.
CQFD. Il y a de plus dans le set de CDROMs Visual Studio Net Enterprise, le 7eme je crois qui contient J#. Toute une maitrise de la typographie chez MS: il y avait Visual C++ et Visual J++ (c'est "visual", sinon on ne saurait voir), proces, puis maintenant Visual C# et Visual J#. Ah ces creatifs du milieu de la pub, tout de meme!
-- "Men alt dette er ikke begyndelsen.", Knut HAMSUN,"Mysterier"- 1892 ____________________GPG/PGP key ID:0x24ADF724______________________
talon
Remi Thomas wrote:
Cela n'a pas toujours était le cas. Avant le procès Microsoft-Sun la meilleur JVM sur Windows était celle de Microsoft.
Je veux bien le croire, mais à cette époque la JVM de Sun n'avait pas HotSpot, et c'est ça qui fait une grosse différence (IBM ayant bien entendu un compilateur JIT similaire).
Ceci plus l'ouverture de cette JVM au modèle objet de Windows (COM) à produit le procès. Sans ceci C# n'aurait jamais existé, Java était initiallement prévu.
C'est bien ce que je pense. Pour de bonnes ou de mauvaises raisons Microsoft voulait faire un Java# similaire mais différent de Java, et ne pouvant aller au plus direct, ils ont pris la voie détournée. D'un autre coté Sun sait que le plus grand avantage, pour ne pas dire le seul, de Java est dans son interopérabilité, donc doit défendre la "pureté de la norme" coute que coute.
Rémi
--
Michel TALON
Remi Thomas <remi@xtware.com> wrote:
Cela n'a pas toujours était le cas. Avant le procès Microsoft-Sun la
meilleur JVM sur Windows était celle de Microsoft.
Je veux bien le croire, mais à cette époque la JVM de Sun n'avait pas
HotSpot, et c'est ça qui fait une grosse différence (IBM ayant bien
entendu un compilateur JIT similaire).
Ceci plus l'ouverture de
cette JVM au modèle objet de Windows (COM) à produit le procès. Sans ceci C#
n'aurait jamais existé, Java était initiallement prévu.
C'est bien ce que je pense. Pour de bonnes ou de mauvaises raisons Microsoft
voulait faire un Java# similaire mais différent de Java, et ne pouvant
aller au plus direct, ils ont pris la voie détournée. D'un autre coté Sun
sait que le plus grand avantage, pour ne pas dire le seul, de Java est
dans son interopérabilité, donc doit défendre la "pureté de la norme" coute
que coute.
Cela n'a pas toujours était le cas. Avant le procès Microsoft-Sun la meilleur JVM sur Windows était celle de Microsoft.
Je veux bien le croire, mais à cette époque la JVM de Sun n'avait pas HotSpot, et c'est ça qui fait une grosse différence (IBM ayant bien entendu un compilateur JIT similaire).
Ceci plus l'ouverture de cette JVM au modèle objet de Windows (COM) à produit le procès. Sans ceci C# n'aurait jamais existé, Java était initiallement prévu.
C'est bien ce que je pense. Pour de bonnes ou de mauvaises raisons Microsoft voulait faire un Java# similaire mais différent de Java, et ne pouvant aller au plus direct, ils ont pris la voie détournée. D'un autre coté Sun sait que le plus grand avantage, pour ne pas dire le seul, de Java est dans son interopérabilité, donc doit défendre la "pureté de la norme" coute que coute.
