Le topic de la programmation: Et envoyez des sioux!

[Frypolar]

La satisfactance

Tu réalises quand même que ce que tu décris depuis quelques pages c’est le comportement classique d’un IDE depuis des années, chose qu’on doit tous connaître ici ? T’en as jamais eu avant ?

En tout cas ça explique pourquoi tu préfères imprimer des centaines de ligne de code plutôt que de faire tes recherches sur une machine

[Dross]

Attends qu'il découvre que l'autocomplétion est à l'IDE ce que l'addition est aux mathématiques.

[vectra]

La complétion et la lecture de code custom massif n'ont à mon sens rien à voir. Je pense que ça ne se passerait pas mieux si on reprenait le problème aujourd'hui avec la complétion, ça se finirait aussi mal que ça s'est fini là (de plus, je n'étais pas sur emacs là).

J'avais déjà sous emacs une auto-completion depuis plusieurs années, mais partielle. Rapide, par contre.
Ce qui manquait, c'était quelque chose de la classe d'intellisense.
Sauf que quand j'ai essayé Intellisense sur vs.code, ça marchait mieux, mais jamais à 100% ce qui est vite frustrant.
Là, j'ai du 100%. Sur le tard, certes, mais 100% et aucune erreur.

[TarteAuxFleurs]

Moi je tiens à dire que tu vends bien emacs vectra !
Je vais ptet sortir de mon vim

[vectra]

C'est dommage, il parle assez mal d'org-mode, ce truc assez récent qui est devenu une vraie killer-feature (jupyter-notebook universel en beaucoup mieux). On peut même éditer son .emacs en litterate programming, et ça marche pour d'autres fichiers de configuration aussi a priori.

[Orhin]

Sauf que quand j'ai essayé Intellisense sur vs.code, ça marchait mieux, mais jamais à 100% ce qui est vite frustrant.

Non mais VSCode c'est pas un IDE hein, juste un bon éditeur de texte avec quelques pluggins puissants.
Mais ça reste à des années lumières d'une solution complète comme IntelliJ.

[Tramb]

Faut arrêter avec les IDEs, un peu, le monde a pas attendu la complétion à bout de doigts pour faire des gros programmes.
Et tous les langages à appels de fonctions prefix n'en bénéficient pas des masses (C, Caml, Lisp et j'en passe).
Après dans les descendants de Simula/Smalltalk qui font obj.f pour le message passing (et qui perdent le multiple dispatch :-p ), c'est pratique c'est sûr. Mais c'est pas ça qui double une productivité.
(Bon ok, j'avoue, je ne peux pas m'en passer :D)

[vectra]

Non mais VSCode c'est pas un IDE hein, juste un bon éditeur de texte avec quelques pluggins puissants.
Mais ça reste à des années lumières d'une solution complète comme IntelliJ.

J'ai topé une licence gratuite full-legit. J'ai vraiment l'intention de m'y mettre pour le déboguage. Non pas qu'emacs débogue mal, mais pour ce que j'ai vu d'Eclipse-CDT et de son débogueur, ça risque de *me* prendre du temps pour arriver au même niveau de détail (qui déboite). J'attends donc Intellijo là-dessus, en espérant qu'il importe directement mes projets CMake (autre effort pour moi, et pas des moindres).

[Dross]

Faut arrêter avec les IDEs, un peu, le monde a pas attendu la complétion à bout de doigts pour faire des gros programmes.

Non, mais ils avaient une autre façon de coder aussi : méga-class "pour dérouler le code" (haha) et autres pratiques considérées comme des anti-pattern avec les outils d'aujourd'hui. Un IDE c'est pas juste l'autocompletion, mais aussi la navigation du code, les outils de refactoring, les templates, les outils de tests intégrés (retours graphiques (résultat et couverture de code) etc), les outils de déploient intégré, la doc, les stats/historique (qui a modifié cette partie du code la dernière fois, et quel est son historique (directement dans l'éditeur du code, bien affiché dans le code, pas à coté), combien de fois cette méthode est appelée dans le codebase) etc.

Tout ça, si si, ça fait une différence au niveau de la productivité et réduit considérablement le time to market.

Après si vous bossez avec des langages/stacks incompatibles, mes condoléances, mais pour les autres, y'a aucuns argument valide pour ne pas utiliser un IDE (autre que vous êtes payé a l'heure et qu'un temps de développement long vous est directement bénéfique).

[Nilsou]

My 2 cents sur les ides : au labos on utilise le classique Eclipse depuis pas mal d'années, et pour le moment on a pas vraiment trouvé mieux.

Bon par contre le principal soucis, c'est que les deux IDE un peu complète que je connais, compatible linux, multi-language etc... sont des machines de guerre qui, sur un CPU à 5000 boules dernières génération, SSD et ram de la mort qui tue n'offrent que des performances médiocres sur les gros projets.
Sur Eclipse typiquement, je ne peut pas dire que quelque soit la config, je l'aie (je l'eusse ? je l'eu ? je l'ai eu ? ) vu tourner avec une fluidité convenable. Des retours que j'ai eu c'est encore pire sous InteliJ...
Peut-être parce qu'ils sont basés sur Java ? Une idée originale d'ailleurs pour de si gros logiciel lourd ...

Si quelqu'un connais un bon équivalent d’Eclipse super fluide, multi-plateforme et complet, au moins vis à vis du C/C++... j’achète.

[Tramb]

Non, mais ils avaient une autre façon de coder aussi : méga-class "pour dérouler le code" (haha) et autres pratiques considérées comme des anti-pattern avec les outils d'aujourd'hui. Un IDE c'est pas juste l'autocompletion, mais aussi la navigation du code, les outils de refactoring, les templates, les outils de tests intégrés (retours graphiques (résultat et couverture de code) etc), les outils de déploient intégré, la doc, les stats/historique (qui a modifié cette partie du code la dernière fois, et quel est son historique (directement dans l'éditeur du code, bien affiché dans le code, pas à coté), combien de fois cette méthode est appelée dans le codebase) etc.

Ah les patterns et anti-patterns. Le gang of four a fait beaucoup de mal au développement à toute une frange de programmeurs qui reste kéblo sur l'objet par message passing de Java et du vieux C++.
https://www.norvig.com/design-patterns/
Quant aux outils de refactoring, tu les oublies dans les langages très dynamiques ou avec des macros. Et même dans du C++ non trivial avec du préproc, tu peux pas compter dessus.
Pour la navigation, pour les langages sans overloading, grep + regex ne souffre pas d'ambigüités rédhibitoires.
Tu parles des templates, c'est finalement une manière plus chic de dire copier/coller et boilerplate pour les langages pas assez expressifs (et ils sont nombreux )

Tout ça, si si, ça fait une différence au niveau de la productivité et réduit considérablement le time to market.

C'est sûr. Mais la qualité du code a significativement augmenté, tu penses ? Y a moins de bugs et d'exploits ?
Moi j'ai surtout vu des différences de x10 sur la productivité des programmeurs (avec les meilleurs qui sont en plus intouchables sur la correctness, je ne parle pas de porcs qui hackent n'importe quoi pour faire genre c'est trop de roxxors).
Alors le x2 d'un IDE moderne me semble nice mais pas fondamental.

Après si vous bossez avec des langages/stacks incompatibles, mes condoléances, mais pour les autres, y'a aucuns argument valide pour ne pas utiliser un IDE (autre que vous êtes payé a l'heure et qu'un temps de développement long vous est directement bénéfique).

Y a des gens qui bossent sur des "langages/stacks incompatibles" (genre Common Lisp) et qui mettent probablement tous les gens présents ici à l'amende en productivité avec Emacs (on peut dire que c'est un IDE, remarque, mais c'est un IDE qui est là depuis un moment).
Tu bosses en quoi, pour ma curiosité ?
Moi/nous C++ essentiellement (embarqué) + asm + un peu de Python pour le scripting + une pincée de Lisp.
J'utilise un IDE (MSVC) pour le C++ pour Windows mais même avec Visual Assist, c'est pas la panacée (loin de là). Et il y a plein de scénarios où il n'est d'aucune aide.

[William Vaurien]

Dans la série des features d'un IDE donnés par Dross, je rajouterais, entre autres, la possibilité d'avoir un retour immédiat sur la qualité de code avec tout un tas de 'capteurs' qui vont te dire si ton code sent mauvais, voir s'il est complètement pourri. Et aussi la possibilité de brancher (et de fabriquer) des dizaines de plugins.

Je ne doute pas qu'un dev "rockstar" qui connaît ses API par cœur et qui a un compilateur intégré dans son cerveau sera plus efficace que moi. Par contre je serais sûrement un moins bon dev sans ce genre d'outils.

Disons que pour un bon 80% des dev qui bossent avec des langages 'mainstream', un bon IDE (oui je rentre emacs dedans) permet un certains confort. Pour moi c'est plutôt ce point qui est important que la productivité:
avec un IDE j'ai accès à tout un tas d'outils élaborés facilement. Et ces outils ont un impact sur ma productivité, mais aussi et surtout sur la qualité de mon code et sur mon espérance de vie (oui car moins de stress ).
Pour avoir l'équivalent avec emacs et/ou vi il faut quand même s'accrocher (en tout cas pour vi): la phase d'apprentissage est longue et difficile, configurer l'outil est compliqué...

On ne peut décemment pas glorifier d'un côté emacs bourré de plugins et de l'autre descendre les IDE plus moderne... C'est finalement la même chose. Quand je vois la présentation d'Emacs plus haut, j'ai quand même l'impression que certains découvrent la roue: regardez, c'est fabuleux, je peux avoir une barre d'état dynamique avec de la couleur ! et même avoir twitter dans mon emacs...
Je ne dit pas que c'est pas bien, mais je trouve que c'est un peu gonflé de venir cracher sur les IDE 'modernes' (il ont une vingtaine d'années maintenant) et en même temps en glorifier un autre qui finalement fait quasiment la même chose.

Concernant le refactoring, les outils de Jetbrains s'en tirent plutôt bien avec du code dynamique, en tout cas ce que j'ai pu en voir sur du JS et du pyhton. @Tramb, tu sembles graviter dans une sphère un peu particulière et très spécialisée du dev, ta perception est peut être faussé par rapport au flot de dev généralistes qui font du java/c#/angular/whatever.js ? Des dev ASM / Lisp ça ne courent pas les rues non plus...



Concernant les lenteurs d'Intellij, @Nilsou, je pense que tu dois avoir des retours d'expérience datant de 2008 ou alors de personnes utilisant cet IDE avec un PC de cet époque...
Je rencontre des problème de perf avec cet outil dans quelques cas, principalement à cause d'aintivirus mal configuré et lorsque il y a des fichiers sources gargantuesques et/ou des millions de lignes de code. Ce qui malheureusement arrive fréquemment sur la maintenance de vieux codes. Datant d'époque ou faire une classe de 10 000 lignes de code était naturel (probablement édité sous VI) et copié/collé des lignes par paquets de 1000 était une "bonne idée".

[Orhin]

Y a des gens qui bossent sur des "langages/stacks incompatibles" (genre Common Lisp) et qui mettent probablement tous les gens présents ici à l'amende en productivité avec Emacs (on peut dire que c'est un IDE, remarque, mais c'est un IDE qui est là depuis un moment).

Et ?
On parle d'outils utilisés pour la productivité d'équipes de dev, pas pour les génies qui bossent tout seul dans leur coin.

Un dev junior (voir un mec sorti d'école) que tu dois intégrer dans ton équipe va pouvoir utiliser un IDE moderne relativement rapidement du fait de l'ergonomie bien foutue et des raccourcis un minimum standardisés.
Sur Emacs ou VI il pleure.

Concernant les lenteurs d'Intellij, @Nilsou, je pense que tu dois avoir des retours d'expérience datant de 2008 ou alors de personnes utilisant cet IDE avec un PC de cet époque...
Je rencontre des problème de perf avec cet outil dans quelques cas, principalement à cause d'aintivirus mal configuré et lorsque il y a des fichiers sources gargantuesques et/ou des millions de lignes de code. Ce qui malheureusement arrive fréquemment sur la maintenance de vieux codes. Datant d'époque ou faire une classe de 10 000 lignes de code était naturel (probablement édité sous VI) et copié/collé des lignes par paquets de 1000 était une "bonne idée".

Ceci.
Entre IntelliJ, Visual Studio et Eclipse, c'est sur les 2 derniers que je constate surtout des lenteurs (mais Eclipse s'améliore pas mal sur les dernières versions).

[Tramb]

Je ne doute pas qu'un dev "rockstar" qui connaît ses API par cœur et qui a un compilateur intégré dans son cerveau sera plus efficace que moi. Par contre je serais sûrement un moins bon dev sans ce genre d'outils.

Non mais pareil pour moi, hein. C'est juste que faut pas dismiss les gens qui bossent sans.

[vectra]

Pour info, la vidéo était un troll à destination des Vim-users. Oui, je trolle souvent, mais il y a une différence entre "venir cracher sur" et le "ça marche pas, je fais quoi?".

J'avais testé vs.code en toute bonne foi dans mon ancien taf' parce que mes collègues directs du moment s'y étaient mis, et j'en suis simplement revenu parce que je n'y ai pas trouvé ce que je souhaitais, alors même que ce n'était pas un vrai IDE mais plutôt un smart editor comme le disaient déjà mes collègues. Et, en général, je n'ai pas vu que des cadors de l'IDE dans le monde professionnel: pas mal de gens se contentent de solutions très mainstream et font juste avec les fonctions courantes.

A la base, pour travailler efficacement, on a besoin d'un IDE qui couvre tous nos besoins, et dans lequel on soit suffisamment proficient, ce qui implique de passer du temps à apprivoiser la bête, d'apprendre un bon nombre de shortkeys, et comprendre un minimum comment créer quelques macros, fonctions, et plugins qui vont bien. J'ai fait cet effort considérable avec emacs parce que c'est ce qu'on nous a inculqué et qu'il est adapté au workflow universitaire.

Je vois bien l'intérêt pour IntelliJ, que je ne nie pas comme je l'ai répété sur cette même page, c'est juste que je sais que ça va prendre du temps de partir de la base pour arriver là où j'en suis sur emacs, avec de toutes façons un workflow qui n'est pas celui d'un vrai dev, soyons clairs là-dessus. Ce n'est pas le métier que j'ai appris, même si je fais du dev et que je m'efforce d'être à jour des techniques et pratiques.

Pour ceux qui pensent que l'usage de Vim/Emacs est un handicap flagrant dans la vie professionnelle, je dis oui, effectivement, dans le cas d'un dev moyen qui bosse sur un plateau. A moins d'avoir des gens déjà très proficients et efficaces sur Vim/Emacs (oui, ça existe), faut pas leur mettre ça entre les mains, surtout en vanilla: ça n'a pas de sens et personne ne dit cela ici, surtout moi. Partout où j'ai été, on laisse le choix des armes aux gens, tant que c'est gratuit (hé :/) et que le travail suit. Après, j'ai vu des gens sous Vim chez Intel & co, donc ça n'est pas forcément un obstacle au talent, même si ça ne le fait pas non plus.

En apparté, un collègue m'a rapporté l'usage de Spacemacs dans une boite du coin, une distribution d'emacs avec déjà une sélection de modules configurés et les plugins dont j'ai parlé. J'aurais peut-être mieux fait de partir de ça directement, mais j'ai préféré refactorer ma base pour garder en vitesse et en contrôle.

[William Vaurien]

Perso je suis pour que chacun utilise l'outil qui lui correspond le plus, dans la mesure ou l'outil ne dénature pas le code et ou il ne faut pas passer 3h / jour à maintenir l'outil.
Je déteste par dessus tout que tel ou tel outil soit considéré comme LE standard quand ce n'est pas justifié.

Ma remarque sur les vi fans qui crachent sur les IDE était général, pas adressé en particulier à quelqu'un: c'est plutôt juste la lassitude de lire à gauche à droite des postes idiots, écrit par des gens pleins de certitudes et de suffisance, sur la supériorité de 'bidule' et la médiocrité des utilisateurs de 'truc'.

Aller je retourne compiler du C...

[vectra]

Ma remarque sur les vi fans qui crachent sur les IDE était général, pas adressé en particulier à quelqu'un: c'est plutôt juste la lassitude de lire à gauche à droite des postes idiots, écrit par des gens pleins de certitudes et de suffisance, sur la supériorité de 'bidule' et la médiocrité des utilisateurs de 'truc'.

Ca me chagrinerait d'avoir laissé cette impression-là, sincèrement...
Surtout que quand tu utilises un truc qui a vaguement l'air rétro, deux fois sur trois, tu te fais basher direct en open-space, peu importe ce qui sort comme boulot.

[Charmide]

Je pense que le taux de hipsters versus vieux cons versus gens raisonnables dépend pas mal du secteur voire de l'organisation, en tout cas en discutant avec les gens j'ai vu tous les travers

[Møgluglu]

J'utilise un IDE (MSVC) pour le C++ pour Windows mais même avec Visual Assist, c'est pas la panacée (loin de là). Et il y a plein de scénarios où il n'est d'aucune aide.

Ton argument est invalide. Visual Studio a un mode pour Q# :


Si on en était resté à vim et emacs, on serait encore en train de programmer des machines classiques comme au 2e millénaire.

[William Vaurien]

Ca me chagrinerait d'avoir laissé cette impression-là, sincèrement...
Surtout que quand tu utilises un truc qui a vaguement l'air rétro, deux fois sur trois, tu te fais basher direct en open-space, peu importe ce qui sort comme boulot.

Non, je crois que c'est une réaction en chaîne démarré par ton post, mais pas ciblé contre toi ou un autre.
Ma petite litanie quand je détecte un petite guerre sur les IDE vs emacs vs vi, suivi de Eclipse vs Intellij...

Je suis content pour toi si tu as réussis à avoir un environnement de dev qui te convienne !

[vectra]

Pas exactement, pour être sincère. Je suis content d'avoir unlocké une complétion qui semble parfaite, mais encore lente. Si je veux de la vitesse, je vais devoir changer de plugin pour passer à rtags, ou alors changer de PC (pro).
Et pour le déboguage, je pense directement passer à IntelliJ.

Pour finir sur une note consensuelle, je dirais qu'avec CMake et git, il n'y a jamais eu autant de facilités à développer un même projet sur plusieurs IDE en même temps :colombe: :rameau:

[Tramb]

Si on en était resté à vim et emacs, on serait encore en train de programmer des machines classiques comme au 2e millénaire.

Dieu (le mec qui ne joue pas aux dés?) nous en préserve.

[Tramb]

Si quelqu'un connais un bon équivalent d’Eclipse super fluide, multi-plateforme et complet, au moins vis à vis du C/C++... j’achète.

Essaie QtCreator, c'est gratos,

[Dross]

Ah les patterns et anti-patterns. Le gang of four a fait beaucoup de mal au développement à toute une frange de programmeurs qui reste kéblo sur l'objet par message passing de Java et du vieux C++.

Un pattern c'est une bonne pratique, c'est complètement synonyme. Un "design pattern", c'est une solution éprouvée pour un problème récurant, ça ne peut donc par définition pas faire du mal aux devs, et faut arrêter avec le gang of four, c'est très vieux et la moitié du bouquin est maintenant intégré en dur dans les langages modernes, et l'autre moitié a été jeté à cause des nouveaux outils (par exemple, on considère le singleton comme un anti-pattern maintenant qu'on a l'injection de dépendance et la gestion du cycle de vie).

https://www.norvig.com/design-patterns/
Quant aux outils de refactoring, tu les oublies dans les langages très dynamiques ou avec des macros. Et même dans du C++ non trivial avec du préproc, tu peux pas compter dessus.

Je l'ai déjà dit, si t'a une stack pas compatible (je suis conscient qu'il y en a), t'a pas le choix alors il n'y a pas de débat.

Mais la qualité du code a significativement augmenté, tu penses ? Y a moins de bugs et d'exploits ?

Lors d'ajouts de fonctionnalités ? Clairement.

Tu bosses en quoi, pour ma curiosité ?

En quoi et "sur quoi" surtout, je suis en start-up, on est 2 dev et on a été 3 pendant quelques années (il a dus retourner en France). Juste à 2-3, on maintient 5 produits desktops basés sur une techno de recherche in-house, et une plateforme web avec API de gestion/API d'utilisation/Pipeline de traitement en Event-Sourcing/Frontal SPA (avec affichage 3D en WebGL etc). Ce sont des outils à destinations du bureau d'étude en mécanique, nos clients sont les grosses entreprises qui vous viennent en tête quand vous pensez Avion, Voiture, Sport, Armée. On est compatible avec les CAO les plus connus du marché et la plupart des PLM/PDM.
Tout ça en 6 ans.
Avec de nombreuses versions et migrations technologiques en prime (winform -> WPF, api WCF -> asp.net -> asp.net core, asp.net mvc + knockout -> asp.net core + angular, app desktop single thread -> multi-tread "à la dur" -> multi-thread "managé" (Task, TPL), etc).

Tout nos concurrents sont des mastodontes avec des armés de devs, et nos clients nous préfèrent quand même (parfois en achetant nos outils après avoir acheté les leurs).

On prends les outils qui nous permettent de faire beaucoup et vite avec peu. Donc (comme dit plus haut) notamment C# .NET, Angular, PaaS et SaaS sur Azure, le tout sous IDE, et tout outils ou workflows nous permettant d'aller plus vite (JetBrains dans VS ? C'est cool on prends. LINQpad ? C'est cool on prends. Etc), avec une meilleure qualité à chaque fois. Mais on n'est pas dogmatique, si demain avec du C et Vi on pouvais aller encore plus vite on aurai déjà migré dessus. Mais ce n'est pas notre conviction.
Et on surveille chaque techno avec cette vision non restrictive (A tiens c'est quoi ce truc, Node.js ? Ça pourrai nous servir tu pense ? Ah et Python t'a vu ? Ça fait quoi ? Pourquoi les gens utilisent ça ? T'a vu le stagiaire il sait faire du R, ça va nous aider. etc).

On est des fanatiques des tests et des nouveaux bidules comme l'intégration continue car on s'est payé les problèmes qu'ils résolvent en pleine gueule à chaque fois. Et à chaque problème on s'est regardé et on s'est dit "putain plus jamais, comment font les autres ?". Et on les a résolu un a un, pour aboutir au résultat actuel (et ma vision actuelle).

Je suis conscient que tout le monde ne vis pas avec mes problématiques, mais si on parle de productivité pure/viabilité des projets, je pense que je suis pas trop mal placé pour en parler.

[Tramb]

Avec de nombreuses versions et migrations technologiques en prime (winform -> WPF, api WCF -> asp.net -> asp.net core, asp.net mvc + knockout -> asp.net core + angular, app desktop single thread -> multi-tread "à la dur" -> multi-thread "managé" (Task, TPL), etc).

Mais pourquoi ?

- - - Mise à jour - - -

Un pattern c'est une bonne pratique, c'est complètement synonyme. Un "design pattern", c'est une solution éprouvée pour un problème récurant, ça ne peut donc par définition pas faire du mal aux devs, et faut arrêter avec le gang of four, c'est très vieux et la moitié du bouquin est maintenant intégré en dur dans les langages modernes, et l'autre moitié a été jeté à cause des nouveaux outils (par exemple, on considère le singleton comme un anti-pattern maintenant qu'on a l'injection de dépendance et la gestion du cycle de vie)..

Le lien que j'ai foutu c'est pour montrer que la moitié du bouquin était déjà inutile dans certains langages de l'époque. Et je me méfie du "on", c'est ce "on" qui foutait des singletons partout y a 20 ans, et qui considère que c'est un anti-pattern.
Alors que la programmation a pas changé des masses

[Dross]

Mais pourquoi ?

Pour régler les problèmes.

Le winform ça vieilli mal et on osai plus y toucher (à chaque modif ça explosai de tout les cotés, alors qu'avec WPF en MVVM ça ne le fait plus (le winform ça supporte très mal le databinding, pas faute d'avoir essayé d'ailleurs)).
WCF c'est lourdingue et lent, pas toujours facile à coupler avec les autres techs.
ASP.NET Core car ça tourne sur linux et donc moins cher sur Azure (+ moins de bordel de base, donc théoriquement plus performant, n'a plus les incohérences ASP.NET MVC/API (je pense aux classes de contrôleurs disjointes)).
Razor + Knockout c'est la merde pour faire une app qui fini par se comporter comme une SPA, donc on a pris un framework SPA histoire de pas réinventer la roue.
Multi-thread pour des questions d'efficacité et de prix (avoir une app qui fait le même travail que 10 app en parallèle bloquant 10 licences CAO, ça commence à chiffrer).
Multi-thread avec les lib qui vont bien pour régler encore une fois les problèmes : certes on avait fini par avoir un moteur multi-thread qui marchais, mais on osait plus le toucher car on avais galéré à le stabiliser (et qu'il était super instable).

Comme je l'ai dit, quand on rencontre un problème on le règle, on reste pas avec "car c'est comme ça qu'on fait". On n'a pas le temps pour ça.

ps: Juste histoire d'expliquer pourquoi je considère qu'on n'a pas le luxe de laisser tel quel : nos outils sont en perpétuel changement, car on n'a pas encore réalisé les 2/3 des fonctionnalités qu'on imagine, de l'autre car nos clients ont leurs demandes propres. Du coup, si tu perds 1 semaine à chaque modif à cause d'un état d'application qui se met en travers de ton chemin, c'est une semaine que tu perds à chaque modif, tu gaspille du temps. Par contre si tu fait la migration qui va te prendre de 1 à 6 semaines en fonction de la nature de la migration, après t'est tranquille et tu ne perds plus du temps de manière cyclique.
Pareil pour les devs futurs, si une nouvelle techno fait que tu mettra 1/2 du temps en moins pour les prochaines itérations, vaux mieux prendre le temps d'y migrer, et le plus tôt possible.

[Orhin]

Sans compter le fait qu'une techno récente généralement :
- sera mieux documentée
- aura une plus grande communauté
- sera mieux suivie (patch de sécu, compatibilité OS/browsers)
- aura un plus gros pool de dev ce qui facilitera le recrutement

[Tramb]

Comme je l'ai dit, quand on rencontre un problème on le règle, on reste pas avec "car c'est comme ça qu'on fait". On n'a pas le temps pour ça.

Je loue ce pragmatisme, mais on pourrait arguer que vous vous créez des problèmes de partir de Winform en passant par tous les nouveaux trucs de MS pour finir par faire une appli portable Windows/Linux.
Niveau UI, depuis 6 ans Qt aurait été bien plus stable, par exemple.

- - - Mise à jour - - -

Sans compter le fait qu'une techno récente généralement :
- sera mieux documentée
- aura une plus grande communauté
- sera mieux suivie (patch de sécu, compatibilité OS/browsers)
- aura un plus gros pool de dev ce qui facilitera le recrutement

Et sera abandonnée plus vite, forçant tout le monde à migrer ou à se taper des bugs et des exploits pendant des années.

[Dross]

Je loue ce pragmatisme, mais on pourrait arguer que vous vous créez des problèmes de partir de Winform en passant par tous les nouveaux trucs de MS pour finir par faire une appli portable Windows/Linux.

Ah mais toutes nos applications n'ont pas fait le chemin complet, on développe et vends encore nos applications WPF par exemple (qui sont bien stabilisées) et elles sont totalement pas portables dans le cloud (pour des raisons technologique, de fonctionnalité et de confidentialité), de la même manière que nos web app sont pour des besoins qui sont totalement différents de ceux adressés par nos outils desktops (et de la même manière ASP.NET Core + Angular ça va rester quelque temps chez nous, car ça corresponds bien à nos besoins actuels et ne nous bloque plus dans nos développements).
On risque un jour de faire le pont entre les deux par contre. Ça fait parti des trucs sympa qu'on imagine.

[Orhin]

Et sera abandonnée plus vite, forçant tout le monde à migrer ou à se taper des bugs et des exploits pendant des années.

En quoi serait elle abandonnée plus vite ?
On ne parle pas de sauter sur la dernière techno à la mode mais de faire des choix pragmatiques.
Tous ceux cités par Dross le sont.