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
Ah putain, alors s'il y a un truc qui me gonfle plus que les neuneux qui foncent sur C# parce qu'il n'y a pas de pointeurs à gérer, c'est bien les gens qui clament haut et fort que le goto c'est le MAL absolu.
Qui a dit que le goto c'est le MAL ? Mais n'utiliser que ca, ca l'est.
La doctrine veut que l'on n'utilise *pas* le goto, absolument jamais. C'est ce que tu entendras partout.
JB.
-- NERVE GAS IS NOT A TOY NERVE GAS IS NOT A TOY NERVE GAS IS NOT A TOY -+- Bart Simpson on chalkboard in episode 2F32
nicolas vigier <boklm@mars-attacks.org> wrote:
Ah putain, alors s'il y a un truc qui me gonfle plus que les neuneux
qui foncent sur C# parce qu'il n'y a pas de pointeurs à gérer, c'est
bien les gens qui clament haut et fort que le goto c'est le MAL
absolu.
Qui a dit que le goto c'est le MAL ? Mais n'utiliser que ca, ca l'est.
La doctrine veut que l'on n'utilise *pas* le goto, absolument
jamais. C'est ce que tu entendras partout.
JB.
--
NERVE GAS IS NOT A TOY
NERVE GAS IS NOT A TOY
NERVE GAS IS NOT A TOY
-+- Bart Simpson on chalkboard in episode 2F32
Ah putain, alors s'il y a un truc qui me gonfle plus que les neuneux qui foncent sur C# parce qu'il n'y a pas de pointeurs à gérer, c'est bien les gens qui clament haut et fort que le goto c'est le MAL absolu.
Qui a dit que le goto c'est le MAL ? Mais n'utiliser que ca, ca l'est.
La doctrine veut que l'on n'utilise *pas* le goto, absolument jamais. C'est ce que tu entendras partout.
JB.
-- NERVE GAS IS NOT A TOY NERVE GAS IS NOT A TOY NERVE GAS IS NOT A TOY -+- Bart Simpson on chalkboard in episode 2F32
Sébastien Kirche
Le 29 mai 2005, Laurent BERNE vraute :
Mais Dot Net, ca se résume pas à une simple machine virtuelle.. Le système de la GAC, reprends les quelques avantages de COM, est infiniment moins lourd dans le déploiement, rajoute l'héritage d'objet pourtant compilé (peut importe le langage d'origine), supprime totalement l'enfer des versions concurrentes, ce genre de chose.
Moi je bosse habituellement sous MacOS X et quand j'ai pu voir ce principe d'assemblages et de coexistence possible des versions de bibliothèques ça m'a rappelé les bundles Mac (ressemblant comme des frères aux assemblages avec les méta-données, le code et les ressources) et les frameworks qui permettent d'installer une bibliothèque indépendemment des autres versions de la même bibliothèque. La seule différence c'est que sur mac on peut avoir un framework local à une application (dans le bundle) ou au niveau système dans une sorte de GAC.
Et ça c'est un net progrès pour ceux qui doivent déployer du code. -- Sébastien Kirche
Le 29 mai 2005, Laurent BERNE vraute :
Mais Dot Net, ca se résume pas à une simple machine virtuelle.. Le
système de la GAC, reprends les quelques avantages de COM, est
infiniment moins lourd dans le déploiement, rajoute l'héritage d'objet
pourtant compilé (peut importe le langage d'origine), supprime
totalement l'enfer des versions concurrentes, ce genre de chose.
Moi je bosse habituellement sous MacOS X et quand j'ai pu voir ce
principe d'assemblages et de coexistence possible des versions de
bibliothèques ça m'a rappelé les bundles Mac (ressemblant comme des
frères aux assemblages avec les méta-données, le code et les ressources)
et les frameworks qui permettent d'installer une bibliothèque
indépendemment des autres versions de la même bibliothèque. La seule
différence c'est que sur mac on peut avoir un framework local à une
application (dans le bundle) ou au niveau système dans une sorte de GAC.
Et ça c'est un net progrès pour ceux qui doivent déployer du code.
--
Sébastien Kirche
Mais Dot Net, ca se résume pas à une simple machine virtuelle.. Le système de la GAC, reprends les quelques avantages de COM, est infiniment moins lourd dans le déploiement, rajoute l'héritage d'objet pourtant compilé (peut importe le langage d'origine), supprime totalement l'enfer des versions concurrentes, ce genre de chose.
Moi je bosse habituellement sous MacOS X et quand j'ai pu voir ce principe d'assemblages et de coexistence possible des versions de bibliothèques ça m'a rappelé les bundles Mac (ressemblant comme des frères aux assemblages avec les méta-données, le code et les ressources) et les frameworks qui permettent d'installer une bibliothèque indépendemment des autres versions de la même bibliothèque. La seule différence c'est que sur mac on peut avoir un framework local à une application (dans le bundle) ou au niveau système dans une sorte de GAC.
Et ça c'est un net progrès pour ceux qui doivent déployer du code. -- Sébastien Kirche
Le goto pour le traitement d'erreur, il n'y a pas mieux. Les exceptions ne sont rien d'autre qu'un bon gros goto déguisé, et très franchement, c'est bien moins lisible qu'un goto. Tu préfères sûrement imbriquer 42 if et répéter du code pour libérer des ressources etc. autant de fois, c'est ton droit.
Dans les exceptions, il y a une sauvegarde du contexte qui n'existe pas avec le goto, mais, à la rigueur, avec le setjmp/longjmp du langage C. En pratique, cela conduit à une plus grande souplesse d'utilisation. Un goto est nécessairement traité au sein de la même fonction, tandis qu'une exception laisse le choix de l'endroit du traitement de l'erreur.
Pour sortir d'une boucle sans faire des constructions à la con c'est pareil, c'est bien utile et ça améliore pas mal la lisibilité de ladite boucle.
Pour sortir d'une boucle, il y a d'autres instructions que le goto comme break et continue, le problème est de sortir de plusieurs boucles imbriquées. Java s'en sort sans goto en étendant break et continue et en étiquettant les boucles. Mais je suis d'accord que c'est la même chose qu'un goto, en particulier le flux est brisé pareillement et le code est aussi difficile à suivre.
-- Richard
Le goto pour le traitement d'erreur, il n'y a pas mieux. Les
exceptions ne sont rien d'autre qu'un bon gros goto déguisé, et très
franchement, c'est bien moins lisible qu'un goto. Tu préfères sûrement
imbriquer 42 if et répéter du code pour libérer des ressources
etc. autant de fois, c'est ton droit.
Dans les exceptions, il y a une sauvegarde du contexte qui n'existe pas
avec le goto, mais, à la rigueur, avec le setjmp/longjmp du langage C.
En pratique, cela conduit à une plus grande souplesse d'utilisation. Un
goto est nécessairement traité au sein de la même fonction, tandis
qu'une exception laisse le choix de l'endroit du traitement de l'erreur.
Pour sortir d'une boucle sans faire des constructions à la con c'est
pareil, c'est bien utile et ça améliore pas mal la lisibilité de
ladite boucle.
Pour sortir d'une boucle, il y a d'autres instructions que le goto comme
break et continue, le problème est de sortir de plusieurs boucles
imbriquées. Java s'en sort sans goto en étendant break et continue et en
étiquettant les boucles. Mais je suis d'accord que c'est la même chose
qu'un goto, en particulier le flux est brisé pareillement et le code est
aussi difficile à suivre.
Le goto pour le traitement d'erreur, il n'y a pas mieux. Les exceptions ne sont rien d'autre qu'un bon gros goto déguisé, et très franchement, c'est bien moins lisible qu'un goto. Tu préfères sûrement imbriquer 42 if et répéter du code pour libérer des ressources etc. autant de fois, c'est ton droit.
Dans les exceptions, il y a une sauvegarde du contexte qui n'existe pas avec le goto, mais, à la rigueur, avec le setjmp/longjmp du langage C. En pratique, cela conduit à une plus grande souplesse d'utilisation. Un goto est nécessairement traité au sein de la même fonction, tandis qu'une exception laisse le choix de l'endroit du traitement de l'erreur.
Pour sortir d'une boucle sans faire des constructions à la con c'est pareil, c'est bien utile et ça améliore pas mal la lisibilité de ladite boucle.
Pour sortir d'une boucle, il y a d'autres instructions que le goto comme break et continue, le problème est de sortir de plusieurs boucles imbriquées. Java s'en sort sans goto en étendant break et continue et en étiquettant les boucles. Mais je suis d'accord que c'est la même chose qu'un goto, en particulier le flux est brisé pareillement et le code est aussi difficile à suivre.
-- Richard
talon
Laurent BERNE wrote:
Je pense notamment à l'assertion sur le prétendu échec de C#(part de marché avoisinant zéro).
Le prétendu échec en question c'est évidemment par rapport au nombre de développements en Visual Basic ou C++. La volonté de Microsoft était de faire basculer tout vers C#. Or ça ne s'est pas produit, selon tout ce qu'on peut lire. Ce n'est pas du tout contradictoire avec le fait qu'il existe un nombre non négligeable d'offres d'emploi pour C#.
de ligne (peut être pas dix fois non plus hein..). Simplement avec des notions comme le databinding par exemple. Ou par la richesse du framework.
La richesse des librairies qui sont autour, je crois que tout le monde est d'accord. Le problème c'est qu'il y a un "lock in" total sur ces librairies.
Ne serait-ce que la possibilité d'utilser du code "Win32" classique et de l'invoquer dans Dot Net, et aussi l'inverse (par exemple faire des DLL en Dot Net et les utiliser dans des applis Win32)
Parcequ'il n'y a pas la possibilité de faire des extensions en C en Java ou en python? En python il y a même moyen d'entremêler complètement le C et le python, si on utilise pyrex. Pour le calcul scientifique c'est particulièrement intéressant parceque ça permet d'intégrer du code performant et largement testé avec un minimum d'efforts.
La conclusion, c'est que je développe plus rapidement en C# aujourd'hui qu'en Delphi ou en C++ ou en Java (et donc je reviens moins cher..). En ces périodes à la délocalisation facile, mon choix est vite fait.
Ne t'inquiètes pas, s'il faut faire du C# pour décrocher des marchés, les Tchèques, Indiens et autres le feront tout aussi bien qu'ils se sont mis à Java et ça ne changera pas un iota à la problématique de la délocalisation. En attendant l'industriel qui aura mis le doigt dans l'engrenage du C#, et encore plus si ses ingénieurs utilisent des trucs non standard, comme des appels à des DLL, sera l'otage de Microsoft indéfiniment. Et ça finira par lui couter la peau des fesses, et dix fois plus que s'il avait développé son bidule en assembleur.
Je pense notamment à l'assertion sur le prétendu échec de C#(part de
marché avoisinant zéro).
Le prétendu échec en question c'est évidemment par rapport au nombre de
développements en Visual Basic ou C++. La volonté de Microsoft était de faire
basculer tout vers C#. Or ça ne s'est pas produit, selon tout ce qu'on peut
lire. Ce n'est pas du tout contradictoire avec le fait qu'il existe un nombre
non négligeable d'offres d'emploi pour C#.
de ligne (peut être pas dix fois non plus hein..). Simplement avec des
notions comme le databinding par exemple. Ou par la richesse du
framework.
La richesse des librairies qui sont autour, je crois que tout le monde est
d'accord. Le problème c'est qu'il y a un "lock in" total sur ces librairies.
Ne serait-ce que la possibilité d'utilser du code "Win32" classique et
de l'invoquer dans Dot Net, et aussi l'inverse (par exemple faire des
DLL en Dot Net et les utiliser dans des applis Win32)
Parcequ'il n'y a pas la possibilité de faire des extensions en C en Java ou en
python? En python il y a même moyen d'entremêler complètement le C
et le python, si on utilise pyrex. Pour le calcul scientifique c'est
particulièrement intéressant parceque ça permet d'intégrer du code performant
et largement testé avec un minimum d'efforts.
La conclusion, c'est que je développe plus rapidement en C# aujourd'hui
qu'en Delphi ou en C++ ou en Java (et donc je reviens moins cher..).
En ces périodes à la délocalisation facile, mon choix est vite fait.
Ne t'inquiètes pas, s'il faut faire du C# pour décrocher des marchés,
les Tchèques, Indiens et autres le feront tout aussi bien qu'ils se sont mis à
Java et ça ne changera pas un iota à la problématique de la délocalisation.
En attendant l'industriel qui aura mis le doigt dans l'engrenage du C#, et
encore plus si ses ingénieurs utilisent des trucs non standard, comme
des appels à des DLL, sera l'otage de Microsoft indéfiniment. Et ça finira par
lui couter la peau des fesses, et dix fois plus que s'il avait développé son
bidule en assembleur.
Je pense notamment à l'assertion sur le prétendu échec de C#(part de marché avoisinant zéro).
Le prétendu échec en question c'est évidemment par rapport au nombre de développements en Visual Basic ou C++. La volonté de Microsoft était de faire basculer tout vers C#. Or ça ne s'est pas produit, selon tout ce qu'on peut lire. Ce n'est pas du tout contradictoire avec le fait qu'il existe un nombre non négligeable d'offres d'emploi pour C#.
de ligne (peut être pas dix fois non plus hein..). Simplement avec des notions comme le databinding par exemple. Ou par la richesse du framework.
La richesse des librairies qui sont autour, je crois que tout le monde est d'accord. Le problème c'est qu'il y a un "lock in" total sur ces librairies.
Ne serait-ce que la possibilité d'utilser du code "Win32" classique et de l'invoquer dans Dot Net, et aussi l'inverse (par exemple faire des DLL en Dot Net et les utiliser dans des applis Win32)
Parcequ'il n'y a pas la possibilité de faire des extensions en C en Java ou en python? En python il y a même moyen d'entremêler complètement le C et le python, si on utilise pyrex. Pour le calcul scientifique c'est particulièrement intéressant parceque ça permet d'intégrer du code performant et largement testé avec un minimum d'efforts.
La conclusion, c'est que je développe plus rapidement en C# aujourd'hui qu'en Delphi ou en C++ ou en Java (et donc je reviens moins cher..). En ces périodes à la délocalisation facile, mon choix est vite fait.
Ne t'inquiètes pas, s'il faut faire du C# pour décrocher des marchés, les Tchèques, Indiens et autres le feront tout aussi bien qu'ils se sont mis à Java et ça ne changera pas un iota à la problématique de la délocalisation. En attendant l'industriel qui aura mis le doigt dans l'engrenage du C#, et encore plus si ses ingénieurs utilisent des trucs non standard, comme des appels à des DLL, sera l'otage de Microsoft indéfiniment. Et ça finira par lui couter la peau des fesses, et dix fois plus que s'il avait développé son bidule en assembleur.
--
Michel TALON
talon
Sébastien Kirche wrote:
Le 29 mai 2005, Laurent BERNE vraute :
Mais Dot Net, ca se résume pas à une simple machine virtuelle.. Le système de la GAC, reprends les quelques avantages de COM, est infiniment moins lourd dans le déploiement, rajoute l'héritage d'objet pourtant compilé (peut importe le langage d'origine), supprime totalement l'enfer des versions concurrentes, ce genre de chose.
Moi je bosse habituellement sous MacOS X et quand j'ai pu voir ce principe d'assemblages et de coexistence possible des versions de bibliothèques ça m'a rappelé les bundles Mac (ressemblant comme des frères aux assemblages avec les méta-données, le code et les ressources) et les frameworks qui permettent d'installer une bibliothèque indépendemment des autres versions de la même bibliothèque. La seule différence c'est que sur mac on peut avoir un framework local à une application (dans le bundle) ou au niveau système dans une sorte de GAC.
Et ça c'est un net progrès pour ceux qui doivent déployer du code.
Et ça c'est ce que Dragonflybsd est en train de mettre au point de la manière la plus générale dans un cadre Unix traditionnel.
--
Michel TALON
Sébastien Kirche <sebastien.kirche.no@spam.free.fr.invalid> wrote:
Le 29 mai 2005, Laurent BERNE vraute :
Mais Dot Net, ca se résume pas à une simple machine virtuelle.. Le
système de la GAC, reprends les quelques avantages de COM, est
infiniment moins lourd dans le déploiement, rajoute l'héritage d'objet
pourtant compilé (peut importe le langage d'origine), supprime
totalement l'enfer des versions concurrentes, ce genre de chose.
Moi je bosse habituellement sous MacOS X et quand j'ai pu voir ce
principe d'assemblages et de coexistence possible des versions de
bibliothèques ça m'a rappelé les bundles Mac (ressemblant comme des
frères aux assemblages avec les méta-données, le code et les ressources)
et les frameworks qui permettent d'installer une bibliothèque
indépendemment des autres versions de la même bibliothèque. La seule
différence c'est que sur mac on peut avoir un framework local à une
application (dans le bundle) ou au niveau système dans une sorte de GAC.
Et ça c'est un net progrès pour ceux qui doivent déployer du code.
Et ça c'est ce que Dragonflybsd est en train de mettre au point de la manière
la plus générale dans un cadre Unix traditionnel.
Mais Dot Net, ca se résume pas à une simple machine virtuelle.. Le système de la GAC, reprends les quelques avantages de COM, est infiniment moins lourd dans le déploiement, rajoute l'héritage d'objet pourtant compilé (peut importe le langage d'origine), supprime totalement l'enfer des versions concurrentes, ce genre de chose.
Moi je bosse habituellement sous MacOS X et quand j'ai pu voir ce principe d'assemblages et de coexistence possible des versions de bibliothèques ça m'a rappelé les bundles Mac (ressemblant comme des frères aux assemblages avec les méta-données, le code et les ressources) et les frameworks qui permettent d'installer une bibliothèque indépendemment des autres versions de la même bibliothèque. La seule différence c'est que sur mac on peut avoir un framework local à une application (dans le bundle) ou au niveau système dans une sorte de GAC.
Et ça c'est un net progrès pour ceux qui doivent déployer du code.
Et ça c'est ce que Dragonflybsd est en train de mettre au point de la manière la plus générale dans un cadre Unix traditionnel.
--
Michel TALON
Richard Delorme
La conclusion, c'est que je développe plus rapidement en C# aujourd'hui qu'en Delphi ou en C++ ou en Java (et donc je reviens moins cher..). En ces périodes à la délocalisation facile, mon choix est vite fait.
C'est un argument pour Python ou Ruby ça, pas pour le langage C#.
-- Richard
La conclusion, c'est que je développe plus rapidement en C# aujourd'hui
qu'en Delphi ou en C++ ou en Java (et donc je reviens moins cher..).
En ces périodes à la délocalisation facile, mon choix est vite fait.
C'est un argument pour Python ou Ruby ça, pas pour le langage C#.
La conclusion, c'est que je développe plus rapidement en C# aujourd'hui qu'en Delphi ou en C++ ou en Java (et donc je reviens moins cher..). En ces périodes à la délocalisation facile, mon choix est vite fait.
C'est un argument pour Python ou Ruby ça, pas pour le langage C#.
-- Richard
Laurent BERNE
Le prétendu échec en question c'est évidemment par rapport au nombre de développements en Visual Basic ou C++. La volonté de Microsoft était de faire basculer tout vers C#. Or ça ne s'est pas produit, selon tout ce qu'on peut lire. Ce n'est pas du tout contradictoire avec le fait qu'il existe un nombre non négligeable d'offres d'emploi pour C#.
Il y a même pas une semaine, un de mes collègues utilisateur de Delphi se plaignait que le soft qui était fourni avec son appareil numérique exigeait Dot Net pour fonctionner.. Dot net est déjà dans le grand public, mais comme c'est transparent (c'est installé par Windows Update) personne ne s'en rend compte, sauf le power user anti monopole qui verrouille tout (mais que fait il encore sous Windows ?). Au niveau internet, ca fait bien longtemps que je n'ai pas vu de site en ASP, ils ont quasi tous été remplacés par ASP.net (malgré le nom, ca n'a rien à voir.. l'un est en VBScript, l'autre en C# compilé..) Des éditeurs comme EBP migrent aussi leur produit vers Dot Net
de ligne (peut être pas dix fois non plus hein..). Simplement avec des notions comme le databinding par exemple. Ou par la richesse du framework.
La richesse des librairies qui sont autour, je crois que tout le monde est d'accord. Le problème c'est qu'il y a un "lock in" total sur ces librairies. Pas plus que celles sous Java, sous Borland, sous Windev même.
C'est les risques classiques du logiciel proprio. D'un autre côté, ces même lib divisent sensiblement le cout du développement. Chacun voit son intérêt. Pour ma part, ca me dérange pas de prendre ce genre de lib pour les zigouigouis graphiques qui font plaisir au client. Ce n'est qu'un front end, un truc pas important quoi.
Ne serait-ce que la possibilité d'utilser du code "Win32" classique et de l'invoquer dans Dot Net, et aussi l'inverse (par exemple faire des DLL en Dot Net et les utiliser dans des applis Win32)
Parcequ'il n'y a pas la possibilité de faire des extensions en C en Java ou en python? En python il y a même moyen d'entremêler complètement le C et le python, si on utilise pyrex. Pour le calcul scientifique c'est particulièrement intéressant parceque ça permet d'intégrer du code performant et largement testé avec un minimum d'efforts. python est un langage de script. Il est fait pour mapper des objets
déjà compilés.
Comparons ce qui est comparable. On parlait de Java non ? Java, je vois pas comment invoquer une DLL, donc du code DEJA COMPILE, et pas forcément en C où en C++. Le seul truc que j'ai vu, c'est JNI, et c'est d'une lourdeur pas possible.
N'importe quel programme sous Win32 est capable d'invoquer une DLL tierce en deux lignes de code. La première est l'appel à la fonction de l'API "loadlibrary" et la deuxième est "GetProcAdress" qui permet d'attribuer un pointeur de fonction sur la fonction désirée. De ce côté là, c'est pas Dot Net qui est en avance, c'est plutôt Java que je trouve en retard. Le cas typique, c'est justement le monde de l'industrie, dont vous parler tant. Souvent, les constructeurs de matériels ne fournissent qu'une DLL avec leurs équipements. C'est au codeur "maison" de faire l'applicatif qui utilise le matériel. J'ai jamais rencontrer Java pour faire cette interface.
La conclusion, c'est que je développe plus rapidement en C# aujourd'hui qu'en Delphi ou en C++ ou en Java (et donc je reviens moins cher..). En ces périodes à la délocalisation facile, mon choix est vite fait.
Ne t'inquiètes pas, s'il faut faire du C# pour décrocher des marchés, les Tchèques, Indiens et autres le feront tout aussi bien qu'ils se sont mis à Java et ça ne changera pas un iota à la problématique de la délocalisation. Je ne m'en fait pas, je reste moins cher qu'eux. C'est même un problème
d'ailleurs, car pour beaucoup de décideurs informatique, je ne parait pas crédible.. Mais bon leur expliquer que j'ai pas 36 marketteux , 45 secretaires et 250 actionnaires derrière moi, c'est un autre problème.
En attendant l'industriel qui aura mis le doigt dans l'engrenage du C#, et encore plus si ses ingénieurs utilisent des trucs non standard, comme des appels à des DLL, sera l'otage de Microsoft indéfiniment. Et ça finira par lui couter la peau des fesses, et dix fois plus que s'il avait développé son bidule en assembleur. En industrie, ce que j'ai vu le plus souvent, c'est du C, pas de
l'assembleur. En gros, c'est toujours le même principe : un drivers fait en C, et une interface graphique avec le bidule que l'electronicien manipule le mieux (j'ai même rencontrer du Windev...)
-- Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de creuser
Le prétendu échec en question c'est évidemment par rapport au nombre de
développements en Visual Basic ou C++. La volonté de Microsoft était de faire
basculer tout vers C#. Or ça ne s'est pas produit, selon tout ce qu'on peut
lire. Ce n'est pas du tout contradictoire avec le fait qu'il existe un nombre
non négligeable d'offres d'emploi pour C#.
Il y a même pas une semaine, un de mes collègues utilisateur de Delphi
se plaignait que le soft qui était fourni avec son appareil numérique
exigeait Dot Net pour fonctionner.. Dot net est déjà dans le grand
public, mais comme c'est transparent (c'est installé par Windows
Update) personne ne s'en rend compte, sauf le power user anti monopole
qui verrouille tout (mais que fait il encore sous Windows ?).
Au niveau internet, ca fait bien longtemps que je n'ai pas vu de site
en ASP, ils ont quasi tous été remplacés par ASP.net (malgré le nom, ca
n'a rien à voir.. l'un est en VBScript, l'autre en C# compilé..)
Des éditeurs comme EBP migrent aussi leur produit vers Dot Net
de ligne (peut être pas dix fois non plus hein..). Simplement avec des
notions comme le databinding par exemple. Ou par la richesse du
framework.
La richesse des librairies qui sont autour, je crois que tout le monde est
d'accord. Le problème c'est qu'il y a un "lock in" total sur ces librairies.
Pas plus que celles sous Java, sous Borland, sous Windev même.
C'est les risques classiques du logiciel proprio. D'un autre côté, ces
même lib divisent sensiblement le cout du développement.
Chacun voit son intérêt.
Pour ma part, ca me dérange pas de prendre ce genre de lib pour les
zigouigouis graphiques qui font plaisir au client. Ce n'est qu'un front
end, un truc pas important quoi.
Ne serait-ce que la possibilité d'utilser du code "Win32" classique et
de l'invoquer dans Dot Net, et aussi l'inverse (par exemple faire des
DLL en Dot Net et les utiliser dans des applis Win32)
Parcequ'il n'y a pas la possibilité de faire des extensions en C en Java ou
en python? En python il y a même moyen d'entremêler complètement le C
et le python, si on utilise pyrex. Pour le calcul scientifique c'est
particulièrement intéressant parceque ça permet d'intégrer du code performant
et largement testé avec un minimum d'efforts.
python est un langage de script. Il est fait pour mapper des objets
déjà compilés.
Comparons ce qui est comparable. On parlait de Java non ?
Java, je vois pas comment invoquer une DLL, donc du code DEJA COMPILE,
et pas forcément en C où en C++.
Le seul truc que j'ai vu, c'est JNI, et c'est d'une lourdeur pas
possible.
N'importe quel programme sous Win32 est capable d'invoquer une DLL
tierce en deux lignes de code.
La première est l'appel à la fonction de l'API "loadlibrary" et la
deuxième est "GetProcAdress" qui permet d'attribuer un pointeur de
fonction sur la fonction désirée. De ce côté là, c'est pas Dot Net qui
est en avance, c'est plutôt Java que je trouve en retard.
Le cas typique, c'est justement le monde de l'industrie, dont vous
parler tant. Souvent, les constructeurs de matériels ne fournissent
qu'une DLL avec leurs équipements. C'est au codeur "maison" de faire
l'applicatif qui utilise le matériel. J'ai jamais rencontrer Java pour
faire cette interface.
La conclusion, c'est que je développe plus rapidement en C# aujourd'hui
qu'en Delphi ou en C++ ou en Java (et donc je reviens moins cher..).
En ces périodes à la délocalisation facile, mon choix est vite fait.
Ne t'inquiètes pas, s'il faut faire du C# pour décrocher des marchés,
les Tchèques, Indiens et autres le feront tout aussi bien qu'ils se sont mis
à Java et ça ne changera pas un iota à la problématique de la délocalisation.
Je ne m'en fait pas, je reste moins cher qu'eux. C'est même un problème
d'ailleurs, car pour beaucoup de décideurs informatique, je ne parait
pas crédible.. Mais bon leur expliquer que j'ai pas 36 marketteux , 45
secretaires et 250 actionnaires derrière moi, c'est un autre problème.
En attendant l'industriel qui aura mis le doigt dans l'engrenage du C#, et
encore plus si ses ingénieurs utilisent des trucs non standard, comme
des appels à des DLL, sera l'otage de Microsoft indéfiniment. Et ça finira
par lui couter la peau des fesses, et dix fois plus que s'il avait développé
son bidule en assembleur.
En industrie, ce que j'ai vu le plus souvent, c'est du C, pas de
l'assembleur.
En gros, c'est toujours le même principe : un drivers fait en C, et une
interface graphique avec le bidule que l'electronicien manipule le
mieux (j'ai même rencontrer du Windev...)
--
Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de
creuser
Le prétendu échec en question c'est évidemment par rapport au nombre de développements en Visual Basic ou C++. La volonté de Microsoft était de faire basculer tout vers C#. Or ça ne s'est pas produit, selon tout ce qu'on peut lire. Ce n'est pas du tout contradictoire avec le fait qu'il existe un nombre non négligeable d'offres d'emploi pour C#.
Il y a même pas une semaine, un de mes collègues utilisateur de Delphi se plaignait que le soft qui était fourni avec son appareil numérique exigeait Dot Net pour fonctionner.. Dot net est déjà dans le grand public, mais comme c'est transparent (c'est installé par Windows Update) personne ne s'en rend compte, sauf le power user anti monopole qui verrouille tout (mais que fait il encore sous Windows ?). Au niveau internet, ca fait bien longtemps que je n'ai pas vu de site en ASP, ils ont quasi tous été remplacés par ASP.net (malgré le nom, ca n'a rien à voir.. l'un est en VBScript, l'autre en C# compilé..) Des éditeurs comme EBP migrent aussi leur produit vers Dot Net
de ligne (peut être pas dix fois non plus hein..). Simplement avec des notions comme le databinding par exemple. Ou par la richesse du framework.
La richesse des librairies qui sont autour, je crois que tout le monde est d'accord. Le problème c'est qu'il y a un "lock in" total sur ces librairies. Pas plus que celles sous Java, sous Borland, sous Windev même.
C'est les risques classiques du logiciel proprio. D'un autre côté, ces même lib divisent sensiblement le cout du développement. Chacun voit son intérêt. Pour ma part, ca me dérange pas de prendre ce genre de lib pour les zigouigouis graphiques qui font plaisir au client. Ce n'est qu'un front end, un truc pas important quoi.
Ne serait-ce que la possibilité d'utilser du code "Win32" classique et de l'invoquer dans Dot Net, et aussi l'inverse (par exemple faire des DLL en Dot Net et les utiliser dans des applis Win32)
Parcequ'il n'y a pas la possibilité de faire des extensions en C en Java ou en python? En python il y a même moyen d'entremêler complètement le C et le python, si on utilise pyrex. Pour le calcul scientifique c'est particulièrement intéressant parceque ça permet d'intégrer du code performant et largement testé avec un minimum d'efforts. python est un langage de script. Il est fait pour mapper des objets
déjà compilés.
Comparons ce qui est comparable. On parlait de Java non ? Java, je vois pas comment invoquer une DLL, donc du code DEJA COMPILE, et pas forcément en C où en C++. Le seul truc que j'ai vu, c'est JNI, et c'est d'une lourdeur pas possible.
N'importe quel programme sous Win32 est capable d'invoquer une DLL tierce en deux lignes de code. La première est l'appel à la fonction de l'API "loadlibrary" et la deuxième est "GetProcAdress" qui permet d'attribuer un pointeur de fonction sur la fonction désirée. De ce côté là, c'est pas Dot Net qui est en avance, c'est plutôt Java que je trouve en retard. Le cas typique, c'est justement le monde de l'industrie, dont vous parler tant. Souvent, les constructeurs de matériels ne fournissent qu'une DLL avec leurs équipements. C'est au codeur "maison" de faire l'applicatif qui utilise le matériel. J'ai jamais rencontrer Java pour faire cette interface.
La conclusion, c'est que je développe plus rapidement en C# aujourd'hui qu'en Delphi ou en C++ ou en Java (et donc je reviens moins cher..). En ces périodes à la délocalisation facile, mon choix est vite fait.
Ne t'inquiètes pas, s'il faut faire du C# pour décrocher des marchés, les Tchèques, Indiens et autres le feront tout aussi bien qu'ils se sont mis à Java et ça ne changera pas un iota à la problématique de la délocalisation. Je ne m'en fait pas, je reste moins cher qu'eux. C'est même un problème
d'ailleurs, car pour beaucoup de décideurs informatique, je ne parait pas crédible.. Mais bon leur expliquer que j'ai pas 36 marketteux , 45 secretaires et 250 actionnaires derrière moi, c'est un autre problème.
En attendant l'industriel qui aura mis le doigt dans l'engrenage du C#, et encore plus si ses ingénieurs utilisent des trucs non standard, comme des appels à des DLL, sera l'otage de Microsoft indéfiniment. Et ça finira par lui couter la peau des fesses, et dix fois plus que s'il avait développé son bidule en assembleur. En industrie, ce que j'ai vu le plus souvent, c'est du C, pas de
l'assembleur. En gros, c'est toujours le même principe : un drivers fait en C, et une interface graphique avec le bidule que l'electronicien manipule le mieux (j'ai même rencontrer du Windev...)
-- Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de creuser
Laurent BERNE
donc conclution pour grandir il faut etre bon mais si on est grand on est mauvais .
Une fois qu'on est devenu grand, oui, on est probablement condamné à une certaine forme de médiocrité créative, alors les grosses boîtes rachètent les petites innovantes pour avoir leurs idées à exploiter.
J'ai tendance à penser que plus une organisation devient conséquente, elle s'enlise dans les procédures et la hierarchie. C'est pas qu'elles soient particulièrement mauvaise, mais quand chaque innovation doit avoir l'aval du service marketting, prévoir un financement avec le service compta, faire la mise au point avec le service qualité, préparer la mise sur le marché avec le service communication, verifier que tout est légal avec le juridique,parfois entrer en compétition interne avec une autre innovation sans compter même que la probabilité d'avoir des "petits chefs" augmente exponentiellement en fonction de la longueur de la chaine hierarchique..
C'est évident que les petites structures sont plus dynamiques, donc plus efficaces.
-- Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de creuser
donc conclution pour grandir il faut etre bon mais si on est grand on
est mauvais .
Une fois qu'on est devenu grand, oui, on est probablement condamné à une
certaine forme de médiocrité créative, alors les grosses boîtes
rachètent les petites innovantes pour avoir leurs idées à exploiter.
J'ai tendance à penser que plus une organisation devient conséquente,
elle s'enlise dans les procédures et la hierarchie.
C'est pas qu'elles soient particulièrement mauvaise, mais quand chaque
innovation doit avoir l'aval du service marketting, prévoir un
financement avec le service compta, faire la mise au point avec le
service qualité, préparer la mise sur le marché avec le service
communication, verifier que tout est légal avec le juridique,parfois
entrer en compétition interne avec une autre innovation sans compter
même que la probabilité d'avoir des "petits chefs" augmente
exponentiellement en fonction de la longueur de la chaine
hierarchique..
C'est évident que les petites structures sont plus dynamiques, donc
plus efficaces.
--
Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de
creuser
donc conclution pour grandir il faut etre bon mais si on est grand on est mauvais .
Une fois qu'on est devenu grand, oui, on est probablement condamné à une certaine forme de médiocrité créative, alors les grosses boîtes rachètent les petites innovantes pour avoir leurs idées à exploiter.
J'ai tendance à penser que plus une organisation devient conséquente, elle s'enlise dans les procédures et la hierarchie. C'est pas qu'elles soient particulièrement mauvaise, mais quand chaque innovation doit avoir l'aval du service marketting, prévoir un financement avec le service compta, faire la mise au point avec le service qualité, préparer la mise sur le marché avec le service communication, verifier que tout est légal avec le juridique,parfois entrer en compétition interne avec une autre innovation sans compter même que la probabilité d'avoir des "petits chefs" augmente exponentiellement en fonction de la longueur de la chaine hierarchique..
C'est évident que les petites structures sont plus dynamiques, donc plus efficaces.
-- Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de creuser
Laurent BERNE
Il y a même pas une semaine, un de mes collègues utilisateur de Delphi se plaignait que le soft qui était fourni avec son appareil numérique exigeait Dot Net pour fonctionner.. Desolé, j'ai oublié un mot :
il fallait lire "appareil photo numérique"
-- Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de creuser
Il y a même pas une semaine, un de mes collègues utilisateur de Delphi se
plaignait que le soft qui était fourni avec son appareil numérique exigeait
Dot Net pour fonctionner..
Desolé, j'ai oublié un mot :
il fallait lire "appareil photo numérique"
--
Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de
creuser
Il y a même pas une semaine, un de mes collègues utilisateur de Delphi se plaignait que le soft qui était fourni avec son appareil numérique exigeait Dot Net pour fonctionner.. Desolé, j'ai oublié un mot :
il fallait lire "appareil photo numérique"
-- Ce n'est pas parce que tu touches le fond que tu dois t'arrêter de creuser
