Fabien LE LEZ a écrit :
>>Je crois que c'est réussi.
>> N'est-ce pas un peu tôt pour le dire, alors que .Net n'en est qu'à ses
> premiers balbutiements ?

Tu as coupé un peu trop tôt:
"MS avait besoin d'offrir une nouvelle impulsion au développement sous
Windows, et de rester celui qui mène la dance. Je crois que c'est réussi."

Je pense qu'à ce niveau c'est plutôt réussi. .Net a quasiment fait
disparaître Win32 de la "place médiatique". Borland et d'autres ont très
bien suivi. Y'a pas mal d'exitation autour de Longhorn et .Net 2.0. .Net
s'est aussi très bien implantée sur le développement mobile (où
portabilité a cette fois réellement un sens).
Je voulais juste dire que son lancement me parraît réussi. Après, juger
que c'est une résussite technique, c'est autre chose. En fait, c'est
presque secondaire...

On Tue, 17 Jan 2006 13:01:29 +0100, "azert" <aze>:

>L'autre jour, j'ai vu une annonce qui demandait un développeur "avec au
>moins 5 ans d'expérience en .NET/C#". Ca rique aussi d'être dur à
>trouver ... :-))

Un ancien programmeur de chez Microsoft, qui a connu les premiers
développements .Net, peut-être ?

On Tue, 17 Jan 2006 13:32:20 +0100, Aurelien Regat-Barrel
<nospam.aregatba>:

>Je voulais juste dire que son lancement me parraît réussi.

Le battage médiatique de lancement, oui. .Net a eu autant de presse
que n'importe quel nouveau gadget.
Mais s'il s'agit de "rester celui qui mène la dance", il va falloir
que ça dure. Et ça, on ne peut guère le prévoir, puisqu'on en est au
tout début.

On Tue, 17 Jan 2006 13:26:54 +0100, "SerGioGio" <nospam>:

>Effectivement, il fallait proposer une alternative à Java, et ils ont
>mélangé toutes leurs idées et technologies ensemble, pour nous sortir du
>.Net.

Je pense que tu as mis le doigt dessus : le service marketing de
Microsoft a créé un concept abstrait[*], voire uniquement un nom, puis
a forcé les développeurs à balancer le plus possible de machins
là-dedans.
[*] Cf <http://www.joelonsoftware.com/articles/fog0000000049.html>,
daté du 22 juillet 2000.

SerGioGio a écrit :
> L' interface est "C" certes, pour permettre à un maximum de languages de
> pouvoir l'utiliser.
> Mais les concepts derrière COM par exemple sont tout ce qu'il y a de plus
> modernes...

Tout à fait. Beaucoup de technos tiennent la route conceptuellement.
Mais pour COM toujours, sa mise en oeuvre est laborieuse, vraiment. Les
méta-infos dans un fichier idl/tlb, le downcasting dynamique
(QueryInterface) qui n'est pas celui du langage (si ce dernier le
supporte), la gestion manuelle de la durée de vie des objets, le
marshaling, l'utilisation de VARIANT, l'introspection, etc...
Toutes ces contraintes techniques sont élégament résolues par .Net,
grâce à l'assistance du framework à tous ces niveaux.
COM est un standard binaire que les langages doivent supporter. En .Net,
c'est natif, ils sont compatibles à la base.

> Je suis peut être le seul à le penser, mais je continue d'être bluffé par
> COM, et je suis déçu que Microsoft soit passé à .Net.
> J'ai été élevé au Windows, donc je ne suis sans doute pas objectif. Je
> trouve que les concepts derrière COM étaient tout bonnement (encore)
> révolutionnaires (surtout à grande échelle dans un OS) et ils sont loin
> d'avoir été exploités comme ils le méritent. Je trouve que Microsoft a eu
> beaucoup d'audace d' intégrer une telle technologie.
> Qu'est ce qu'on nous propose maintenant? Avec dot net: une usine à gaz, avec
> nouveaux languages, nouveaux dialectes, une machine virtuelle (pas installée
> sur toutes les machines), etc. Et on va vivre dessus pendant des années...
> (très sincèrement: quel intérêt d'une machine virtuelle, pour exécuter une
> application sur Windows???)

Je suis assez d'accord. Je suis aussi très attaché à mes habitudes
chèrement acquises. Conceptuellement je trouve .Net très intéressant,
mais dans la pratique, je suis plus nuancé. .Net corrige pas mal des
gros problèmes du développement natif/Win32, et c'est vraiment +
agréable et + simple. Mais c'est aussi + limité : on efface pas comme ça
20 ans d'évolution.

> Ce que Microsoft aurait dû faire je pense, c'est simplifier la façon
> d'écrire des composants COM, pour C++, pour C, et autres.

C'est ce qu'ils ont fait depuis longtemps. MFC/ATL, les assistants de
VC++, la directive #import, ... Et en VB c'est le langage roi en matière
de programmation COM. Automatiser Excel est un jeu d'enfant.
Mais tout ça ce sont des pansements qui viennent se coler au dessus de
Win32. En .Net y'a plus rien à panser. Maintenant, si le pansement te
convenait parfaitement, alors tu n'en voit pas l'utilité. Mais pour les
petits nouveaux à former, c'est quand même 2 belles étapes de gagner
(apprendre les problèmes, apprendre à les résoudres).

> Aujourd'hui...
> combien de languages vont pouvoir se permettre le passage à .Net...? C++ a
> été dialectisé: en avait t'on vraiment besoin??
> Bien sûr, COM ne disparait pas avec .Net, mais il va être marginalisé,
> puisque les gens vont écrire du .Net plutôt que du COM.

Pour le C++, je trouve que MS a bien joué. Managed C++, techniquement
parlant, c'est un truc assez bluffant. Dans un environnement managé, tu
compiles et appelles du code natif sans te poser de questions, le
compilo gère tout en arrière plan. Par rapport à Java/JNI c'est vraiment
super.
Mais c'est pas parfait pout autant. La syntaxe est immonde. Managed C++
était juste là pour faciliter la migration de projets C++ natifs
existants vers .Net : c'est mieux que de tout recoder.
Maintenant on a C++/CLI, qui a plus d'ambition : être un langage à part
entière, capable de rivaliser avec C#. Là, pour le coup, je sais pas
trop ce que ça va donner.

>>Je crois que c'est beaucoup plus simple. MS avait besoin d'offrir une
>>nouvelle impulsion au développement sous Windows, et de rester celui qui
>>mène la dance. Je crois que c'est réussi.
>> Effectivement, il fallait proposer une alternative à Java, et ils ont
> mélangé toutes leurs idées et technologies ensemble, pour nous sortir du
> ..Net.

Win32 est une API objet utilisée essentiellement via des langages de
programmation objet. Paradoxe dans tout ça : l'interface qui les
connecte est en C. Ca se défend parfaitement, mais c'est un fait. Cette
interface C native est pour le programmeur moyen plus une gêne qu'autre
chose. Quand tu y penses, c'est allucinant de ne pas pouvoir utiliser
dans un langage X un composant développé en un autre. Et même dans un
même langage comme C++, une dll VC++ ne peut pas être utilisée avec g++
(tu vois l'idée de ma remarque).

Donc le mélange et l'uniformisation ne me choque pas. Personnellement,
je trouve même que c'est la grande force de .Net.
Sauf que c'est encore un monde parallèle, un peu en marge. En ce qui
nous concerne, ça revient à jouer les colons.
Personnelement j'ai plutôt envie qu'elle s'impose toute seule (ou que
Microsoft s'en charge), plutôt que de me battre à justifier pourquoi il
faut installer le framework pour utiliser mon appli.

Aurelien Regat-Barrel <nospam.aregatba> writes:

> Maintenant on a C++/CLI, qui a plus d'ambition : être un langage à part
> entière, capable de rivaliser avec C#. Là, pour le coup, je sais pas trop
> ce que ça va donner.

Je doute que C++/CLI soit capable de rivaliser avec C#. Il a
exactement la meme utilite: servir d'interface entre du C++ et du
..NET. A mon sens, il manque quelque chose d'important a C++/CLI pour
en faire un langage a succes: de l'homogeneite dans les concepts
utilises. Il melange les concepts de C++ et ceux de CLI. Il va
continuer a etre tiraille entre les deux.

On Tue, 17 Jan 2006 14:36:41 +0100, Aurelien Regat-Barrel
<nospam.aregatba>:

>COM est un standard binaire que les langages doivent supporter. En .Net,
> c'est natif, ils sont compatibles à la base.

Si j'ai tout bien compris, ce n'est pas exactement ça.

COM est une technologie utilisable en C++ ; les versions Windows des
compilateurs C++ doivent se démerder pour respecter cette
spécification.

Point Net est une technologie qui définit de nouveaux langages, avec
un "C++/CLI" basé sur C++ comme C++ est basé sur C.

On 17 Jan 2006 14:46:53 +0100, Jean-Marc Bourguet <jm>:

>Je doute que C++/CLI soit capable de rivaliser avec C#. Il a
>exactement la meme utilite: servir d'interface entre du C++ et du
>.NET.

Gageons que quelqu'un arrivera à faire une bibliothèque propre pour
utiliser Point Net avec un compilateur C++.

Fabien LE LEZ <gramster> writes:

> On 17 Jan 2006 14:46:53 +0100, Jean-Marc Bourguet <jm>:
> >Je doute que C++/CLI soit capable de rivaliser avec C#. Il a
> >exactement la meme utilite: servir d'interface entre du C++ et du
> >.NET.
> Gageons que quelqu'un arrivera à faire une bibliothèque propre pour
> utiliser Point Net avec un compilateur C++.

J'ai des doutes. Le modele objet est different entre CLI et C++.

Par exemple dans un constructeur CLI, l'appel a un membre virtuel doit
se resoudre a l'appel du membre de la classe la plus derivee, pas en
C++.

J'ai moins regarde le modele de genericite, mais il est possible qu'il
soit aussi inreconciliable que le modele objet.

A+

Jean-Marc Bourguet a écrit :
> Je doute que C++/CLI soit capable de rivaliser avec C#. Il a
> exactement la meme utilite: servir d'interface entre du C++ et du
> ..NET. A mon sens, il manque quelque chose d'important a C++/CLI pour
> en faire un langage a succes: de l'homogeneite dans les concepts
> utilises. Il melange les concepts de C++ et ceux de CLI. Il va
> continuer a etre tiraille entre les deux.

Tu appelles ça un manque d'homogeneite, ses concepteurs une force ;)
Question de point de vue sans doute.
C++/CLI est le seul à permettre le RAII et à offrir les templates en
plus des generics. Le dernier point a été défendu ici:
http://blogs.msdn.com/slippman/archive/2004/08/05/209606.aspx

Mais je suis d'accord que dans l'ensemble ça laisse perplexe. C'est ni
blanc ni noir, c'est gris...

Il m'avait semblé lire qu'une classe managée pourrait hériter d'un type
natif (sorte d'héritage privé). Ca aurait été une possibilité fabuleuse.
Mais j'ai du prendre mes désirs pour des réalités :-(

Fabien LE LEZ a écrit :
>>COM est un standard binaire que les langages doivent supporter. En .Net,
>> c'est natif, ils sont compatibles à la base.
>> Si j'ai tout bien compris, ce n'est pas exactement ça.
> COM est une technologie utilisable en C++ ; les versions Windows des
> compilateurs C++ doivent se démerder pour respecter cette
> spécification.
> Point Net est une technologie qui définit de nouveaux langages, avec
> un "C++/CLI" basé sur C++ comme C++ est basé sur C.

En fait .Net c'est vaste, y'a plein de sous niveaux. Je considère
personnellement .Net comme une plateforme, et je n'y inclus pas les
langages. Un peu comme x86 par exemple.

Tous les langages génèrent le même bytecode (CIL), utilisent les mêmes
types de base etc... Les compilos .Net sont des pisseurs de CIL, comme
C/C++/... génèrent de l'assembleur.

http://www.informit.com/content/images/irf_guide_dotnet_ganesh/elementLinks/ganesh_.netguide_fig12.gif

COM définit une protocole de communication logiciel : format de la
vtable, objet racine IUnknown, downcasting via QueryInterface...
En .Net, la virtualité est géré au niveau de l'assembleur, l'objet
racine System::Object est le même pour tous les langages, idem pour le
mécanisme d'exceptions etc...
Ainsi .Net 2.0 gère la destruction déterministe, mais C++/CLI est le
seul langage qui en tire parti.

Du coup tous ces mécanismes sont natifs. Chaque langage les expose avec
la syntaxe qu'il veut. Tout ça est standardisé, portable, et même assez
libre il me semble. Là où ça se complique c'est au niveaux des
bibliothèques / API. Beaucoup sont très liées à Win32. Et au niveau des
licences, c'est moins net (pour reprendre ta blague ;))

Aurelien Regat-Barrel <nospam.aregatba> writes:

> Jean-Marc Bourguet a écrit :
> > Je doute que C++/CLI soit capable de rivaliser avec C#. Il a
> > exactement la meme utilite: servir d'interface entre du C++ et du
> > ..NET. A mon sens, il manque quelque chose d'important a C++/CLI pour
> > en faire un langage a succes: de l'homogeneite dans les concepts
> > utilises. Il melange les concepts de C++ et ceux de CLI. Il va
> > continuer a etre tiraille entre les deux.
> Tu appelles ça un manque d'homogeneite, ses concepteurs une force ;)

Entre unification et confusion, il n'y a qu'une difference de point de
vue...

Je trouve qu'avoir deux modeles objets et deux modeles de genericites,
c'est un manque d'homogeneite -- et je pense que ce manque
d'homogeneite est consubstantiel a l'idee de C++/CLI --; quand en plus
ces modeles ne sont pas syntaxiquement bien distinct, ca releve pour
moi de la confusion -- la je ne crois pas que c'etait necessaire.

> Question de point de vue sans doute. C++/CLI est le seul à
> permettre le RAII et à offrir les templates en plus des generics.

Ada. Bien qu'a ma connaissance aucun compilateur Ada95 n'implemente
la genericite "partagee", la norme est soigneusement construite pour
la permettre. Certains compilateurs Ada83 avaient un pragma qui
permettait de passer d'un mode a l'autre sans changer la semantique.
On faisait le choix suivant l'importance relative de la compacite du
code/aspect bibliotheque sans generation de code et de la rapidite du
resultat (mais Ada83 n'avait pas l'equivalent de
constructeur/destructeur).

> Le dernier point a été défendu ici:
> [..]

J'irai voir quand j'aurai le temps.

> Il m'avait semblé lire qu'une classe managée pourrait hériter d'un type
> natif (sorte d'héritage privé). Ca aurait été une possibilité fabuleuse.
> Mais j'ai du prendre mes désirs pour des réalités :-(

Je n'ose pas imaginer le resultat.

A+

Aurelien Regat-Barrel <nospam.aregatba> writes:

| Jean-Marc Bourguet a écrit :
| > Je doute que C++/CLI soit capable de rivaliser avec C#. Il a
| > exactement la meme utilite: servir d'interface entre du C++ et du
| > ..NET. A mon sens, il manque quelque chose d'important a C++/CLI pour
| > en faire un langage a succes: de l'homogeneite dans les concepts
| > utilises. Il melange les concepts de C++ et ceux de CLI. Il va
| > continuer a etre tiraille entre les deux.
|
| Tu appelles ça un manque d'homogeneite, ses concepteurs une force ;)
| Question de point de vue sans doute.
| C++/CLI est le seul à permettre le RAII et à offrir les templates en
| plus des generics.

???

| Le dernier point a été défendu ici:
| http://blogs.msdn.com/slippman/archive/2004/08/05/209606.aspx

et lire également

http://public.research.att.com/~bs/bs_faq.html#CppCLI

-- Gaby

On 17 Jan 2006 16:32:09 +0100, Gabriel Dos Reis
<dosreis>:

>[..]

"[...] tempts programmers to write non-portable code that (often
invisibly) become intimately tied to Microsoft Windows."

Ben oui mon gars, c'est le but. Voire même la principale raison d'être
de Point Net.

Gabriel Dos Reis a écrit :
> | C++/CLI est le seul à permettre le RAII et à offrir les templates en
> | plus des generics.
> ???

"C++/CLI est le seul (*langage .Net*) à permettre le RAII et à offrir
les templates"

désolé pour cet oubli

> et lire également
> [..]

Haaa, enfin un avis extérieur sur le sujet. Merci pour le lien.