Discussion :

[LSMetag]

Bonjour,

pour ma part, j'ai quelques langages de programmation à mon actif: Progress, PL/SQL, PHP, Java. Chacun avec plusieurs années d'expérience. Ce que je remarque c'est que sans une pratique régulière d'un langage, il s'émousse et il faut un temps pour reprendre ses marques et retrouver une fluidité et donc une productivité correcte. Cependant, connaître plusieurs langages permet d'avoir une sorte de culture générale et permet d'envisager des solutions auxquelles on n'aurait pas forcément songé.

Dernier point: pour faciliter la gestion d'un SI et surtout être sûr de disposer de gens compétents, il vaut mieux éviter d'avoir N langages présents dans son SI et surtout éviter les langages "exotiques" maîtrisés seulement par quelques experts. Cela ne signifie par pour autant qu'il ne faut avoir qu'un seul langage, chaque langage a souvent un domaine de prédilection. Ce qu'il faut c'est savoir mettre en oeuvre le bon langage pour le bon besoin, tout en tenant compte des diverses contraintes présentes (performances, maintenabilité, interfaces...)

A mes yeux, les gens compétents ne sont pas ceux qui sont doués pour "pisser du code" dans un langage qu'ils maîtrisent. Ce sont ceux qui ont une culture générale et une maîtrise des différents paradygmes, leur permettant d'appréhender rapidement n'importe quelle technologie et d'avoir en tête une mine d'idées, d'anticipation des écueils ou des éventuels avantages.

Un exemple personnel : Je suis développeur "spécialisé" C#.NET en théorie. On m'a soudainement demandé de chiffrer des évolutions sur 2 applications PHP5 avec un framework MVC maison. En 1h15, alors que je n'avais jamais vu les applis ni appréhendé de longue date le PHP, j'ai posé les macro-chiffrages et chiffrages détaillés, en indiquant les portions de code à modifier et comment les modifier, pour les deux applications.

Sauf urgence, je pense qu'il vaut mieux passer 2/3 semaines à se rôder (c'est d'ailleurs toujours le cas pour les nouvelles recrues) pour qu'ensuite la productivité, la qualité générale, la maintenabilité et l'efficacité des chiffrages augmente.

[kolodz]

En premier lieu, je tiens à noté que cela fait plaisir d'avoir le premier commentaire d'un article qui est allé lire les sources.

En second lieu, les deux articles ont deux problématiques différentes et donc deux points de vue différents. L'article de Sam Atkinson parle principalement des langages alternatifs et utilisations dans des projets professionnels sans bonne raison. Ce qui posera forcement des problèmes de maintenances (Si cela n'en pose pas pendant le projet en lui-même). L'article de Yegor Bugayenko, lui parle de la relation de l’apprentissage "des bases" dans une équipe de développement pendant un projet.

Pour le détail, je vais commenté ce que j'ai lu :

Par ailleurs, il faudra m'expliquer comment faire une appli web sans utiliser au moins deux langages (sans compter html et css).

Ce n'est pas ce qu'explique Sam Atkinson, en particulier quand sa conclusion inclus : I think being able to program in multiple languages is an absolute must and is something I look for on a CV."
L'idée du choix de l'apport d'un nouveau langage dans un projet devant suivre cette logique : But you need to be able to properly justify this up front with strong reasoning. The answer shouldn’t be “I fancied trying something new”.

Quant à l'apprentissage au cours d'un projet... Je ne vois même pas comment on peut faire pour ne pas apprendre à chaque projet.
Chaque développement un peu trapu entraîne des choix et des expériences qui sont des apprentissages. Ceux qui ne fonctionnent pas bien entraineront d'autres choix la fois d'après qui nécessiteront sans doute également une part d'apprentissage.
Le plombier a des normes fixes (relativement) là où un développeur travaille sur des environnements mouvants. Un développement de deux ans et la base de donnée a de nouvelle fonctionnalités, le framework a changé de version majeure, le langage a évolué notablement et le contrat suivant est déjà signé... Où apprend-on dans ce cas ?

Cela soulève deux argument selon moi.
En premier lieu, il faut bien comprendre que l'argument de Yegor Bugayenko est de dire que si tu es sur un projet utilisant le langage X, et que tu es développeur en Y. C'est le manageur qui a fait une boulette et c'est à lui d'assumer la connerie et non à toi : Ask the project manager to fix this.

En second lieu, il ne pas confondre travail et projet. Un emploi ne se résume pas à un ou plusieurs projets. Si tu as un jour un manageur un minimum compétent, tu verra que celui-ci n'affecte pas directement une personne à un projet. En générale, celle-ci a un temps de formation.. En particulier quand une personne rejoins une entreprise.
D'ailleurs, cela est l'une des raisons qui fait qu'un projet ne finit pas "dans les temps", simplement parce que le temps de formation s'est retrouvé dans le temps du projet. Alors, que c'est bien autre chose...

Au contraire de l'article, je pense que le développeur DOIT se former en permanence, sur tous les projets qu'il fait. Ça fait partie intégrante de son boulot. Celui qui ne le fait pas ne peut pas tenir plus de dix ans avant d'être complètement dépassé sauf à considérer que l'apprentissage des techniques du métier sont un loisir. Je ne vois pas pourquoi un client ou un employeur n'aurait pas à se soucier de cette partie du travail. C'est un peu facile de demander des types de bon niveau, formé aux dernières technologies, sans prendre en compte la nécessité pour ces ressources d'une formation véritablement continue.

Au final, je dirai qu'il faut aussi bien comprendre le degré d'incompétence ciblé est "Je n'ai pas la moindre idée de ce qu'il faut faire." et non "Je ne suis pas sûr d'une chose."
Et encore, encore une fois, ne pas confondre projet, travail et emploie.

- comment fait-on pour se renouveler si l'entreprise nous cloisonne dans un environnement. ( Je parle pour les dev qui ont des enfants et ne peuvent pas se renouveler chez eux au détriment de l'éducation )

Il y a deux possibilités :
- changer d'entreprise
- Être payer plus et donc avoir la possibilité financier de se re-former

Bref avec ce genre de considération , beaucoup de DEV quittent la technique pour passer dans le management, c'est une perte considérable !

Beaucoup de "dev" passent dans le management, simplement parce qu'il n'y a pas filière "management technique". La plus part des manageurs actuels sont des anciens développeurs.

Bref, si ce mec là était mon chef de projet, je programmerais toujours en COBOL, parce que ça fonctionne. Quid ensuite de la maintenance et de "l'évolutivité" ? Une fois que tout le monde sera à la retraite, je leur souhaite bien du plaisir.

Vieux ne veux pas dire hors d’usage ou obsolète !
J'ai un ami qui est formateur sur COBOL... IBM maintient un plug-in eclipse pour développer en COBOL. Et oui, c'est pour du bancaire. L'évolutivité, il y a certains moment où tout le monde l'en veux pas. En particulier, quand tu apprends que l'une des versions de PHP avait un problème sur les calculs sur le nombre flottant.
Je ne te reprends pas sur la confusion général que tu réalise entre ton "chef de projet" et ton "supérieur hiérarchique"....

La richesse dans le développement, quand tu y es autorisé, c'est de pouvoir prendre des décisions et faire des propositions pertinentes, en tant que personne sur le terrain, pour le bien-être de l'entreprise et ses clients.

Donc, tu n'as pas pris le temps de lire la source de l'article pour y voir cette partie : But you need to be able to properly justify this up front with strong reasoning. The answer shouldn’t be “I fancied trying something new”.
Ce qui est basiquement ce que tu vient de dire... Visiblement, tu n'es pas une personne sur le terrain en ce qui concerne cette article !

Cordialement,
Patrick Kolodziejczyk.

[dfiad77pro]

Un exemple personnel : Je suis développeur "spécialisé" C#.NET en théorie. On m'a soudainement demandé de chiffrer des évolutions sur 2 applications PHP5 avec un framework MVC maison. En 1h15, alors que je n'avais jamais vu les applis ni appréhendé de longue date le PHP, j'ai posé les macro-chiffrages et chiffrages détaillés, en indiquant les portions de code à modifier et comment les modifier, pour les deux applications.

J'ai toujours eu un peu de mal avec la notions du chiffrage lorsque celui ci implique qu'on doit faire un document indiquant exactement ce qu'il faut faire.

En gros tu fais déjà tout le boulot

et le développeur n'a qu'à recopier et tester...


moi ce genre de DSF ( très courant) m'ennuis et on perds du temps cela dit , c'est vital si on doit déléguer un travail en Inde ou autre pays ou la main d'oeuvre est sous-payé

Il y a deux possibilités :
- changer d'entreprise
- Être payer plus et donc avoir la possibilité financier de se re-former

personnellement mon entreprise me paye une semaine de formation tout les ans dans le domaine que je souhaite
Le reste je le fait en formation sur mon temps perso.

[LSMetag]

Vieux ne veux pas dire hors d’usage ou obsolète !
J'ai un ami qui est formateur sur COBOL... IBM maintient un plug-in eclipse pour développer en COBOL. Et oui, c'est pour du bancaire. L'évolutivité, il y a certains moment où tout le monde l'en veux pas. En particulier, quand tu apprends que l'une des versions de PHP avait un problème sur les calculs sur le nombre flottant.
Je ne te reprends pas sur la confusion général que tu réalise entre ton "chef de projet" et ton "supérieur hiérarchique"....
...
Donc, tu n'as pas pris le temps de lire la source de l'article pour y voir cette partie : But you need to be able to properly justify this up front with strong reasoning. The answer shouldn’t be “I fancied trying something new”.
Ce qui est basiquement ce que tu vient de dire... Visiblement, tu n'es pas une personne sur le terrain en ce qui concerne cette article !

Cordialement,
Patrick Kolodziejczyk.

Je n'ai jamais dit le contraire. Je parle en matière de nouvelle application. Evidemment qu'on ne va pas refaire une application qui fonctionne bien et qui plus est critique "pour le hype". Tout choix doit être fondé sur un raisonnement constructif avec de vrais arguments plutôt qu'une volonté d'être "à la mode". Après je m'inquiète en effet pour le Cobol, étant donné la difficulté à trouver du personnel en la matière. Pourquoi ne pas penser à mobiliser en parallèle quelques ressources pour une refonte de la solution ? Celà permettrait ensuite de booster la productivité, maintenabilité,...et surtout de sortir de cette situation inconfortable. Après tout, avec tout ce que rapporte les traders, ça doit pouvoir se faire non ? Et puis les distributeurs de billets piratables (Windows XP), ça m'ennuie. C'est pour ça que je ne retire plus mais ne paye que par Paypal ou au pire par carte bleue en magasin. M'enfin bon, c'est pas comme si les banques n'étaient pas prévenues 12 ans à l'avance...

En effet, je n'ai pas pris le temps d'aller voir les sources de cet article, ce qui veut peut-être dire qu'il est mal résumé. Je suis sur le terrain, et je fais partie de ceux qui anticipent des problèmes ou proposent des solutions pour booster la productivité, mais que personne n'écoute, pour ensuite se retrouver dans le mur, alors qu'on avait prévenu. Et après, c'est celui qui a prévenu et qu'on n'a pas écouté qui se retrouve à devoir faire des heures sup voire de l'astreinte pour résoudre le problème, désormais bien ancré. La même personne est rabaissée et l'utilisateur final est pénalisé.

Beaucoup d'entreprises fonctionnent de manière unilatérale. On a une MOA qui crée des spécifications fonctionnelles, une MOE qui fait des spécifications techniques sans forcément consulter ses développeurs ou prendre en considération d'éventuelles remarques, et une hiérarchie qui fait pression.

Je sais que je ne suis pas fait pour la plupart des entreprises, de part ma manière de voir les choses et mon aspect "électron libre"/"franc du collier", mais il y a des entreprises qui apprécient cela. Notamment celles qui cherchent à fidéliser leur clientèle plutôt que simplement faire le "job".

[LSMetag]

J'ai toujours eu un peu de mal avec la notions du chiffrage lorsque celui ci implique qu'on doit faire un document indiquant exactement ce qu'il faut faire.

En gros tu fais déjà tout le boulot

et le développeur n'a qu'à recopier et tester...


moi ce genre de DSF ( très courant) m'ennuis et on perds du temps cela dit , c'est vital si on doit déléguer un travail en Inde ou autre pays ou la main d'oeuvre est sous-payé




personnellement mon entreprise me paye une semaine de formation tout les ans dans le domaine que je souhaite
Le reste je le fait en formation sur mon temps perso.

T'inquiètes le chiffrage c'est pas comme ça. C'est moi qui ai fait un peu de zèle. Après tout j'ai analysé le code pour chiffrer. Donc ça coûtait rien ensuite de dire ce que j'avais vu

[tanatiel]

Sauf urgence, je pense qu'il vaut mieux passer 2/3 semaines à se rôder (c'est d'ailleurs toujours le cas pour les nouvelles recrues) pour qu'ensuite la productivité, la qualité générale, la maintenabilité et l'efficacité des chiffrages augmente.

Tout à fait, la connaissance d'un langage permet d'en connaître les forces ET les faiblesses. cela permet de prendre du recul à la fois lors des chiffrages mais également lors de la conception technique et de trouver des solutions fiables, pérennes et performantes.

[kolodz]

Je n'ai jamais dit le contraire. Je parle en matière de nouvelle application. Evidemment qu'on ne va pas refaire une application qui fonctionne bien et qui plus est critique "pour le hype". Tout choix doit être fondé sur un raisonnement constructif avec de vrais arguments plutôt qu'une volonté d'être "à la mode". Après je m'inquiète en effet pour le Cobol, étant donné la difficulté à trouver du personnel en la matière. Pourquoi ne pas penser à mobiliser en parallèle quelques ressources pour une refonte de la solution ? Celà permettrait ensuite de booster la productivité, maintenabilité,... Après tout, avec tout ce que rapporte les traders, ça doit pouvoir se faire non ? Et puis les distributeurs de billets piratables (Windows XP), ça m'ennuie. C'est pour ça que je ne retire plus mais ne paye que par Paypal ou au pire par carte bleue en magasin. M'enfin bon, c'est pas comme si les banques n'étaient pas prévenues 12 ans à l'avance...

Comme je le disais mon ami est formateur... C'est bien pour former les gens ! Ensuite, les applications bancaire en COBOL sont sur des mainframes Unix (de ce que j'en sais). Donc aucun rapport avec les distributeurs de billets. Pour finir, le tradding en bourse est un secteur financier totalement différent de celui qui s'occupe des opérations bancaires. Et pourquoi redévelopper encore et encore ce qui fonctionne depuis des années sans problèmes ? C'est une perte d'argent et de temps monumental... C'est loin d'être une décision raisonné.

A mes yeux, les gens compétents ne sont pas ceux qui sont doués pour "pisser du code" dans un langage qu'ils maîtrisent. Ce sont ceux qui ont une culture générale et une maîtrise des différents paradygmes, leur permettant d'appréhender rapidement n'importe quelle technologie et d'avoir en tête une mine d'idées, d'anticipation des écueils ou des éventuels avantages.

Un exemple personnel : Je suis développeur "spécialisé" C#.NET en théorie. On m'a soudainement demandé de chiffrer des évolutions sur 2 applications PHP5 avec un framework MVC maison. En 1h15, alors que je n'avais jamais vu les applis ni appréhendé de longue date le PHP, j'ai posé les macro-chiffrages et chiffrages détaillés, en indiquant les portions de code à modifier et comment les modifier, pour les deux applications.

La question n'est pas de savoir si tu es un bon développeur. Ce que pointe du doigt tanatiel est bien :

pour faciliter la gestion d'un SI et surtout être sûr de disposer de gens compétents, il vaut mieux éviter d'avoir N langages présents dans son SI et surtout éviter les langages "exotiques" maîtrisés seulement par quelques experts.

Ce qui est de la gestion de base de l'éco-système d'un SI et des ressources qui vont avec. Avoir l'ensemble de ces applications développer sur le même langage/Framework, implique des coût moindre. Il sera plus facile d'échanger des personne d'un projet à un autre, par exemple. Je ne parle même pas des setup d'installation...
Cela me rappel une discutions sur la programmation orienté aspect (AspectJ pour les connaisseurs). Et l'un des gros points noir était bien qu'il n'était pas envisageable de transmettre un projet utilisant AspectJ à une équipe support classique n'ayant qu'une formation Java de base (BAC+2). Il en va de même avec l'apport d'un nouveau langage.

D'un point de vue SI et projet, la multiplication des langages est une mauvaises choses en-soit, même si il est possible qu'ils apportent des points positifs plus important.

Cordialement,
Patrick Kolodziejczyk
Note : Le passage de C# à PHP5 n'est pas non plus d'une grande difficulté pour un développeur expérimenté, en particulier sur du code existant. Bien qu'il y ai besoin d'une connaissance du métier associer...

[stendhal666]

A mes yeux, les gens compétents ne sont pas ceux qui sont doués pour "pisser du code" dans un langage qu'ils maîtrisent. Ce sont ceux qui ont une culture générale et une maîtrise des différents paradygmes, leur permettant d'appréhender rapidement n'importe quelle technologie et d'avoir en tête une mine d'idées, d'anticipation des écueils ou des éventuels avantages.

Tout à fait d'accord avec LSMetag dont je plussoie la réponse (mais pas l'orthographe, je préfère paradigme). Je crois que Kolodz manque l'essentiel en disant que:

D'un point de vue SI et projet, la multiplication des langages est une mauvaises choses en-soit, même si il est possible qu'ils apportent des points positifs plus important.

Car un langage n'est pas un paradigme, et réciproquement. Java a pas mal évolué pour proposer des aspects génériques et fonctionnels. Quelqu'un qui n'a connu que Java en profitera beaucoup moins que quelqu'un qui a eu la curiosité d'étudier C++ ou Haskell. On peut rester dans le même environnement, garder les mêmes outils, etc. et évoluer tout de même dans la productivité et la maintenabilité, voire la performance du code en élevant les habitudes de programmation.

Et puis il y a le raisonnement par l'absurde: si on veut absolument standardiser par le bas (je ne prends que ce que sait faire le plus mauvais programmeur), alors pourquoi ne pas y aller carrément: je n'autorise que les mots-clés for et do?

J'ai lu un billet très intéressant dans le blog Codemanship (http://codemanship.co.uk/parlezuml/blog/?sectionid=37 scroller un peu vers le bas, le billet s'appelle Continuous Inspection II - Planning & Executing CInsp) qui indique qu'il est normal et même important d'avoir des coûts cachés dans le prix d'un développement: entretien du code, formation des développeurs, etc. comme il y en a dans un restaurant, où l'on ne dit pas quel part du prix du steack correspond au nettoyage de la cuisine.

[LSMetag]

Comme je le disais mon ami est formateur... C'est bien pour former les gens ! Ensuite, les applications bancaire en COBOL sont sur des mainframes Unix (de ce que j'en sais). Donc aucun rapport avec les distributeurs de billets. Pour finir, le tradding en bourse est un secteur financier totalement différent de celui qui s'occupe des opérations bancaires. Et pourquoi redévelopper encore et encore ce qui fonctionne depuis des années sans problèmes ? C'est une perte d'argent et de temps monumental... C'est loin d'être une décision raisonné.

Je pense qu'on ne s'est pas bien compris. Je suis d'accord avec toi qu'une application qui fonctionne bien n'a pas à être redéveloppée. C'est une perte d'argent pour rien en effet, d'un point de vue SI et gestionnaire.
Les distributeurs de billets n'étaient qu'un exemple de ce qui pourrait éventuellement arriver dans un avenir incertain, comme pour le bug de l'an 2000. Et s'il y avait une grosse tuile dans les mainframe, que faire ? Quel coût ça aurait ? Aurait-on le personnel pour gérer ça ? Ne vaut-il pas mieux échelonner plutôt que de se retrouver ruiné à un instant "t" ? Pour le trading, la séparation des banques de dépôts et d'affaire n'en est qu'à ses balbutiements (programme de M.Hollande).

Ce qui est de la gestion de base de l'éco-système d'un SI et des ressources qui vont avec. Avoir l'ensemble de ces applications développer sur le même langage/Framework, implique des coût moindre. Il sera plus facile d'échanger des personne d'un projet à un autre, par exemple. Je ne parle même pas des setup d'installation...
Cela me rappel une discutions sur la programmation orienté aspect (AspectJ pour les connaisseurs). Et l'un des gros points noir était bien qu'il n'était pas envisageable de transmettre un projet utilisant AspectJ à une équipe support classique n'ayant qu'une formation Java de base (BAC+2). Il en va de même avec l'apport d'un nouveau langage.

En toute logique, avoir un éco-système basé sur le même socle technique est tout à fait logique et moins coûteux. Je suis bien d'accord. A quoi bon avoir du J2EE et du .NET sachant que ces technos font grosso-modo la même chose ?

Je parle surtout en matière de "sous-technos" comme par exemple Aspect-J dont tu parlais. Pourquoi ne pas simplement dispenser une formation de 2 jours sur Aspect-J et son éco-système ? Les BAC+2 ne sont pas plus bêtes que les autres et ça vous permettrait de faire monter en compétence votre main d'oeuvre. Ils ont des gardes fous derrière eux (ceux qui maîtrisent) pour leur éviter des erreurs.
Après tout, utiliser de la programmation Aspect pourrait, par exemple, limiter les régressions dans le développement en mettant en place des tests automatisés. Combien ça coûte de corriger un bug qu'on a créé ? Ou les pénalités de dépassement des délais à cause des invalidations de versions causées par des effets de bord ? Sans compter les conséquences lors de l'utilisation, si jamais ça passe au travers des tests.

Si il y a changement, évidemment que c'est contre-productif qu'il soit brutal. Mais si c'est pertinent pour le respect du besoin, l'avenir de l'entreprise ou encore le service à l'utilisateur final, je pense qu'il ne faut pas avoir peur de faire un peu de R&D, et de prévoir une petite marge de manoeuvre pour créer une branche expérimentale.

Ce n'est qu'un exemple. Je ne suis pas responsable de SI (et je n'ai pas l'intention de le devenir), mais je trouve que l'anticipation est quelque chose qui manque cruellement dans nos entreprises. Et on le paie parfois très cher. On n'a qu'une vision à court terme, basée sur les coûts immédiats.

[kolodz]

Je crois que Kolodz manque l'essentiel en disant que:

la multiplication des langages est une mauvaises choses en-soit[/B], même si il est possible qu'ils apportent des points positifs plus important.

Car un langage n'est pas un paradigme, et réciproquement. Java a pas mal évolué pour proposer des aspects génériques et fonctionnels. Quelqu'un qui n'a connu que Java en profitera beaucoup moins que quelqu'un qui a eu la curiosité d'étudier C++ ou Haskell. On peut rester dans le même environnement, garder les mêmes outils, etc. et évoluer tout de même dans la productivité et la maintenabilité, voire la performance du code en élevant les habitudes de programmation.

Et puis il y a le raisonnement par l'absurde: si on veut absolument standardiser par le bas (je ne prends que ce que sait faire le plus mauvais programmeur), alors pourquoi ne pas y aller carrément: je n'autorise que les mots-clés for et do ?

Je ne manque pas l'essentiel, tu ne lis que ce qui est écrit en gras...
Tu n'as pas lu le début, qui indique bien le point de vue SI et non développeur. D'ailleurs le blogueur en question soulève exactement le même argument. Simplement, notre curiosité n'a rien à voir avec le choix des langages que l'on va utiliser pour des projets en production. C'est un choix...
Tu n'as pas lu non plus la fin, qui implique qu'il est possible qu'il y ai des points positif plus important.

Beaucoup de société évite la multiplication des langages, souvent en poussant la refonte d'un ensemble cohérent d'application. Et donc en sélectionnant à ce moment là un langage et un framework. Encore une fois en respectant : But you need to be able to properly justify this up front with strong reasoning. The answer shouldn’t be “I fancied trying something new”.

Donc, si tu as affaire un SI un minimum sérieux et que tu leur explique que la nouvelle application tu veux la développer en Java, alors qu'ils ont que des applications C++/C# et les développeurs qui vont avec. Tu as intérêt avoir un bon argumentaire du pourquoi il est nécessaire d'avoir à gérer le Java. Car, cela demande un investissement non négligeable.

D'ailleurs, il y a une publication très intéressante qui explique pourquoi, il est important de passer aux nouveaux langage de programmation de haut niveau. Car, ils apportent beaucoup plus de sécurité et de lisibilité que les autres langages... C'est un texte que j'ai eu en école d'ingénieur. Pratiquement toute ma classe s'est mis à expliquer pourquoi Scala était mieux que Java ou Java mieux que C++.
Sauf que la publication date de la fin des années 60 et que pour lui, les langages de "haut niveau", c'est Cobol/basic (Le C étant encore en cours de développement...). On a été deux ce jour là à remarquer la date de l'article et comprendre que les structures contrôles "évoluées" dont parlait le texte étaient les boucles for et while par rapport au goto.
A ce moment là, il était important, voir vitale de passer à ces langages. Aujourd'hui, c'est beaucoup plus relatif. Il est souvent plus important pour un SI d'avoir un environnement cohérent que d'avoir le dernier langage capable de tout faire.

Et s'il y avait une grosse tuile dans les mainframe, que faire ? Quel coût ça aurait ? Aurait-on le personnel pour gérer ça ? Ne vaut-il pas mieux échelonner plutôt que de se retrouver ruiné à un instant "t" ?

Les sociétés qui font du COBOL ont les ressources nécessaire pour maintenir leur application ! Ils ont pour la plus part des plans de formations et de recrutement sur le long terme, avec un minimum de gestion des risque pris en compte (départ, accident...)
Ce ne sont pas des amateurs loin de là.

Je parle surtout en matière de "sous-technos" comme par exemple Aspect-J dont tu parlais. Pourquoi ne pas simplement dispenser une formation de 2 jours sur Aspect-J et son éco-système ? Les BAC+2 ne sont pas plus bêtes que les autres et ça vous permettrait de faire monter en compétence votre main d'oeuvre. Ils ont des gardes fous derrière eux (ceux qui maîtrisent) pour leur éviter des erreurs.

Pour l'exemple précis d'Aspect J, c'est juste impossible. Le cours de base sur les principes, c'est 20H minimum et 20H de plus pour la pratique. Cela fait directement une semaine de formation minimum pour toute personne qui va potentiellement toucher au logiciel. En plus de cela il va te falloir un "garde fous" qui globalement sera là juste pour ça, alors que tu aurai pu avoir simplement un manageur classique et leur laisser la technique. En même temps, il sera là pour faire les formations qui sera nécessaire de faire aux nouveaux (le turn over tout ça...)
Sans prendre en compte la partie risque inhérent à l'utilisation de technologie moins fiabilisé et maitrisé. Il ne te sera par exemple pas possible (ou plus difficilement ) de remplacer une personne malade par un prestataire pour tenir les délais.
Donc d'un point de vue budget, ça calcule.

Note : La programmation orienté aspect est selon moi la programmation, où il est le plus facile de faire un effet de bord non voulu. Ou de ne pas faire ce que l'on pensait...

Ce n'est qu'un exemple. Je ne suis pas responsable de SI (et je n'ai pas l'intention de le devenir), mais je trouve que l'anticipation est quelque chose qui manque cruellement dans nos entreprises. Et on le paie parfois très cher. On n'a qu'une vision à court terme, basée sur les coûts immédiats.

Possible, mais cela ne fait pas réellement partie du débat porter par les deux blogueurs. Arrêtons déjà entant que développeur de pousser des langages dans les entreprises sans aucunes raisons.

Cordialement,
Patrick Kolodziejczyk.

[javan00b]

Je ne suis pas d'accord, si on utilise que Java dans ce cas on ne fait pas d'application WEB... ou alors c'est un fan des applets

Faut pas oublier que HTML, CSS et Javascript sont aussi des langages

Oui mais HTML, CSS sont des languages d'integrateurs, c'est évident qu'un developpeur sais comment les utiliser. De toute facon certaine lib Java peut aussi permettre au developpeur de ne pas avoir à coder une ligne de HTML/CSS.

Pour Javascript c'est different, si tu t'en sert vraiment pour faire une app web c'est sur qu'il te faut beaucoup de connaissance, il y a tellement de stack de librairie different qui sont utilisé, par contre si tu t'en sert seulement pour manipuler le DOM et faire des petites animations jquery, alors sa tombe dans la categorie job d'integrateur.

Je pense que l'auteur parle seulement de language core comme Java, C#, C++, Python etc..

[javan00b]

Pour ma part, au boulot le projet sur lequel je suis depuis 2ans utilise les technologies suivantes: Javascript, C++, C#, Java, Objective C, Python, une grosse BD oracle, et une plus petite SQlite :p. J'ai travailler sur toute les couches du projet. Je peux vous dire qu'on s'ennuie beaucoup moins que par exemple lorsque j'ai participer au developpement de 3DS studio max, je ne fesais que du c++, apres quelque temps c'etait ennuyant.

[_skip]

J'ai lu l'article de Sam Atkinson et je pense que son propos sur java fait entièrement du sens. C'est juste qu'il vous est rapporté entièrement sorti de son contexte.

I’m not sure if you’ve noticed, but recently there seems to be an awful lot of noise about the death of Java and the rise of the JVM. Scala, Clojure, Groovy, Jython have all recently gone through being the language choice du jour (Although this great article shows how Java still rules the roost by a long way). More and more projects in these languages are appearing on the job boards and in projects at bigger and bigger companies

But, is this a good thing or not?

As a massive nerd, I love trying new programming languages. New things are shiny. I like shiny. Last year when I started doing the “functional programming principals in Scala” course run by Martin Odersky, the creator of Scala, I was convinced Scala was going to be the answer to all of my Java based problems. “Look ma, the syntax is so much more concise! And now I understand why immutable is so awesome!”. It’s this kind of hedonism which is why more and more projects are getting started in these languages. Bored programmers want to try new things out, and so a new language is brought into the company.

This is a terrible idea.
.

Je vais pas citer tout l'article mais déjà clairement, au vu des langages qu'il cite, il parle des langages pour la JVM!

Donc lorsqu'il en arrive à son argumentaire comme quoi Java est le meilleur choix parmi ceux-ci, c'est pas dans le sens "C++, javascript, php, .net et tout le reste du monde c'est de la merde" comme on pourrait le croire dans les fragments repris en français de ce topic. Déjà en limitant le scope de son affirmation aux langages pour la JVM, son propos a tout de suite moins l'air d'une bêtise, sachant que les langages destinés à produire du bytecode pour la JVM adressent généralement les mêmes besoins et sont dans la plupart des cas *relativement* interchangeables.

En gros ce qu'il dit :

• Qu'aucun langage pour la JVM n'est aussi bien servi question outillage que java, c'est objectivement assez vrai.
• Que java c'est globablement du terrain connu et qu'on a des chances de trouver les réponses (forte communauté), c'est vrai
• Qu'introduire un autre langage comme Scala ou Groovy accroît les risques de maintenance et ne devrait pas être pris à la légère, c'est largement défendable aussi.
• Qu'il faut donc des arguments vraiment solides pour justifier l'emploi de ces langages alternatifs en entreprise dans le contexte particulier de son projet sous peine que ça vous retombe lourdement dessus en cas de problème, c'est plutôt vrai aussi.

Donc pour commencer, avant de lâcher des pavés du style "Qu'il essaie de faire XX avec son java de merde" ou encore "si on l'écoutait, on ferait du Cobol", franchement allez lire la source.

[tanatiel]

En gros ce qu'il dit :

• Qu'aucun langage pour la JVM n'est aussi bien servi question outillage que java, c'est objectivement assez vrai.
• Que java c'est globablement du terrain connu et qu'on a des chances de trouver les réponses (forte communauté), c'est vrai
• Qu'introduire un autre langage comme Scala ou Groovy accroît les risques de maintenance et ne devrait pas être pris à la légère, c'est largement défendable aussi.
• Qu'il faut donc des arguments vraiment solides pour justifier l'emploi de ces langages alternatifs en entreprise dans le contexte particulier de son projet sous peine que ça vous retombe lourdement dessus en cas de problème, c'est plutôt vrai aussi.

Effectivement, son point de vue s'inscrit dans une réalité projet et cohérence de SI. Si individuellement, il est souhaitable pour chaque développeur de faire preuve de curiosité et de sortir un peu des sentiers battus (à titre personnel, ie: aller voir du code C++ quand on est developpeur Java par exemple), le choix du ou des langages dans un projet doit être motivé et argumenté. Ces critères peuvent être techniques bien sûr mais avoir aussi des aspects humains: a-t-on suffisamment de personnes compétentes sur ce langage?

Pour avoir fait de la maintenance applicative pendant assez longtemps, je vous assure que ce point est critique car rien n'est pire de se retrouver en situation de crise car LE développeur qui connait le langage XX est parti (ou malade ou que sais-je) et que personne ne maîtrise le dèv bien pointu qu'il avait fait. Toujours être sûr de disposer de back-up est essentiel et entre la maîtrise technique, la maîtrise fonctionnelle et la maîtrise des process que doit avoir chaque back-up, si on peut se passer de la maîtrise technique juste en harmonisant les langages au sein du SI, c'est un confort non négligeable.

Reste donc le côté individuel de la démarche de découverte d'un langage et ce que je trouve regrettable de mon point de vue, c'est que l'on n'ait pas de temps dédié pour cela car après tout cette "ouverture d'esprit" est quelque chose qui bénéficie aux compétences du développeur et donc à son entreprise au final.

[Jch71]

En tant que bientôt jeune diplômé et stagiaire, je ne vois pas comment je pourrais m'intégrer sur des projets sans apprendre de nouveaux langages ...

De plus, étant adepte du changement dans les projets, je pense que l'ennui arriverait rapidement en ne développant que dans un seul langage, et plus l'expertise arrive, plus on est demandé dans ce domaine (un cercle vicieux à mon avis !).

On a besoin d'experts dans certains langages, mais dans le projets actuels, il est rare de ne développer qu'en Java (par exemple). Il y aura toujours une base de donnée derrière un projet, ou un lien avec un navigateur, ou du XML qui traîne quelque part !

[Traroth2]

Je ne pense pas qu'un plombier n'apprenne rien en exerçant sa profession. Je pense qu'un type qui sort de l'école avec un CAP plomberie et un type qui fait ça depuis 15 ans, ils n'ont pas le même niveau de compétence. Le présupposé de base de l'auteur de ce billet de blog est donc faux. Ensuite, il faudrait démontrer que les deux situations sont comparables, et ça, ça risque moins simple qu'on pourrait l'imaginer. La plomberie, c'est un domaine qui évolue assez lentement, je pense. En informatique, les langages, les frameworks, les outils, ça bouge constamment. On ne peut pas se contenter de ce qu'on apprend pendant ses études. Et surtout, savoir programmer, c'est bien plus que de savoir un langage de programmation sur bout des doigts. C'est pourquoi un bon programmeur peut s'adapter à un nouveau langage en relativement peu de temps. Fondamentalement, je ne pense pas que le métier d'un programmeur est de maitriser un langage de programmation.

[LSMetag]

Je ne pense pas qu'un plombier n'apprenne rien en exerçant sa profession. Je pense qu'un type qui sort de l'école avec un CAP plomberie et un type qui fait ça depuis 15 ans, ils n'ont pas le même niveau de compétence. Le présupposé de base de l'auteur de ce billet de blog est donc faux. Ensuite, il faudrait démontrer que les deux situations sont comparables, et ça, ça risque moins simple qu'on pourrait l'imaginer. La plomberie, c'est un domaine qui évolue assez lentement, je pense. En informatique, les langages, les frameworks, les outils, ça bouge constamment. On ne peut pas se contenter de ce qu'on apprend pendant ses études. Et surtout, savoir programmer, c'est bien plus que de savoir un langage de programmation sur bout des doigts. C'est pourquoi un bon programmeur peut s'adapter à un nouveau langage en relativement peu de temps. Fondamentalement, je ne pense pas que le métier d'un programmeur est de maitriser un langage de programmation.

Content qu'un type expérimenté soit du même avis que moi à ce sujet ! Il faudrait l'apprendre aux managers et RH.

[LSMetag]

J'ai lu l'article de Sam Atkinson et je pense que son propos sur java fait entièrement du sens. C'est juste qu'il vous est rapporté entièrement sorti de son contexte.

Je vais pas citer tout l'article mais déjà clairement, au vu des langages qu'il cite, il parle des langages pour la JVM!

Donc lorsqu'il en arrive à son argumentaire comme quoi Java est le meilleur choix parmi ceux-ci, c'est pas dans le sens "C++, javascript, php, .net et tout le reste du monde c'est de la merde" comme on pourrait le croire dans les fragments repris en français de ce topic. Déjà en limitant le scope de son affirmation aux langages pour la JVM, son propos a tout de suite moins l'air d'une bêtise, sachant que les langages destinés à produire du bytecode pour la JVM adressent généralement les mêmes besoins et sont dans la plupart des cas *relativement* interchangeables.

En gros ce qu'il dit :

• Qu'aucun langage pour la JVM n'est aussi bien servi question outillage que java, c'est objectivement assez vrai.
• Que java c'est globablement du terrain connu et qu'on a des chances de trouver les réponses (forte communauté, grosse présence sur stackoverflow), c'est vrai
• Qu'introduire un autre langage comme Scala ou Groovy accroît les risques de maintenance et ne devrait pas être pris à la légère, c'est largement défendable aussi.
• Qu'il faut donc des arguments vraiment solides pour justifier l'emploi de ces langages alternatifs en entreprise dans le contexte particulier de son projet sous peine que ça vous retombe lourdement dessus en cas de problème, c'est plutôt vrai aussi.

Donc pour commencer, avant de lâcher des pavés du style "Qu'il essaie de faire XX avec son java de merde" ou encore "si on l'écoutait, on ferait du Cobol", franchement allez lire la source.

Ayant commis l'erreur de ne pas consulter la source, les propos deviennent tout de suite plus pertinents. Mais celà vaut aussi pour des technologies similaires qui ne sont pas forcément liées à la JVM. S'il y a un vrai gain, ça vaut peut-être valoir le coup soit de dispenser une formation commune (même si ça prend une semaine), soit de chiffrer un peu large, s'il y a de la marge, sachant qu'un bon dev consciencieux sait se "débrouiller", même s'il dépasse un peu les horaires théoriques (c'est relativement courant, même s'il ne faut pas en faire une habitude).

[_skip]

Ayant commis l'erreur de ne pas consulter la source, les propos deviennent tout de suite plus pertinents. Mais celà vaut aussi pour des technologies similaires qui ne sont pas forcément liées à la JVM. S'il y a un vrai gain, ça vaut peut-être valoir le coup soit de dispenser une formation commune (même si ça prend une semaine), soit de chiffrer un peu large, s'il y a de la marge, sachant qu'un bon dev consciencieux sait se "débrouiller", même s'il dépasse un peu les horaires théoriques (c'est relativement courant, même s'il ne faut pas en faire une habitude).

Il y a pas de réponse simple à ce problème. C'est forcément un trade-off, comme dit dans l'article (qui n'est décidément pas si con) il existe parfois de vrais arguments en faveur d'un changement, ça peut même se jouer non pas rien qu'au niveau du langage mais aussi du framework pour un même langage. Faut juste que la prise de risque soit contrebalancée par un gain vraiment concret (meilleure productivité, maintenance, etc...). En voulant changer, tu vas générer de la friction, des membres de l'équipe vont peut être perdre leurs repères et il y a toujours un danger de se vautrer (qu'on peut souvent atténuer mais rarement totalement éradiquer).

C'est comme souscrire une assurance, tu peux choisir de sacrifier plus d'argent pour plus de sécurité, tu peux jouer la chance, motivé par un gros potentiel d'économie (voire carrément faire le con ) ou tu peux payer le prix fort pour ne courir aucun risque jusqu'au ridiculement déraisonnable. Faut voir après ou tu veux mettre la barre dans la multitude de solutions entre-deux qui existent.

Souvent, on quitte un terrain connu, c'est à dire un langage ou un framework dont on connaît les limites, les pièges et les implications pour se tourner vers de l'inconnu. Forcément ça ajoute de l'aléatoire, et même si on fait des efforts d'apprentissage et de formation, on se rend compte que passé le "wouah effect" initial, il y a obligatoirement à un moment ou à un autre des complications qui surviennent et là faut avoir bien assuré le coup. Cependant ça peut être trop tard, tu trouves des tonnes de témoignage par exemple de gens qui ont investi dans des technos, initialement poussés dans cette direction par des résultats probants et rapides, et qui en ont malheureusement fait les frais que dans une phase très (trop?) avancée du projet.

Perso en bon geek, j'aime le changement, ma stratégie pour le faire accepter est d'éprouver les nouveautés dans des projets personnels ou alors de les suggérer dans un projet non stratégique de mon entreprise. Mais là encore je dois faire super gaffe et prendre sur moi de démontrer la plus-value de mon approche, en pensant bien que ce qu'on veut surtout pas c'est se retrouver avec des choses que je suis le seul à pouvoir maîtriser. Il faut jamais sous-estimer que ça peut représenter de pousser un changement, on sait toujours ce qu'on laisse, mais pas forcément ce qu'on trouve. Etre audacieux c'est bien, être prudent c'est pas mal non plus.

[Traroth2]

J'ai lu l'article de Sam Atkinson et je pense que son propos sur java fait entièrement du sens. C'est juste qu'il vous est rapporté entièrement sorti de son contexte.



Je vais pas citer tout l'article mais déjà clairement, au vu des langages qu'il cite, il parle des langages pour la JVM!

Donc lorsqu'il en arrive à son argumentaire comme quoi Java est le meilleur choix parmi ceux-ci, c'est pas dans le sens "C++, javascript, php, .net et tout le reste du monde c'est de la merde" comme on pourrait le croire dans les fragments repris en français de ce topic. Déjà en limitant le scope de son affirmation aux langages pour la JVM, son propos a tout de suite moins l'air d'une bêtise, sachant que les langages destinés à produire du bytecode pour la JVM adressent généralement les mêmes besoins et sont dans la plupart des cas *relativement* interchangeables.

En gros ce qu'il dit :

• Qu'aucun langage pour la JVM n'est aussi bien servi question outillage que java, c'est objectivement assez vrai.
• Que java c'est globablement du terrain connu et qu'on a des chances de trouver les réponses (forte communauté, grosse présence sur stackoverflow), c'est vrai
• Qu'introduire un autre langage comme Scala ou Groovy accroît les risques de maintenance et ne devrait pas être pris à la légère, c'est largement défendable aussi.
• Qu'il faut donc des arguments vraiment solides pour justifier l'emploi de ces langages alternatifs en entreprise dans le contexte particulier de son projet sous peine que ça vous retombe lourdement dessus en cas de problème, c'est plutôt vrai aussi.

Donc pour commencer, avant de lâcher des pavés du style "Qu'il essaie de faire XX avec son java de merde" ou encore "si on l'écoutait, on ferait du Cobol", franchement allez lire la source.

Effectivement, ça tient tout de suite beaucoup plus debout, surtout depuis la sortie de Java 8, qui refait quand même énormément le retard de Java en matière de concepts de programmation.