Développant en C++ (outils Microsoft sous Windows) depuis de nombreuses
années, je suis actuellement en recherche de poste (ingénieur de
développement) à 41 ans, et j'ai beaucoup de mal à trouver.
Dois-je en cnclure que le développement en C++ est en voie de
disparition (Java semble avoir la cote en ce moment), que je suis "trop
vieux" pour ça (il y a pourtant des développeurs seniors), ou que le
développement informatique est désormais suffisament "offshorisé" pour
limiter les recrutements en région parisienne ?
Ensuite, on verrait, mais si j'avais à parier, je parierais pour une réussite à peu près comme Java : il y aura certaines catégories d'applications où il servira beaucoup, mais il serait assez peu utilisé en dehors de ces catégories.
Mais Sun n'a pas l'assise de Microsoft dans les système d'exploitation. Et comme toujours, Microsoft va utiliser Windows pour imposer ses technologies.
C'est une rémarque intéressante. Parce qu'en fait, les domaines où Java reste dominants correspondent bien aux domaines où Sun domine, comme les serveurs d'entrepris. (Domine, ou dominer -- Linux y fait une percée. Mais on ne voit quasiment pas de Microsoft, sauf dans les toutes petites entreprises.)
En l'occurence, à terme, pour programmer une application Windows, il sera obligatoire de passer par .Net (WinFX). Donc on peut parier sur un développement beaucoup plus important que Java (si tenté qu'on puisse comparer .Net et Java).
De l'autre côté, .NET est ressenti comme une technologie « propriétaire », qui impose Microsoft non seulement maintenant, mais à jamais. Tandis que Java était ressenti comme une technologie plutôt ouverte. Jusqu'ici, tous les développements .NET que j'ai vu étaient des clients -- pour l'instant, j'ai l'impression qu'il n'a pas percé du tout dans les serveurs (ou Linux et Solaris dominent).
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
John Deuf wrote:
[...]
Ensuite, on verrait, mais si j'avais à parier, je parierais
pour une réussite à peu près comme Java : il y aura
certaines catégories d'applications où il servira beaucoup,
mais il serait assez peu utilisé en dehors de ces
catégories.
Mais Sun n'a pas l'assise de Microsoft dans les système
d'exploitation. Et comme toujours, Microsoft va utiliser
Windows pour imposer ses technologies.
C'est une rémarque intéressante. Parce qu'en fait, les domaines
où Java reste dominants correspondent bien aux domaines où Sun
domine, comme les serveurs d'entrepris. (Domine, ou dominer --
Linux y fait une percée. Mais on ne voit quasiment pas de
Microsoft, sauf dans les toutes petites entreprises.)
En l'occurence, à terme, pour programmer une application
Windows, il sera obligatoire de passer par .Net (WinFX). Donc
on peut parier sur un développement beaucoup plus important
que Java (si tenté qu'on puisse comparer .Net et Java).
De l'autre côté, .NET est ressenti comme une technologie
« propriétaire », qui impose Microsoft non seulement maintenant,
mais à jamais. Tandis que Java était ressenti comme une
technologie plutôt ouverte. Jusqu'ici, tous les développements
.NET que j'ai vu étaient des clients -- pour l'instant, j'ai
l'impression qu'il n'a pas percé du tout dans les serveurs (ou
Linux et Solaris dominent).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Ensuite, on verrait, mais si j'avais à parier, je parierais pour une réussite à peu près comme Java : il y aura certaines catégories d'applications où il servira beaucoup, mais il serait assez peu utilisé en dehors de ces catégories.
Mais Sun n'a pas l'assise de Microsoft dans les système d'exploitation. Et comme toujours, Microsoft va utiliser Windows pour imposer ses technologies.
C'est une rémarque intéressante. Parce qu'en fait, les domaines où Java reste dominants correspondent bien aux domaines où Sun domine, comme les serveurs d'entrepris. (Domine, ou dominer -- Linux y fait une percée. Mais on ne voit quasiment pas de Microsoft, sauf dans les toutes petites entreprises.)
En l'occurence, à terme, pour programmer une application Windows, il sera obligatoire de passer par .Net (WinFX). Donc on peut parier sur un développement beaucoup plus important que Java (si tenté qu'on puisse comparer .Net et Java).
De l'autre côté, .NET est ressenti comme une technologie « propriétaire », qui impose Microsoft non seulement maintenant, mais à jamais. Tandis que Java était ressenti comme une technologie plutôt ouverte. Jusqu'ici, tous les développements .NET que j'ai vu étaient des clients -- pour l'instant, j'ai l'impression qu'il n'a pas percé du tout dans les serveurs (ou Linux et Solaris dominent).
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Aurelien Regat-Barrel wrote:
[...]
Ensuite, on verrait, mais si j'avais à parier, je parierais pour une réussite à peu près comme Java : il y aura certaines catégories d'applications où il servira beaucoup, mais il serait assez peu utilisé en dehors de ces catégories.
Mais Sun n'a pas l'assise de Microsoft dans les système d'exploitation. Et comme toujours, Microsoft va utiliser Windows pour imposer ses technologies.
Je suis assez d'accord avec toi sur ce point. Je ne suis pas sûr que .Net suive le même chemin que Java, parce que les moyens de Microsoft sont bien supérieurs. Il suffit de comparer la vitesse d'évolution des 2 technologies.
Java a évolué extrèmement vite au départ. Et à l'encontre de Microsoft (jusqu'ici, au moins), Sun a su accrocher quelques autres joueurs de tailles, genre IBM.
C'est possible que .NET devient incontournable dans les domaines où Microsoft domine, comme les desktops et les stations de client, de même que Java est devenu incontournable dans les serveurs Web (ou Sun a dominé, et ou IBM a une rôle extrèmement important en ce qui concerne les logiciels).
Pour l'instant, la situation est que tout le monde veut s'en servir pour un projet pilote, pour voir ce que ça donne. C-à-d à peu près la situation de Java il y a sept ou huit ans. (Mais j'avoue que j'ai pu avoir laissé passer beaucoup, parce que dans les domaines où je travaille, Microsoft n'est simplement pas présent.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Aurelien Regat-Barrel wrote:
[...]
Ensuite, on verrait, mais si j'avais à parier, je parierais
pour une réussite à peu près comme Java : il y aura
certaines catégories d'applications où il servira beaucoup,
mais il serait assez peu utilisé en dehors de ces
catégories.
Mais Sun n'a pas l'assise de Microsoft dans les système
d'exploitation. Et comme toujours, Microsoft va utiliser
Windows pour imposer ses technologies.
Je suis assez d'accord avec toi sur ce point. Je ne suis pas
sûr que .Net suive le même chemin que Java, parce que les
moyens de Microsoft sont bien supérieurs. Il suffit de
comparer la vitesse d'évolution des 2 technologies.
Java a évolué extrèmement vite au départ. Et à l'encontre de
Microsoft (jusqu'ici, au moins), Sun a su accrocher quelques
autres joueurs de tailles, genre IBM.
C'est possible que .NET devient incontournable dans les domaines
où Microsoft domine, comme les desktops et les stations de
client, de même que Java est devenu incontournable dans les
serveurs Web (ou Sun a dominé, et ou IBM a une rôle extrèmement
important en ce qui concerne les logiciels).
Pour l'instant, la situation est que tout le monde veut s'en
servir pour un projet pilote, pour voir ce que ça donne. C-à-d à
peu près la situation de Java il y a sept ou huit ans. (Mais
j'avoue que j'ai pu avoir laissé passer beaucoup, parce que dans
les domaines où je travaille, Microsoft n'est simplement pas
présent.)
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Ensuite, on verrait, mais si j'avais à parier, je parierais pour une réussite à peu près comme Java : il y aura certaines catégories d'applications où il servira beaucoup, mais il serait assez peu utilisé en dehors de ces catégories.
Mais Sun n'a pas l'assise de Microsoft dans les système d'exploitation. Et comme toujours, Microsoft va utiliser Windows pour imposer ses technologies.
Je suis assez d'accord avec toi sur ce point. Je ne suis pas sûr que .Net suive le même chemin que Java, parce que les moyens de Microsoft sont bien supérieurs. Il suffit de comparer la vitesse d'évolution des 2 technologies.
Java a évolué extrèmement vite au départ. Et à l'encontre de Microsoft (jusqu'ici, au moins), Sun a su accrocher quelques autres joueurs de tailles, genre IBM.
C'est possible que .NET devient incontournable dans les domaines où Microsoft domine, comme les desktops et les stations de client, de même que Java est devenu incontournable dans les serveurs Web (ou Sun a dominé, et ou IBM a une rôle extrèmement important en ce qui concerne les logiciels).
Pour l'instant, la situation est que tout le monde veut s'en servir pour un projet pilote, pour voir ce que ça donne. C-à-d à peu près la situation de Java il y a sept ou huit ans. (Mais j'avoue que j'ai pu avoir laissé passer beaucoup, parce que dans les domaines où je travaille, Microsoft n'est simplement pas présent.)
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
loufoque wrote:
Ensuite, on verrait, mais si j'avais à parier, je parierais pour une réussite à peu près comme Java : il y aura certaines catégories d'applications où il servira beaucoup, mais il serait assez peu utilisé en dehors de ces catégories.
Bon, les deux sont faits pour le RAD, ce qui permet de faire des projets simples rapidement. La différence entre les deux étant que .NET est plus focalisé sur Windows.
Et donc côté client. Tandis que Apache, WebSphere, etc., l'ignorent, et continuent à ne supporter que Java (et éventuellement Perl).
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
loufoque wrote:
Ensuite, on verrait, mais si j'avais à parier, je parierais
pour une réussite à peu près comme Java : il y aura
certaines catégories d'applications où il servira beaucoup,
mais il serait assez peu utilisé en dehors de ces
catégories.
Bon, les deux sont faits pour le RAD, ce qui permet de faire
des projets simples rapidement. La différence entre les deux
étant que .NET est plus focalisé sur Windows.
Et donc côté client. Tandis que Apache, WebSphere, etc.,
l'ignorent, et continuent à ne supporter que Java (et
éventuellement Perl).
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Ensuite, on verrait, mais si j'avais à parier, je parierais pour une réussite à peu près comme Java : il y aura certaines catégories d'applications où il servira beaucoup, mais il serait assez peu utilisé en dehors de ces catégories.
Bon, les deux sont faits pour le RAD, ce qui permet de faire des projets simples rapidement. La différence entre les deux étant que .NET est plus focalisé sur Windows.
Et donc côté client. Tandis que Apache, WebSphere, etc., l'ignorent, et continuent à ne supporter que Java (et éventuellement Perl).
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ
On 16 Jan 2006 01:38:59 -0800, "kanze" :
Et donc côté client. Tandis que Apache, WebSphere, etc., l'ignorent, et continuent à ne supporter que Java (et éventuellement Perl).
Ou PHP.
Mais y a-t-il autre chose dans .Net qu'une refonte de l'API Win32 pour les applications GUI ?
On 16 Jan 2006 01:38:59 -0800, "kanze" <kanze@gabi-soft.fr>:
Et donc côté client. Tandis que Apache, WebSphere, etc.,
l'ignorent, et continuent à ne supporter que Java (et
éventuellement Perl).
Ou PHP.
Mais y a-t-il autre chose dans .Net qu'une refonte de l'API Win32 pour
les applications GUI ?
Et donc côté client. Tandis que Apache, WebSphere, etc., l'ignorent, et continuent à ne supporter que Java (et éventuellement Perl).
Ou PHP.
Mais y a-t-il autre chose dans .Net qu'une refonte de l'API Win32 pour les applications GUI ?
Jean-Marc Bourguet
Fabien LE LEZ writes:
On 16 Jan 2006 01:38:59 -0800, "kanze" :
Et donc côté client. Tandis que Apache, WebSphere, etc., l'ignorent, et continuent à ne supporter que Java (et éventuellement Perl).
Ou PHP.
Mais y a-t-il autre chose dans .Net qu'une refonte de l'API Win32 pour les applications GUI ?
Tel que je le vois dans .NET il y a deux plusieurs choses: - un runtime se voulant commun a tous les langages (ce n'est pas nouveau pour quelqu'un qui a utilise VMS) - ce runtime est base sur un modele objet et un modele de genericite (ca me semble plus nouveau) avec du GC - une machine virtuelle cible pour les compilateurs voulant compiler pour ce runtime
C++/CLI, c'est on ajoute a C++ une nouvelle sorte d'objet et une nouvelle sorte de template avec leur semantique propre pour s'interfacer avec .NET. On garde plus ou moins la syntaxe du C++, ce qui a mon avis pose des problemes: des choses similaires ont un comportement different suivant qu'il s'agit d'un template "natif" ou CLI, d'une classe native ou CLI. Parfois le comportement different est totalement gratuit et pas necessaire a mon avis pour s'interfacer avec CLI (par exemple la recherche des noms dans les classes CLI n'est pas la meme que dans les classes natives), parfois ca me semble plus difficile car le comportement est defini par CLI (les appels de membres virtuels dans les constructeurs et destructeurs).
Il y a aussi des ajouts qui n'ont qu'un rapport lointain avec la necessite de s'interfacer avec CLI (for each, long long -- par chance ou par choix la proposition de CLI semble correspondre sur ce dernier point a la proposition du comite).
Si j'avais a programmer pour .NET, j'essaierais de le faire autant que possible en C#, au moins c'est un langage dont le modele objet naturel est celui du runtime...
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
Fabien LE LEZ <gramster@gramster.com> writes:
On 16 Jan 2006 01:38:59 -0800, "kanze" <kanze@gabi-soft.fr>:
Et donc côté client. Tandis que Apache, WebSphere, etc.,
l'ignorent, et continuent à ne supporter que Java (et
éventuellement Perl).
Ou PHP.
Mais y a-t-il autre chose dans .Net qu'une refonte de l'API Win32 pour
les applications GUI ?
Tel que je le vois dans .NET il y a deux plusieurs choses:
- un runtime se voulant commun a tous les langages (ce n'est pas
nouveau pour quelqu'un qui a utilise VMS)
- ce runtime est base sur un modele objet et un modele de
genericite (ca me semble plus nouveau) avec du GC
- une machine virtuelle cible pour les compilateurs voulant
compiler pour ce runtime
C++/CLI, c'est on ajoute a C++ une nouvelle sorte d'objet et une
nouvelle sorte de template avec leur semantique propre pour
s'interfacer avec .NET. On garde plus ou moins la syntaxe du C++, ce
qui a mon avis pose des problemes: des choses similaires ont un
comportement different suivant qu'il s'agit d'un template "natif" ou
CLI, d'une classe native ou CLI. Parfois le comportement different
est totalement gratuit et pas necessaire a mon avis pour s'interfacer
avec CLI (par exemple la recherche des noms dans les classes CLI n'est
pas la meme que dans les classes natives), parfois ca me semble plus
difficile car le comportement est defini par CLI (les appels de
membres virtuels dans les constructeurs et destructeurs).
Il y a aussi des ajouts qui n'ont qu'un rapport lointain avec la
necessite de s'interfacer avec CLI (for each, long long -- par chance
ou par choix la proposition de CLI semble correspondre sur ce dernier
point a la proposition du comite).
Si j'avais a programmer pour .NET, j'essaierais de le faire autant que
possible en C#, au moins c'est un langage dont le modele objet naturel
est celui du runtime...
A+
--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Et donc côté client. Tandis que Apache, WebSphere, etc., l'ignorent, et continuent à ne supporter que Java (et éventuellement Perl).
Ou PHP.
Mais y a-t-il autre chose dans .Net qu'une refonte de l'API Win32 pour les applications GUI ?
Tel que je le vois dans .NET il y a deux plusieurs choses: - un runtime se voulant commun a tous les langages (ce n'est pas nouveau pour quelqu'un qui a utilise VMS) - ce runtime est base sur un modele objet et un modele de genericite (ca me semble plus nouveau) avec du GC - une machine virtuelle cible pour les compilateurs voulant compiler pour ce runtime
C++/CLI, c'est on ajoute a C++ une nouvelle sorte d'objet et une nouvelle sorte de template avec leur semantique propre pour s'interfacer avec .NET. On garde plus ou moins la syntaxe du C++, ce qui a mon avis pose des problemes: des choses similaires ont un comportement different suivant qu'il s'agit d'un template "natif" ou CLI, d'une classe native ou CLI. Parfois le comportement different est totalement gratuit et pas necessaire a mon avis pour s'interfacer avec CLI (par exemple la recherche des noms dans les classes CLI n'est pas la meme que dans les classes natives), parfois ca me semble plus difficile car le comportement est defini par CLI (les appels de membres virtuels dans les constructeurs et destructeurs).
Il y a aussi des ajouts qui n'ont qu'un rapport lointain avec la necessite de s'interfacer avec CLI (for each, long long -- par chance ou par choix la proposition de CLI semble correspondre sur ce dernier point a la proposition du comite).
Si j'avais a programmer pour .NET, j'essaierais de le faire autant que possible en C#, au moins c'est un langage dont le modele objet naturel est celui du runtime...
A+
-- Jean-Marc FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html Site de usenet-fr: http://www.usenet-fr.news.eu.org
David MAREC
D'après kanze:
lfaj wrote:
Dois-je en cnclure que le développement en C++ est en voie de disparition (Java semble avoir la cote en ce moment),
J'ai plutôt l'impression du contraire, au moins sur le marché de l'indépendant. Il y a peut-être un peu plus de contrats en Java, mais ils sont typiquement beaucoup plus court -- on ne fait pas de gros développements en Java. La démande en C++ semble y être, en tout cas.
[ / C'est un peu hors du débat/ ]
Curieusement, lorsque que je compile Java¹ (ctmetcsdc) , c'est une longue liste de «.cpp» et de «.hpp» qui défile.
La mécanique - ou du moins, une partie - Java est écrite en C++ !?
¹ : jdk 1.4 -- ...
D'après kanze:
lfaj wrote:
Dois-je en cnclure que le développement en C++ est en voie de
disparition (Java semble avoir la cote en ce moment),
J'ai plutôt l'impression du contraire, au moins sur le marché de
l'indépendant. Il y a peut-être un peu plus de contrats en Java,
mais ils sont typiquement beaucoup plus court -- on ne fait pas
de gros développements en Java. La démande en C++ semble y être,
en tout cas.
[ / C'est un peu hors du débat/ ]
Curieusement, lorsque que je compile Java¹ (ctmetcsdc) , c'est une longue
liste de «.cpp» et de «.hpp» qui défile.
La mécanique - ou du moins, une partie - Java est écrite en C++ !?
Dois-je en cnclure que le développement en C++ est en voie de disparition (Java semble avoir la cote en ce moment),
J'ai plutôt l'impression du contraire, au moins sur le marché de l'indépendant. Il y a peut-être un peu plus de contrats en Java, mais ils sont typiquement beaucoup plus court -- on ne fait pas de gros développements en Java. La démande en C++ semble y être, en tout cas.
[ / C'est un peu hors du débat/ ]
Curieusement, lorsque que je compile Java¹ (ctmetcsdc) , c'est une longue liste de «.cpp» et de «.hpp» qui défile.
La mécanique - ou du moins, une partie - Java est écrite en C++ !?
¹ : jdk 1.4 -- ...
Cyrille
[ / C'est un peu hors du débat/ ]
Curieusement, lorsque que je compile Java¹ (ctmetcsdc) , c'est une longue liste de «.cpp» et de «.hpp» qui défile.
La mécanique - ou du moins, une partie - Java est écrite en C++ !?
J'imagine que la machine virtuelle est écrite en code natif (et donc avec un langage compilé, pourquoi pas C++), puisqu'elle ne peut compter sur une autre machine virtuelle Java pour s'exécuter.
-- Là.
[ / C'est un peu hors du débat/ ]
Curieusement, lorsque que je compile Java¹ (ctmetcsdc) , c'est une longue
liste de «.cpp» et de «.hpp» qui défile.
La mécanique - ou du moins, une partie - Java est écrite en C++ !?
J'imagine que la machine virtuelle est écrite en code natif (et donc
avec un langage compilé, pourquoi pas C++), puisqu'elle ne peut compter
sur une autre machine virtuelle Java pour s'exécuter.
Curieusement, lorsque que je compile Java¹ (ctmetcsdc) , c'est une longue liste de «.cpp» et de «.hpp» qui défile.
La mécanique - ou du moins, une partie - Java est écrite en C++ !?
J'imagine que la machine virtuelle est écrite en code natif (et donc avec un langage compilé, pourquoi pas C++), puisqu'elle ne peut compter sur une autre machine virtuelle Java pour s'exécuter.
-- Là.
Fabien LE LEZ
On 16 Jan 2006 13:53:05 +0100, Jean-Marc Bourguet :
[...]
Finalement, j'ai l'impression que .Net est la réponse du berger Microsoft à la bergère wxWidgets (ou Qt, etc.)
Typiquement, si on veut faire une application GUI pour un seul OS, on la développe sous Windows, car c'est le plus gros marché.
Mais il est de plus en plus facile, grâce à des bibliothèques comme wxWidgets, de faire des applications multi-plate-formes, et donc d'encourager l'utilisation de MacOSX et de Linux.
Pour endiguer le phénomène, Microsoft décide de faire en sorte que les programmeurs ne sachent faire que de la programmation Windows. .Net était né.
Ce n'est point net[*], tout ça.
[*] Oui, je sais, elle est très mauvaise. Désolé.
On 16 Jan 2006 13:53:05 +0100, Jean-Marc Bourguet <jm@bourguet.org>:
[...]
Finalement, j'ai l'impression que .Net est la réponse du berger
Microsoft à la bergère wxWidgets (ou Qt, etc.)
Typiquement, si on veut faire une application GUI pour un seul OS, on
la développe sous Windows, car c'est le plus gros marché.
Mais il est de plus en plus facile, grâce à des bibliothèques comme
wxWidgets, de faire des applications multi-plate-formes, et donc
d'encourager l'utilisation de MacOSX et de Linux.
Pour endiguer le phénomène, Microsoft décide de faire en sorte que les
programmeurs ne sachent faire que de la programmation Windows. .Net
était né.
On 16 Jan 2006 13:53:05 +0100, Jean-Marc Bourguet :
[...]
Finalement, j'ai l'impression que .Net est la réponse du berger Microsoft à la bergère wxWidgets (ou Qt, etc.)
Typiquement, si on veut faire une application GUI pour un seul OS, on la développe sous Windows, car c'est le plus gros marché.
Mais il est de plus en plus facile, grâce à des bibliothèques comme wxWidgets, de faire des applications multi-plate-formes, et donc d'encourager l'utilisation de MacOSX et de Linux.
Pour endiguer le phénomène, Microsoft décide de faire en sorte que les programmeurs ne sachent faire que de la programmation Windows. .Net était né.
Ce n'est point net[*], tout ça.
[*] Oui, je sais, elle est très mauvaise. Désolé.
loufoque
Typiquement, si on veut faire une application GUI pour un seul OS, on la développe sous Windows, car c'est le plus gros marché.
Dans un but commercial oui. Mais moi par exemple, qui fait des applications dans mon temps libre, je les fais donc avec le toolkit que je préfère pour la plateforme que j'utilise. Et avouons le, du point de vue du programmeur, y'a mieux que les outils Microsoft. L'API Win32 et MFC sont immondes.
Je trouve .NET pas trop mal, mais avec C# uniquement. Avec C++ je trouve que ça se marie très mal. Or certains projets peuvent avoir besoin de la puissance de C ou C++ et préféreront donc peut-être chercher des solutions alternatives.
Typiquement, si on veut faire une application GUI pour un seul OS, on
la développe sous Windows, car c'est le plus gros marché.
Dans un but commercial oui. Mais moi par exemple, qui fait des
applications dans mon temps libre, je les fais donc avec le toolkit que
je préfère pour la plateforme que j'utilise.
Et avouons le, du point de vue du programmeur, y'a mieux que les outils
Microsoft. L'API Win32 et MFC sont immondes.
Je trouve .NET pas trop mal, mais avec C# uniquement. Avec C++ je trouve
que ça se marie très mal.
Or certains projets peuvent avoir besoin de la puissance de C ou C++ et
préféreront donc peut-être chercher des solutions alternatives.
Typiquement, si on veut faire une application GUI pour un seul OS, on la développe sous Windows, car c'est le plus gros marché.
Dans un but commercial oui. Mais moi par exemple, qui fait des applications dans mon temps libre, je les fais donc avec le toolkit que je préfère pour la plateforme que j'utilise. Et avouons le, du point de vue du programmeur, y'a mieux que les outils Microsoft. L'API Win32 et MFC sont immondes.
Je trouve .NET pas trop mal, mais avec C# uniquement. Avec C++ je trouve que ça se marie très mal. Or certains projets peuvent avoir besoin de la puissance de C ou C++ et préféreront donc peut-être chercher des solutions alternatives.
loufoque
(Mais j'avoue que j'ai pu avoir laissé passer beaucoup, parce que dans les domaines où je travaille, Microsoft n'est simplement pas présent.)
Je croyais qu'en France ils étaient implantés partout ?
(Mais
j'avoue que j'ai pu avoir laissé passer beaucoup, parce que dans
les domaines où je travaille, Microsoft n'est simplement pas
présent.)
Je croyais qu'en France ils étaient implantés partout ?
