Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
l'argument quand on a rien à y redire.Envoyé par Keihilin
/me cherche un smiley capable de traduire son état d'esprit face à cette affirmation...
ah voilà :
On attends encore des tests pour les perfs car pour l'instant cela parle sans prouver quoique se soit...
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Je ne vois pas non plus l'ombre d'un début de preuve (et même d'exemple) dans ton propos...
Par contre un truc que j'entend régulièrement en confidence c'est
"L'équipe (anciens VBistes) ne comprend rien aux generics/closures/lambdas/wcf/autrenouveautécomplexifiante donc on va pas s'embêter à migrer en 2.0/3.5"
j'imagine que blâmer la stabilité est plus politiquement correct...
In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.
Ce n'est pas une preuve juste un témoignage de 2 chef d'équipes de projet dans une ssii qui travaillent sur .NET depuis....le début
Tu as peut-être raison et peut-être tort en tout cas dans cette ssii on utilise le 1.1 basta."L'équipe (anciens VBistes) ne comprend rien aux generics/closures/lambdas/wcf/autrenouveautécomplexifiante donc on va pas s'embêter à migrer en 2.0/3.5"
j'imagine que blâmer la stabilité est plus politiquement correct...
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Je t'invite à faire un sondage pour savoir quelle version est utilisée en entreprise comme cela on pourrait se faire une idée
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
Il y a déjà eu des sondages sur quelques blogs et, sauf erreur, sur codeproject.
Le 2.0 devient la norme, mais le 1.1 est effectivement encore très présent, voir majoritaire et le 3.5 reste l'apanage des "early adopters".
Je ne conteste pas ce fait, c'est l'argument de la stabilité qui me fait rire aux éclats.
Les raisons des lenteurs d'adoption (hormis la complexification qui en rebute certains) est plutôt à chercher du côté des coûts...puisque (merci Microsoft) il faut repasser par la case achat de licences Visual Studio pour passer de 1.1 à 2.0 et de 2.0 à 3.5 !!
Ajoute à ça que sur mon marché les "leaders" technologiques sont généralement les banques et autres institutions financières dans lesquelles l'environnement informatique est archi-contrôlé et où la moindre évolution doit faire l'objet de processus de tests et acceptation qui prennent des mois, voir des années, et tu comprends pourquoi une technologie de plus de 5 ans reste majoritairement déployée...
In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.
Il faut dire aussi que la stabilité c'est un facteur un peu difficile à démontrer d'ailleurs il ne me semble pas qu'il fasse parti de ceux définis dans la norme iso en ce qui concerne la qualité de logiciel.
Pour l'argumentation du coût de la licence. Mais si c'est tellement attrayant le .NET 3.5 ou le 2.0 on devrait voir un retour sur investissement assez rapidemment (qualité et coût) non il y a comme un doute alors ce n'est pas sûr parce que du coup là se serait vraiment pour la mode wcf/machinchosebidule....
Pour l'argumentation des environnements archi-contrôlé ok je comprends que c'est de la faute des leaders. Je reconnais là des pratiques dans ma SSII faire des TA pendant des mois et je trouve que c'est pure connerie que cela dure aussi longtemps (voir la catastrophe des modèles en cascade). Du coup le problème que je vois ce n'est plus la version du framework mais celles des informaticiens un peu malmené par les gens du métiers hein...
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
L'argument de stabilité ne s'applique pas au runtime seul, mais au runtime + le parc d'application existant.
Malgré tous les efforts de compatibilité ascendantes, chaque nouvelles versions apportent son lot d'incompatibilité avec les programmes existants, que ce soit au niveau source ou binaire. Cela peut aller d'un détail anodin à des changement plus important, mais quoi qu'il en soit cela peut impacter les programmes existantes. Ainsi Sun publie à chaque nouvelle version une liste des incompatibilités connus, mais il est également possible d'en retrouver d'autres, ou tout simplement que cela réveille un bug caché
Bien sûr dans 95% des cas il n'y aura aucun problème. Mais lorsqu'on maintient un gros parc d'application, le moindre problème peut s'avérer très coûteux, ce qui fait que l'industrie tarde à adopter les nouvelles versions et considère une version dite stable... mais cela ne veut pas dire que la version suivante n'est pas stable pour un nouveau projet.
Penses simplement à ceci : Tu as un parc informatique constitué de plusieurs applications développées avec le runtime 1.1 et fonctionnant de manière stable.
Je te rassure c'est un phénomène que l'on retrouve également avec Java
a++
Je parlerais plus de compatibilité que de stabilité.
Face à cette phrase :
je comprend que le 1.1 est stable et que les 2.0 et 3.5 ne le sont pas, hors toutes considérations de compatibilité...Comme lorsque l'on dit "mon application en version alpha 0.4 n'est pas stable".
Ca dépend de plusieurs facteurs, parmi lesquels la manière dont les applications ont été développées et la manière dont elles communiquent entre elles (si elles communiquent).Penses simplement à ceci : Tu as un parc informatique constitué de plusieurs applications développées avec le runtime 1.1 et fonctionnant de manière stable.
Mais généralement, grâce à une compatibilité ascendante plutôt bonne et au fait que les frameworks peuvent cohabiter sans problèmes sur une même machine, les migrations se passent bien.
Tout autre chose adi, j'aimerais que tu m'éclaires sur un point : si la JVM server est à ce point plus rapide, pourquoi n'est-elle pas la JVM par défaut ? La seule et unique ?
++
In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.
La JVM client se charge plus rapidement et est plus performante pour les interfaces utilisateurs.
Oui on se comprend bien
C'est pour cela que j'ai dit que ce n'est pas le runtime qui n'est pas stable, mais le couple runtime+applications.
Par contre il n'est pas rare de simplifier cela en distant que c'est le runtime qui n'est pas assez mure ni assez stable
Oui dans de nombreux cas le problème vient des applications...
En général oui... mais en entreprise la mise à jour d'un parc informatique n'est pas toujours simple. D'autant plus lorsqu'il s'agit d'application au cœur même du métier.
La JVM client est plus rapide à démarrer (même si ce n'est plus forcément aussi visible), en s'adaptant progressivement pendant l'exécution (le code n'est optimisé que s'il est souvent utilisé, ce qui offre des performances plus que correcte dans la plupart des cas).
A l'inverse la JVM server est plus longue mais apporte des optimisation beaucoup plus poussé. C'est surtout intéressant pour des tâches répétitives et pour des applications à longue durée de vie...
Par contre la JVM client n'est pas forcément la JVM par défaut, et la JVM server commence à prendre le dessus. En fait depuis Java 5.0 (fin 2004) on distingue 3 cas :
- Sous Windows en 32bits c'est la JVM client qui est utilisé. D'ailleurs la JVM server n'est pas distribué avec le runtime mais seulement avec le JDK.
- Sous les autres systèmes en 32bits, la JVM par défaut est déterminé selon le type de machine (server si on est au moins sur un bi-processeur avec + de 2 Go de Ram, client sinon).
- Enfin, les versions 64bits ne disposent que de la version server (quel que soit le système)
A noter également que dans les cartons de Java 7 on retrouve un mode "Tiered Compilation" qui devrait permettre de cumuler les avantages des deux JVM
a++
Sinon par rapport aux tarifs des licences VS dont parlait Keihilin.
J'ai l'impression que Java marque un point non négligeable de ce côté avec ses éditeurs gratuits comme eclispse et netbeans.
Je ne sais pas si les leaders Java utilisent ces EDI (leaders dans le même sens dont l'entendait Keihilin) parce que cela ferait une sacré économie au niveau des coûts effectivement qui peut vite se chiffrer en million sur un projet rien que pour l'acquisition des licences.
Un peu de comparaison syntaxique/technique et un peu de comparaison des coûts. Pour 200 000 euros je ne dis pas non de changer de langage/techno
" Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]
J'ai donc répondu : "Autre avis ? (précisez...)"
C'est toujours amusant, les sondages, quand ils ne sont pas anonymes (pas complètement du moins, puisqu'on peut voir nos pseudos respectifs)...
Encore plus sympathique, c'est quand la question ne mène pas à une liste de réponses "fermée" ... (d'où ma réponse ci-dessus...) et que cette question se veut, volontairement, explicitement, la source d'un débat.
La question est donc : "C# vs Java -- Quel est le meilleur des deux langages selon vous ?"
Et mon "autre avis (précisez...)" ne sera pas : "parce que le meilleur langage, pour moi, en fait, c'est ***" (avec ou non arguments à l'appui sur le langage heureux élu)
Reprenons la question :
il s'agit d'évaluer ce qui est LE meilleur langage informatique entre deux, et de relier cette évaluation personnelle à une "raison" parmi :
(i) Je suis intéréssé par Java et C#
(ii) C#
(iii) Java
(iv) J'apprécie le fait d'avoir l'alternative Java ou C#
(v) Ni l'un ni l'autre
(vi) Sans Opinion
(vii) Autre avis
et il m'a semblé logique de répondre (vii), parce que j'aurais en fait aimé pouvoir répondre : (i) et (iv) et (v).
En effet, mon sentiment est qu'on (je, en tout cas) ne peut pas vraiment mettre ces deux langages, à la fois très similaires, mais également, significativement "concurrents" sur certains aspects (syntaxiques et sémantiques), sur une même échelle, avec une relation d'ordre, l'un (le "meilleur" ) au-dessus de l'autre.
Ce sentiment que je ne peux pas élaborer ici complètement sans ouvrir un autre débat qui nous éloignerait sensiblement du sujet présent, m'a donc fait éliminer : (ii) et (iii) ; quant à (vi) : eh bien puisque j'ai un "autre avis", j'ai éliminé aussi...
Mais je termine quand même sur le pourquoi je ne peux pas vraiment choisir un "meilleur" entre les deux, brièvement :
pour moi, c'est précisément la "tension" entre, à la fois :
a) les similarités des objectifs de conception, le paradigme (objet), la plateforme (à base de VM / code intermediaire, etc), la syntaxe, etc
ET
b) le fait que ces deux langages ne sont avant tout que des artefacts logiques (lire : en tant que systèmes logiques exécutables par une machine) créés par des humains (sisi, les informaticiens sont aussi des humains...) qui ont tenté d'adresser un grand ensemble de problématiques communes, et en faisant dans chaque cas des hypothèses très proches, mais cependant, en arrivant à des conclusions / des priorités / des solutions parfois significativement différentes.
Or, Java est arrivé, dans le temps, le premier ; et dans toute activité intellectuelle humaine, l'appréhension d'un même paradigme, des mêmes problématiques, etc, est amha, trop fortement dépendante du contexte historique humain lui même (enjeux commerciaux, et provenance, passé, et expérience des chercheurs, etc), entre l'apparition et le développement du premier, Java, jusqu'à l'apparition 6 ou 7 ans plus tard du second, C#.
L'existence de cette "tension" conceptuelle entre les similarités et leur nature d'artefacts différents conçus par des humains pour "la même machine" (en gros, la machine abstraite de Turing), et le fait qu'il y ait eu un laps de temps aussi important (sur l'échelle de temps du domaine informatique) suffit à ne pas me permettre de décider du "meilleur" de façon "fair play", entre les deux "concurrents". Certes, les avancées en matière de logiciel arrivent beaucoup plus "lentement" qu'en matière de matériel, surtout en termes d'industrialisation, dont on ne fait principalement que continuer de parler / débattre pour le logiciel, tandis qu'elle est faite depuis longtemps pour le hardware... Mais : il ne faut pas non plus amha sous estimer les avancées, a minima, "conceptuelles", en matière de production de code dans un langage (pensez aux design patterns, dont l'idée a été formalisée / systématisée bien plus récemment que le paradigme objet lui même -- un des premier langage à objets fut Simula 67, par ex)
Ainsi, si Java et C# étaient "apparus" (pensés, conçus) en même temps, ou quasi en même temps, en 93/94, qui dans les labos de Sun, qui dans ceux de Microsoft, alors là, oui, peut être pourrais je avoir une préférence plus tranchée sur l'un ou l'autre, étant donnée une liste de critères qui se voudraient objectifs car mesurables (dans le temps ou l'espace, sur l'usage à travers différents types de projets, etc)
Mais seulement voilà : C# et sa plateforme sous jacente, informé de l'expérience du prédecesseur Java, a choisi cette orientation (que nous connaissons) qui par beaucoup d'aspects me ferait tendre à sous estimer l'apport de Java à cause de maladresses de jeunesse de celui ci ; et inversement, la précédence de Java dans l'introduction de certaines idées / concepts, et techniques concrètes me ferait tendre à sous estimer l'apport de C# dans les modalités où celui ci a réutilisé, en les adaptant / augmentant de manière intéressante, les propriétés de la syntaxe et de la sémantique Java.
En espérant que mon "blabla intuitif (mais pas tant que ça...)" ne fut pas totalement dénué de sens...
...My 2 cents.
[ EDIT ]
Meilleurs voeux à tous pour 2009.
I do believe in Software Factories that do the job.
Domain-Specific Languages * .NET =
Then, what's next ?
Pour ajouter quelque chose à votre contribution, derrière un langage il y a (on l'oublie bien souvent) une philosophie et des décideurs (des humains).
Ainsi, dans le temps un langage peut évoluer en bien ou en mal selon des critères qui ne sont pas entièrement objectifs pour tenter de répondre aux besoins.
Il s'agit donc bien d'un outil qui prendras plusieurs formes avant qu'une approche précise se montre dominante. C'est le même processus de diversification et de sélection que l'on peut voir dans de nombreuses activités humaines où l'on tente de repousser les limites techniques.
Ce qui est certain c'est que les choix d'aujourd'hui aurons une incidence sur l'avenir. Aujourd'hui nous en sommes encore à manier des lignes du texte et demain l'approche sera peut être totalement différente. Mais certains conceptes de base resterons d'actualité car elles aurons fait leurs preuves par le passé.
Espérons donc que ce cycle de va et viens continue, et que d'autres langages concurrents verrons le jour à l'avenir pour apporter leurs propres contributions. Car, sans cela, je suis d'avis que seul la stagnation est possible. Il s'agit bien d'un processus d'évolution tel celui qui a contribué à l'émergence de la vie sur terre.
Développeur en devenir.
A la recherche de toute source approfondissant Merise, UML, Java, l'objet, les design patterns hors GOF et le développement en général.
Recherche également des informations sur les techniques de développement et les bonnes pratiques en terme de programmation en entreprise.
"On en apprends beaucoup plus par la confrontation que par la conciliation"
Oui. J'y ai fait une brève allusion en parlant de la provenance, de l'expérience des chercheurs/inventeurs des langages de programmation.
Tout à fait. Meyer, lors de sa discussion sur le processus de conception de "son" langage Eiffel (il en fut le premier concepteur principal), tient compte et adresse (par son expérience et opinions) ce problème de certains langages de programmation, qui par le passé, ont souffert des "conceptions en comités", où tout le monde / où chacun insiste pour mettre dans la syntaxe et/ou la sémantique du langage telle ou telle fonctionnalité, indispensable pour eux... Des fonctionnalités qui se révèlent être finalement un alourdissement, une complexification inutile pour le langage, réduisant ainsi ses chances d'adoption par le plus grand nombre quand ce n'est pas tout simplement... son utilité, sa simplicité d'utilisation elle même pour la puissance expressive initialement espérée...
Tout à fait.
Oui. Et ma foi, même si ceux ci sont appelés à être en petit nombre, ceux du paradigme objet ont de bonnes chances d'en faire partie, amha... non ?
Je ne m'inquiète pas trop là dessus...
... ça devient presque philosophique mais je suppose que c'est effectivement proche de ce qui se passe réellement ; l'évolution biologique a probablement un pendant dans l'évolution intellectuelle humaine ; et, oui, j'aurais tendance à dire que la diversité associée aux enjeux de la compétition d'idées, dans les langages informatiques comme pour le reste, est une assez bonne garantie pour créer toujours plus de... diversité.
A ce titre, l'apparition du monde "open source" est amha très probablement...
... au moins : une assez bonne nouvelle.
I do believe in Software Factories that do the job.
Domain-Specific Languages * .NET =
Then, what's next ?
Je reviens sur cette partie de l'argumentaire entre hegros et Keihilin, sur la dimension "coût" -- comparatif Java vs. .NET.Sinon par rapport aux tarifs des licences VS dont parlait Keihilin.[...]Un peu de comparaison syntaxique/technique et un peu de comparaison des coûts. Pour 200 000 euros je ne dis pas non de changer de langage/techno
Perso, en 13 ans passés dans l'informatique au moins pour le gagne-pain, liés au développement logiciel proprement dit, avec une charge de mes fonctions sur ses tâches (analyse et/ou conception et/ou implémentation) que j'évalue à entre 60 % et 100 % de mon temps "salarié" (ou autre rémunération) pendant ces années, et dont les 8 dernières années au moins ont été passées à plus de 90 % sur Windows et plus de 60 et quelques % sur .NET, je ne vais vraiment pas pouvoir faire de remarques utiles sur Java-la-plateforme-et-les-EDI (sur- ou hors-Windows) autres que celles d'un observateur de Java "passif".
Mais mon sentiment, pour ne traiter donc que de ce .NET, et malgré un véritable "open source boom" qui n'a rien à envier à ceux que Java et d'autres langages/plateformes peuvent connaître (bon, toutes proportions respectées / ramenées à des échelles de temps comparables parce que Java a près de 15 ans déjà (env.) et .NET seulement 10 (env., bis) ), est que le problème est largement plus humain que technique.
Je veux dire ; et si je ne me trompe pas :
* Microsoft Windows => soumis à licence (payante)
* Visual Studio => idem OS ; et souvent considéré "cher" par certaines petites (voire grandes) structures
* .NET framework et runtime (version MS pour Windows, dont cet OS n'est qu'un pré requis) => gratuit
Or, soyons honnêtes et ne jouons pas les prudes ou les naifs : il suffit de savoir lire ; genre, pour commencer, les annonces d'offres d'emplois pour développeurs (confirmés/expérimentés/seniors, bref tout sauf "débutants" ) et, "encore plus mieux, plus fort", pour "architectes", tous estampillés à la même enseigne ".NET", "sur les dernières technologies/librairies (.NET)" (MS ou autres, mais globalement de plus en plus souvent open source) :
tout le monde ou presque parle "d'industrialisation", à travers le controle source, le build, la gestion de conf, etc, plus ou moins explicitement, et quand c'est explicite on s'en gargarise en arguant du fait qu'avec .NET, framework "reflectif" / extensible, bref super "moderne", "on" (les architectes) est capable de mettre en oeuvre cette "industrialisation" au moins aussi bien que Java... mais... ahh, oui, c'est triste, par contre, Microsoft, ça coute cher, même ne serait-ce pour le développement "pur"...
"But... (?) heh, wait a minute."
"Y'a pas comme un hic ?" : on vient de se rappeler en se tapant le front de la main bon sang mais c'est bien sur que le framework .NET sauce MS pour Windows se télécharge gratuitement lui aussi... et qu'il y a une foultitude de frameworks open source eprouvés Java portés (ou réécrits) pour .NET... sans parler d'autres initiatives quasi originales ("quasi" car rien n'est vraiment "original" en matière de logiciel, si on y regarde de près) et même des EDIs gratuits et eux même extensibles (SharpDevelop en est un), et... etc, etc. qui s'appuient tous sur ledit framework.
Alors ?!? D'où vient qu'on devrait accepter comme triste, inéluctable fatalité que, quelque part, .NET, sur MS Windows, sera toujours "plus cher" que Java, sur ce même OS à cause des licences des outils ? Seulement pour ça : produire le code.
A la rigueur, si on me parlait de comparer .NET sur Windows à Java sur Linux, je voudrait bien hausser les epaules et repondre, de bonne foi, même si c'est très naivement (car inexpérimenté et pas plus informé outre mesure) : "ah ben oui, ok, vu, dans leur cas l'OS et la plateforme et leurs EDIs et les frameworks qu'ils utilisent sont 'gratuits', et dans le notre, notre Windows au moins, et souvent notre EDI, VS, eux au moins, on doit les payer... C'est pas de chance."
Ou encore, on pourrait imaginer l'experience de pensée, a l'instar des philosophes antiques (ou pas antiques) :
imaginons que Microsoft aient "locké" une partie des plus "hi tech" des fonctionnalités du framework (genre quelques namespaces System.Quelquechose.Blabla) dans un composant / assembly si bien obfusqué qu'il resisterait a toute forme de reverse engineering, et qui serait seulement livré (et donc soumis à licence) avec Visual Studio... là, oui, ça serait pas cool... et oui, peut etre que pour quelquechose comme 10 % de tous les projets possibles et imaginables, les gens n'auraient pas le choix et devraient tristement depenser des sousous qu'ils auraient pu economiser avec Java.
Mais non, ils ne l'ont pas fait bien sûr ; cela aurait été stupide de leur part pour maintenir leur business a base Windows * (X $ licences) + .NET * (zéro $) seulement, beaucoup plus important, je suppose, que le business Visual Studio seul (aussi développé qu'il puisse être) ; le beurre de Microsoft vient d'abord de leur OS, de leur plateformes (Office, Live, etc), de leurs jeux, etc.
Il y a largement moins de "vaches à lait" de la classe "développeurs sous Windows + .NET + Visual Studio" que de la classe "utilisateurs Windows avec ou sans .NET" sur terre. Ou alors, personne ne m'a encore rien dit...
Et encore non, bis repetita : on parle de comparer Java sur Windows vs. .NET sur Windows ; et on rabache a tout va que tout ce qu'ils font sur Java dans leur EDIs gratuits, avec SVN, Ant, etc, on peut faire idem (ou très proche) sur .NET dans un SharpDevelop ou d'autres de la meme veine, avec le meme SVN, le NAnt (au lieu de Ant), etc...
Je commence à me dire qu'en fait, sciemment ou non, nous sommes beaucoup a faire preuve d'une bonne dose d'hypocrisie, si on remet ces données en contexte de (en quelque sorte) "notre profession de foi" relativement à .NET.
En effet, pour revenir aux notions d'industrialisation (avec méthodologies, méthodes, processus, analyse / conception, Merise ou non, modélisations, MDA ou non, et tutti quanti) j'ai toujours du mal me faire convaincre que ce n'est pas anormal, quelque part, que nous tous, "soi disants architectes", tout ambitieux que nous sommes, ne soyons toujours pas capables de construire (ou au moins, d'adapter de maniere utile, car organisée, progressive) des outillages à base d"EDIs gratuits, pour accélérer de façon claire, objective, la production du code "à grande échelle".
Mais non... beaucoup d'entre nous (svp, notez que je ne jette la pierre à personne, et je suis le dernier à me moquer en quoi que ce soit, j'essaie de me placer plus sur le plan de la constatation) choisissons la solution de facilité :
"woa, le framework 3.5 avec Linq, EF, WCF, etc yaddayaddayadda, c'est super ! ... bon, ok, on part là dessus... oh, zut, il nous faut le dernier VS 2008 pour en profiter pleinement ?... aie, bon ok... *soupir* etc etc"
C'est là le hic.
D'après moi, c'est un problème stratégique d'évaluation / d'optimisation des investissements / coûts liés :
* au prix réel de la plateforme technique : prix des licences OS et hors OS (et là, certes, Visual Studio n'est pas gratuit, mais il y a d'autres EDIs)
* à la montée réelle en compétences, objective, mesurable (et pour cela il faut commencer par choisir des critères sur une plage de temps) versus "le blabla-langue-de-bois-a-la-sauce-.NET-que-Java-a-connu-en-son-temps", concernant ceux qui veulent se faire appelés "architectes logiciel", et qui, d'après moi et entre autres fonctions, ne doivent pas perdre de vue que l'architecture logicielle, ce n'est pas seulement celle de l'applicatif "alimentaire" du projet X ou Y, c'est aussi et peut être surtout (pour "le long" terme) l'architecture du tooling autour des EDIs et autres briques de la chaine de production du code que la force de développement utilise tous les jours (*).
Force est de reconnaitre que la tendance la plus courante reste, pour ce que j'ai vu moi même en tout cas, une sorte de résignation à acheter la licence de la dernière version de Visual Studio sans vraiment d'etude sérieuse, digne de ce nom, sur l'apport réel et la nécessité objective d'utiliser cette version.
Il faut savoir ce qu'on veut : on veut ne pas etre pieds et poings liés vis à vis de MS et leur EDI, a cause du surcout prohibitif (pour notre "modeste" budget) lié au prix des licences versions N, N+1, N+2, etc ?
Eh bien soit : il faut alors assumer et investir en R & D pour faire en sorte de se reorienter vers un EDI bien moins cher car gratuit, mais que l'on devra probablement adapter pour le type de code applicatif et de briques .NET que l'on utilise... Un tel investissement semblera peut etre plus important sur un ou deux projets plutot que d'acheter "en aveugle" le dernier Visual Studio 2010/2012, etc, mais j'ai du mal a voir comment une telle stratégie ne serait pas plus censée, logique, sur le long terme, si on veut effectivement reduire les couts de mise en oeuvre de la production du code.
My 2 cts.
[ EDIT ] (*)
"architecte logiciel" (ma propre définition, courte mais j'espère précise, mais peut être un peu "brutale" ou péremptoire pour certains) :
"celui qui a en charge les études, la définition et la mise en oeuvre des architectures logicielles nécessaires et suffisantes, prises au sens large (i.e, cibles applicatives métier et outils), pour la production des applications du domaine (métier) de son employeur"
si on accepte ma définition, mon sentiment est donc que la grande majorité desdits "architectes logiciels" spécialisés sur .NET aujourd'hui sous estiment (ou oublient, ou detourne les yeux de...) la partie "outils" de leur mission, et ce malgré le potentiel, affiché, expliqué, argumenté (MSDN, autres...) d'extensibilité du framework et des outils qui s'appuient dessus, par construction même dudit framework ; préférant alors dépenser l'argent alloué en licences MS Visual Studio plutôt qu'en R & D, sans même envisager cette dernière ; si la dimension "budget" des projets qui utilisent leur architectures se révèle critique de manière répétée, précisément à cause du prix des licences, c'est alors amha ... un mauvais calcul de leur part ; et l'argument selon lequel .NET serait "à priori" (et tristement) plus cher que Java, sous Windows, à cause de l'EDI, devient caduque s'il sort de leur bouche, amha.
Comment en effet ne pas être péremptoire sur cet aspect ".NET vs Java / coûts" quand on commence d'emblée par exclure a priori ces possibilités qui privilégient la R & D sur des licences existantes, déjà payées, à l'achat des nouvelles ? Je ne vois pas...
Si "l'architecte logiciel" est frileux sur ces questions, je ne vois pas qui d'autre dans l'entreprise pourra ne pas l'être à sa place (?!)
Ainsi, amha, la R & D peut bien sûr être plus couteuse, mais cela doit être démontré, ou au moins, évalué avant, en toute honneteté intellectuelle. Ou encore : "qui ne tente rien n'a rien"...
Enfin, je ne dis pas qu'il faut systématiquement chercher a réinventer "la roue de l'EDI" mais sur N projets (N > 3 ou 4), il est probablement plus intéressant d'avoir développé un tooling maison adapté, conçu avec soin, pour la version N - 2 de Visual Studio, sur 4 ans, ou pour un autre EDI carrément gratuit celui là, sur la même période, que de passer "les yeux fermés" à la version N de VS après deux ans, puis à la N + 2 après 4 ans ; coincidence... .NET 2.0 et VS 2005 ont tous deux 4 ans déjà... qui peut dire avoir eu du succès avec la 1ère approche plutôt qu'avec la seconde ? c'est un autre sondage qu'il serait surement intéressant de mener...
I do believe in Software Factories that do the job.
Domain-Specific Languages * .NET =
Then, what's next ?
Je suis un fervent admirateur des deux.
Historiquement, Java représente pour moi :
La démocratisation à grande échelle de la POO
Des avancées phénoménales sur les logiques de framework et d'usines logicielles
La preuve évidente qu'une communauté d'utilisateurs responsabilisée peut faire avancer un projet
Java pour moi, sans l'être, c'est mon premier langage. Celui qui m'a fait découvrir l'aspect "jouissif" de développer, d'abstraire, de penser "utilisateur".
Java a fait murir le web dans le monde de l'entreprise, a révolutionné le développement d'applications distribuées, a révolutionné aussi le monde la persistence.
Strut, spring, jsf, jpa, hibernate, jboss, tomcat, swing,swt...Le flux d'innovation est constant; la communauté toujours solide.
Et .NET, c'est un peu pour moi le mal nécessaire. Comprendre que j'aime .NET et que je pense qu'il est nécessaire que .NET et Java existent, pour l'émulation et l'innovation.
Alors que C# est largement inspiré de Java, et heljsberg a probablement là tiré les erreurs de J#; c'est aujourd'hui devenu un langage puissant, avec des démarquations fortes.
Ce qui freine un peu .NET c'est la logique "in house" de microsoft, là ou java à réussi son pari de la portabilité (rien n'est parfait, mais si la perfection existait, nous le saurions tous depuis longtemps)
Ce qui freine surtout .NET, c'est sa communauté "attentiste", qui attend que l'outillage soit produit par Microsoft.
On peut faire des choses dans le communautaire microsoft avec les DSL, Codedom, DLR, ...Et ça existe.
Autre points, il est évident que la démarche de conception objet est fortement issue du Java. Les jalons y sont historiquement posés.
Pour la question des coûts...Bofs, faux sujet, avec la politique ISV de microsoft, ma société utilises tous les derniers produits sans coûts (team foundation, team developper, team database, sql 2008, server 2008).ne soyons toujours pas capables de construire (ou au moins, d'adapter de maniere utile, car organisée, progressive) des outillages à base d"EDIs gratuits, pour accélérer de façon claire, objective, la production du code "à grande échelle".
Mais non... beaucoup d'entre nous (svp, notez que je ne jette la pierre à personne, et je suis le dernier à me moquer en quoi que ce soit, j'essaie de me placer plus sur le plan de la constatation) choisissons la solution de facilité :
"woa, le framework 3.5 avec Linq, EF, WCF, etc yaddayaddayadda, c'est super ! ... bon, ok, on part là dessus... oh, zut, il nous faut le dernier VS 2008 pour en profiter pleinement ?... aie, bon ok... *soupir* etc etc"
Pour tous ceux qui ont un jour du implémenter un environnement en unix + oracle + conteneur jsp + cvs quelconque + un outil de tracking, c'est compliqué, et pas nécessairement user friendly.
Si c'était si simple d'implémenter de l'open source, il n'y aurait pas autant de SSII spécialisées dans ce domaine.
La question est plutôt sur le coût global de l'outil de développement.
Former les gens ? S'adapter à de nouvelles méthodes ?
Le coût du logiciel est loin d'être le coût le plus élevé !
Et d'ailleurs on assiste aujourd'hui à un packaging un "dégeekification" des ces outils.
Comme quoi les deux mondes s'émulent, et en mon sens il est vital pour l'informatique qu'il existe plusieurs "continents", avec des idées différentes, tant qu'il s'agisse toujours de démocratie.
C'est certain que tout miser dans l'outillage dans un IDE aussi bon soit-il, c'est prendre lerisque d'avoir une usine logicielle à obsolescence rapide et de surtout de se confiner techniquement.
Code : Sélectionner tout - Visualiser dans une fenêtre à part Enfin, je ne dis pas qu'il faut systématiquement chercher a réinventer "la roue de l'EDI" mais sur N projets (N > 3 ou 4), il est probablement plus intéressant d'avoir développé un tooling maison adapté, conçu avec soin, pour la version N - 2 de Visual Studio, sur 4 ans, ou pour un autre EDI carrément gratuit celui là, sur la même période, que de passer "les yeux fermés" à la version N de VS après deux ans, puis à la N + 2 après 4 ans ; coincidence... .NET 2.0 et VS 2005 ont tous deux 4 ans déjà... qui peut dire avoir eu du succès avec la 1ère approche plutôt qu'avec la seconde ? c'est un autre sondage qu'il serait surement intéressant de mener..
En revanche, il serait intéressant de voir à quel point on pourrait externaliser une usine logicielle de l'IDE :
Bah oui, finalement, avec l'UML, on nous promet que le développeur ne développe plus et que des hommes métiers modélisent leur processus...
Bah oui, tout seul on modélise bien, à 20, faudrait déjà que tous disposent de la même capacité et la même qualité de conception.
Bah oui, UML c'est comme Java, c'est comme C# : ça fonctionne toujours tout seul, les exemples marchent toujours.
La réalité du développement, c'est le collaboratif, l'itératif, le consensus, l'agile, l'abstraction.
Il n'y a pas de raison particuliére à ce qu'un logiciel réalisé en C# ne puisse être écrit en Java, si ce n'est le choix d'origine, qui dépend fortement de l'expérience de ceux qui initient le projet.
Il n'y a pas plus de raison qu'un développeur soit bon en java et mauvais en c# : l'approche objet est strictement équivalente !
Il y a encore moins de raison de tenir des débats de chapelles sur le meilleur langage.
Mon nirvana de développeur ?
Pouvoir utiliser un middle ware J2EE, un GUI en .NET, des web services en .NET, un MQ en JMS, un cache distribué en .NET
Là, je pense que je prendrai un pied grave !
+1
Oui, c'est aussi ce que j'entendais par "architectes frileux".
Bah, pardon pour "mon envolée" d'hier, mais j'étais peut être dans un état d'esprit "revanchard", rapport... vous savez...à la nouvelle année, les bonnes résolutions, etc, etc...
Bon débat à tous pour la suite.
I do believe in Software Factories that do the job.
Domain-Specific Languages * .NET =
Then, what's next ?
Oh... Juste...
+1 !
L'outillage "maison", qu'il soit full Microsoft, ou open source, ou un mix des deux (et merci B.AF pour ces deux pointeurs, au fait), peut jouer un rôle utile, là. Mais oui, la dimension humaine (mentalités, expérience) ne doit pas, amha, ne doit jamais être oubliée ni même sous estimée, si on veut arriver à un consensus, pour pouvoir se relever les manches, et... agir après avoir... parlé.
(Par "consensus"... j'entends : pas sur ces forums, bien sûr (!)... mais au moins, chez son propre employeur, avec le reste de l'équipe de dév, c'est déjà largement bien, pour commencer
+1 !
+0,5 ... c'est en tout cas la réalité vers laquelle il faudrait aller (côté .NET) si on veut faire "aussi bien" que Java, à supposer qu'on ait encore des doutes.
+1 ... et la réciproque doit être vraie, non ?
+1 ... mais "66 % oui" et "33 % non"... je reconnais que de tels débats sont toujours amha un peu naifs dans leur idée même, mais ils peuvent parfois, si pas trop longs, mais surtout s'ils contiennent des arguments forts (respect de la différence de vécu chez l'autre, exemples concrets, et retours d'expériences vécues justement...) être utiles à quelques uns ou "presque tout le monde". Par exemple, je retiens ici certains de vos arguments qui "tiennent" tout à fait "la route" selon moi et que je n'avais pas vus.
Heheben, ma foi, alors je vous le souhaite sincèrement
a++ (non... a##
I do believe in Software Factories that do the job.
Domain-Specific Languages * .NET =
Then, what's next ?
Quand je parle d'unifié la modélisation, il y a une étape qui est finalement de transposer une réalité métier dans un modéle applicatif. Si l'outillage peut aider à fiabiliser l'implémentation technique, il n'a aucune capacité à vérifier l'adhérence d'un programme versus la réalité dans laquelle il sera exploité.L'outillage "maison", qu'il soit full Microsoft, ou open source, ou un mix des deux (et merci B.AF pour ces deux pointeurs, au fait), peut jouer un rôle utile, là. Mais oui, la dimension humaine (mentalités, expérience) ne doit pas, amha, ne doit jamais être oubliée ni même sous estimée, si on veut arriver à un consensus, pour pouvoir se relever les manches, et... agir après avoir... parlé.
(Par "consensus"... j'entends : pas sur ces forums, bien sûr (!)... mais au moins, chez son propre employeur, avec le reste de l'équipe de dév, c'est déjà largement bien, pour commencer )
Je prend par exemple un sujet très simple (au demeurant) :
Une gestion de stock et un catalogue de produits
A priori, autant de développeur et de métiers autant de vision d'un domaine de gestion des stocks et identique pour les produits.
L'incohérence dans les produits peut provoquer l'incohérence dans les stocks, est ce que le stock va supporter des back values, parle-t-on en date de sortie, en date de commande , d'opération...
Voilà les limites de la modélisation : quand il s'agit de leverager la POO pour fournir un niveau d'abstraction suffisant pour garantir évolutivité et maintenabilité.
C'est un peu comme une maison...Si l'architecte est super bon, mais que les maçons utilisent des matériaux de mauvaises qualité (aka la compréhension "ex-IT" du domaine métier) et sont tous de formation différente avec une conception différente de leur métier, je doute du résultat.
Le vrai débat de l'informatique pour moi en 2008 est devenu beaucoup plus simple :
Nous avons le hardware, nous avons des outils de développement puissants, nous avons des solutions de virtualisation de clouding de distribution de présentation....Bref, nous sommes tous super outillés.
Pourquoi considérer qu'un développeur se doit de travailler sur bases de spécifications qui seront écrites par quelqu'un qui n'a jamais ...
- De connaissances étendues du système dans lequel sa demande va s'inscrire
Eg. : Inscrire une demande dans un domaine A qui est inter connecté en tant que consommateur ou fournisseur de n domains, sans jamais aborder la question de la contamination, souvent reléguée au bug tracking lors des mises en production
- Vraiment poussée l'abstraction
Eg. : On va se retrouver avec une table client, une table fournisseur, une table centrale d'achat...Alors qu'au final on référence une personne morale...
Et allez expliquer à nos MOA chéris la débilité profonde de leur demande qu'ils justifieront systèmatiquement par "la confidentialité de l'information".
- Jamais pondu une ligne de code à destination pro.
Parce que ça aussi c'est le sujet. C# ou Java, c'est bien de choisir quand on peut choisir, mais le développement c'est aussi réaliser dans des environnements sous contraintes et c'est aussi là que se fait la capitalisation et globalement la maturité. Comme me l'a dit un de mes "mentors", "tu ne seras vraiment un bon développeur que le jour où tu auras donné satisfaction à un utilisateur en ayant utilisé les moyens que l'on t'a imposé".
Et c'est vrai. Avoir le choix C# ou Java ne devrait même pas être motif de débat. C'est déjà pour moi une chance aujourd'hui de pouvoir choisir une de ces deux technologies.
Et sur ce dévelopement complêtement anarchique de la parainformatique, Java ou .NET, nous allons continuer à resasser les éternelles questions de méthode, de position du développeur...
Tant que les organisations n'auront pas compris qu'un développeur motivé et intéressé, donc acteur principal, génére plus de valeur ajoutée qu'un process en 60 documents à 3 niveaux de validation, quelle que soit la puissance des langages et outils, l'informatique n'avancera pas dans ses mentalités.
Et désolé pour la digression.
Je ne suis pas d'accord sur ce point en particulier.
Microsoft a toujours eu une politique particulière concernant "l'outillage", et cela ne date pas de .Net.
A l'époque de VB déjà, si par exemple on cherchait des jeux de contrôles un tant soit peu avancés, il fallait se tourner vers des initiatives tierces, souvent payantes.
A la sortie de .Net, la politique n'avait pas changée, et Microsoft s'est largement appuyé sur la communauté pour "enrichir" son framework.
Somme toute, ce n'est que récemment que MS a commencé a développer des outils et des frameworks "annexes", tels qu'Ajax ToolKit, les Enterprise Libraries ou Unity.
Mais entre temps, la communauté n'avait pas attendu pour proposer ses propres outils originaux ou "portés" du monde Java...
Ben tout cela me semble possible...où pas loin.
In my experience, any attempt to make any system idiot proof will only challenge God to make a better idiot.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager