Discussion :

[Amine Horseman]

Un développeur devrait-il apprendre plusieurs langages ?
Ceci est « une mauvaise idée », selon un sénior

Dans un billet de blog publié sur Core Java Interviews Question, Sam Atkinson, blogueur et directeur de développement à HSBC nous explique son point de vue sur les développeurs polyvalents qui aiment essayer de nouveaux langages et pourquoi c’est « une mauvaise idée » selon lui.

En effet, Sam Atkinson affirme que les langages bien mûrs comme java sont suffisants pour faire le travail, et il n’est pas nécessaire pour un développeur maîtrisant ce langage d’apprendre de nouveaux : cela « va être un cauchemar de maintenance », même si « vous connaissez déjà le langage en question » prévient-il.

« Java est utilisé depuis longtemps et a un ensemble incroyable d'outils et de bibliothèques autour de lui » ajoute Atkinson en citant l’exemple d’IntelliJ. « Un outillage de ce type n’existe pas de façon mature dans les autres [nouveaux] langages [...] Il y a aussi le manque de documentation et de soutien en ligne ». Toutefois, ce n’est pas le fait de maîtriser plusieurs langages qui pose problème selon lui; bien au contraire, il affirme que ceci est « nécessaire » pour avoir un bon CV et que c’est « une excellente façon de changer sa manière de penser concernant le style de codage ». Cependant, ce qui lui pose problème c’est le fait que les développeurs profitent souvent des projets qu’ils réalisent pour apprendre ces nouveaux langages.

Pour illustrer ce dernier point, il cite un article de Yegor Bugayenko, co-fondateur et directeur de technologie à teamed.io, qui avait écrit dans son blog que « chaque projet de logiciel est un business, et nous, les développeurs, sommes ses ressources ». Par conséquent, si on utilise les projets pour apprendre : « ça sera du vol », et un bon gestionnaire de projets ne doit jamais accepter, car « ce n’est pas une école ».

Bugayenko nous explique ensuite que si on contacte un plombier pour installer un système de drainage dans notre maison, et que celui-ci nous dit qu’il n’a jamais travaillé sur une telle tâche, nous n’accepterons jamais de dépenser notre argent pour qu’il puisse se former. De la même façon, en tant que développeurs, « nous voulons apprendre, mais nous ne voulons pas dépenser notre propre argent pour ça. Nous ne voulons pas rester à la maison pendant quelques années pour apprendre toutes les technologies possibles avant d'entrer dans le marché du travail […] Nous voulons apprendre sur le tas ». Or, un programmeur qui ne possède pas les compétences adéquates est « une ressource non fiable » et « aucun projet ne prendrait une telle ressource depuis le début ».

Concernant Sam Atkinson, nous pouvons néanmoins discuter les gains apportés par l’utilisation de nouveaux langages par rapport aux coûts nécessaires à leur apprentissage, et rester toujours prêts à nous reconvertir dans ces langages si cela est plus avantageux.

Source : Article de Sam Atkinson, Article de Yegor Bugayenko

Pensez-vous qu’apprendre plusieurs langages est une mauvaise chose ?
Que pensez-vous de l’avis d’Atkinson et de Bugayenko ?

[el_slapper]

Les deux articles sont fort différentes l'un de l'autre.

Celui de Yegor Bugayenko, en gros, dit qu'on ne devrait pas avoir à apprendre au cours d'un projet. Point. Celui de Sam Atkinson dit, lui, que Java permet de résoudre tous les problèmes, et est standard, donc aucun autre langage n'est utile.

Je ne suis d'accord avec aucun des deux articles. Le développement est une activité hautement fluide, contrairement à la plomberie prise en comparaison. Si un plombier met une heure à installer un lavabo(chiffre complètement au pif, je n'y connais rien), il mettra à peu près dix heures pour en installer dix similaires. Peut-être 9 et demi avec l'effet d'expérience. Si un développeur met 10 heures à coder un envoi de mail, pour les 9 autres, il réutilise le code, voire l'encapsule, et ne mettra pas beaucoup plus de temps.

Surtout, si on encapsule proprement, on gagne beaucoup de temps pour la suite du projet - et pour la maintenance. Un contenu informatique n'est pas comme un bâtiment, c'est très vivant, et ça change tout le temps. Prendre le temps d'enseigner les spécificités dudit ensemble, ça permet de gagner du temps tout de suite - le programmeur sera plus opérationnel - et plus tard - on aura un ensemble cohérent. Chaque projet est différent, et croire qu'il suffit d'en maitriser un pour maitriser les autres me parait hautement illusoire.

Pour ce qui est du Java, c'est effectivement un langage qui permet de tout faire. Mais la contrepartie est qu'il n'est pas spécifiquement à adapté à tel ou tel besoin. Il est généraliste. Pour des sujets spécialisés, d'autres langages survivent ou même se développent. J'ai souvenir d'un batch comptable réalisé dans une banque de taille moyenne dont les grands chefs rêvaient de "tout Java", et qu'on m'a fait faire en Cobol. Parceque j'étais deux fois moins cher.

Ca ne veut pas dire que Java est toujours un mauvais choix, mais comme toute création humaine, il a ses limites, et affirmer de but en blanc que c'est toujours le bon choix, c'est à la limite de la croyance religieuse.

[fatbob]

Moi non plus, je ne suis pas d'accord avec ces articles.
Pour ce qui concerne Java, j'ai essayé et je n'ai jamais réussi à m'y mettre vraiment. J'ai toujours trouvé le développement en java d'une lourdeur sans égale dans les autres langages que j'ai pu tester (peut-être C++ ?). Il est évident que pour un développeur chevronné dans ce langage, ce point doit s'amenuiser avec le temps mais quand même. Pour la lisibilité et la maintenance, pour ma part, je préfère python (de loin).

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

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 ?

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.

[TiranusKBX]

Il est clair que pour un développeur tel que Sam Atkinson qui reste dans le domaine financer le changement c'est pas souvent
De ce fait il ne peut voir ce qui se passe dans d'autres secteurs, et quand on développe pour des milieux économiques différents
l'on doit s'y adapter, d'où l'apprentissage de nouveaux languages

[Mouke]

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

En excluant HTML/CSS, il est possible aujourd'hui de faire une app web en javascript de à A à Z : frontend avec jQuery, backend avec node.js, db avec MongoDB.

[fatbob]

En excluant HTML/CSS, il est possible aujourd'hui de faire une app web en javascript de à A à Z : frontend avec jQuery, backend avec node.js, db avec MongoDB.

Plutôt me recycler dans la fabrication de fromage.

[Saverok]

L'une des choses que je préfère en info est que ça bouge tout le temps à tous les niveaux.
Il y a constamment de nouvelles API, nouveaux framework, langages, etc, etc, etc
L'innovation est constante et partout
Et pas uniquement dans la pure technique mais aussi dans les usages et le métier.

Je ne suis pas spécialement vieux, enfin je crois lol, et lorsque j'ai débuté, le tactile se limitait aux bornes et on ne parlait absolument pas de la mobilité et encore moins du social.
Aujourd'hui, impossible de faire sans
Bref, faut constamment s'adapter

Si on ne se forme pas à l'occasion d'un projet, à quel moment peut on le faire ?
C'est en grande partie aux entreprises de former leurs salariés et je n'ai jamais rencontré d'entreprises qui investissent en formation au niveau auquel avance les innovations du monde info

[LSMetag]

Evidemment je suis en total désaccord avec cet article qui ne fait que rappeler certains aspects qui me répugnent dans le développement informatique (et qui m'ont poussé à la démission).

Ok, un projet a sa part de "business" et nous sommes en effet des ressources. Seulement, contrairement au plombier, on bosse en équipe. On a une hiérarchie avec qui discuter et des collègues pour s'entraider et contrôler la qualité de la prestation.
On n'est pas forcément là JUSTE pour faire le job, avec un truc possiblement bancal qui va plus ou moins bien marcher, agacer les utilisateurs, possiblement réduire la productivité si la techno n'est pas adaptée et qui sera un cauchemar à maintenir.

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.
Enfin bon, c'est un écueil chez les "séniors". Dès qu'il s'agit de changer une habitude bien ancrée et d'apprendre, c'est dur. C'est pour ça qu'on préfère des jeunes, plus malléables.

Le monde évolue, les technologies évoluent, les tendances évoluent, les supports évoluent, les formations évoluent,...

Java est certes une technologie mature, sur beaucoup de supports. Mais il faut rappeler que ses problèmes de sécurités font débat, son aspect usine à gaz aussi. Il peut être contre-productif de créer une architecture J2EE inadaptée pour une solution qui serait bien plus performante, simple (en matière de code/architecture), fiable et maintenable avec du simple Javascript/TypeScript + Node.js (ou du Dart pour les gens comme moi qui n'aiment pas JS) , passant par des WebSockets par exemple. En plus ça coûterait beaucoup plus cher.
Bref, il est important d'au moins "connaître" plusieurs technologies pour avoir des marges de manoeuvre pour répondre de manière plus pertinente au besoin.

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. Ce n'est pas à un commercial de dire "on prend ça parce qu'on a fait comme ça avant et qu'on a des partenariats avec tel fournisseur".
La dernière fois où c'est arrivé, on remplaçait une équipe qui venait de se faire virer, sur un projet au développement cauchemardesque, aux performances cauchemardesques, où l'on était tributaire des bugs du fournisseurs des outils de développement (IBM), avec des clients mécontents d'office,... La compétence de la précédente équipe n'était pas en cause...C'est les choix techniques "sûrs".
Je me demande ce qu'il en est advenu...

[martopioche]

Je ne suis d'accord avec aucun des deux articles. Le développement est une activité hautement fluide, contrairement à la plomberie prise en comparaison. Si un plombier met une heure à installer un lavabo(chiffre complètement au pif, je n'y connais rien), il mettra à peu près dix heures pour en installer dix similaires. Peut-être 9 et demi avec l'effet d'expérience. Si un développeur met 10 heures à coder un envoi de mail, pour les 9 autres, il réutilise le code, voire l'encapsule, et ne mettra pas beaucoup plus de temps.

Très mauvaise analogie avec le bâtiment car elle néglige que... Le bâtiment "encapsule" et "factorise" également... Si on doit comparer plombier qui installe un lavabo avec un développeur qui envois un courriel, lavabo = fonction d'envois de courriel et installation = intégration... Et mine de rien, là où le plombier va passer du temps se prendre la tête avec le câblage... Le développeur aussi.

Là dessus, l'analogie est identique pour l'évolution : tant que le plombier/dev utilisent le matériel connu, ils sont efficace, mais le jour où on demande à l'un ou l'autre d'installer un autre "modèle" (un robinet rhéostatique/configuration différente, techno différente), l'efficacité ne sera plus la même.

[landry161]

Chaque projet est différent, et croire qu'il suffit d'en maitriser un pour maitriser les autres me parait hautement illusoire.

Très illusoire

[Greg-dev]

En effet, Sam Atkinson affirme que les langages bien mûrs comme java sont suffisants pour faire le travail, et il n’est pas nécessaire pour un développeur maîtrisant ce langage d’apprendre de nouveaux : cela « va être un cauchemar de maintenance », même si « vous connaissez déjà le langage en question » prévient-il.

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

[KeatsPeeks]

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

Spring MVC, Struts, GWT, JSF...
(en considérant que le JSP fait partie du Java bien sûr).

[Invité]

Plutôt que d'apprendre xx langages, un développeur devrait plutôt se concentrer sur les peu qui lui servent au quotidien, et de monter en compétence au niveau théorique. De cette façon il sera capable de répondre à un maximum de demandes puisqu'il saura comment ça fonctionne, il sera capable d'apprendre un nouveau langage au besoin car il connaitra les différents paradigmes de programmation, il sera capable d'avoir un avis éclairé sur les diverses façons d’exécuter des taches et d'en donner les forces et faiblesses, et ainsi de suite.

[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.

[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).

[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.

[stendhal666]

Tout d'abord, la dernière fois qu'un plombier est venu chez moi pour installer un évier, il s'est rendu compte que les canalisations derrière étaient d'un type qu'il ne connaissait pas. S'il m'avait dit, attendez, je refais tout avec des matériaux que je connais, que lui aurais-je répondu? Oui, oui, très bien restez dans votre zone de confort, refaites toute ma maison en Java tant que vous y êtes?

Ou bien s'il m'avait dit: vos chiottes sont toutes petites, je vais vous installer des gogues minus mais avec un nouveau système de branchement, je lui aurais dit: non, non! des chiottes Java, même si je peux plus fermer la porte?

La force du secteur informatique a toujours été qu'à côté de mastodontes obligés de gérer tout un héritage de code, de nouveaux langages émergent, suffisamment flexibles pour ajouter de nouvelles possibilités en terme d'expressivité, de maintenabilité, de puissance, etc. Pour certains projets, selon les exigences, il peut tout à fait être intéressant de se lancer dans des pistes nouvelles: les risques sont plus élevés, d'accord, mais l'espérance de gain également. Si je veux griller la politesse à la concurrence, un langage de développement rapide, comme Python, peut être intéressant, en particulier si j'ai besoin de l'appui de non spécialistes de la programmation -analystes de données, mathématiciens, par exemple, qui sont de plus en plus souvent familiers avec ce langage.