Discussion :

[Mickael_Istria]

J'imagine que le but d'Atom IDE c'est centraliser les developpements et de diriger les contributions sur les plugins standards.

Ouais, comme toutes les plateformes modulaires l'esperent et l'ont espere avant: le kernel Linux aimerait que tous les devs travaillent sur des choses standards, Eclipse IDE aimerait que les contributeurs de plugins contribuent directement leurs fonctionnalites dans l'IDE, VSCode aussi, Maven aussi, bref toutes les *plateformes* vivent comme ca... Sauf que la realite, c'est qu'a un moment, il est plus simple et plus rentable dans pas mal de cas de faire son plug-in dans son coin que de la contribuer; et en fait, c'est meme necessaire a la creation d'un ecosysteme robuste autour de la plateforme/de l'outil.
Je pense qu'Atom le savent bien, et je vois pas comment ils pourraient changer la donne. Soit leur IDE n'est pas extensible et il n'aura pas d'ecosysteme et mourra par manque de dynamisme, ou alors il sera extensible, devient une plateforme et affrontera les memes problemes que tous les autres avant lui. Sauf que les autressont deja en place et ont les reins tres solides en termes de contributions, donc ca va etre dur de se faire sa place.
Ce qui me rend sceptique, c'est en fait que quand on voit la presentation, cet editeur/IDE-ish ne semble avoir aucune valeure ajoutee ni aucun facteur cle de succes par rapport a ce qui se fait deja. Ou alors, j'ai loupe quelquechose? Je prends le pari du petard mouille: dans 6 mois il sera sorti des memoires et GitHub/Facebook se rabatteront sur les IDEs existants.

[martopioche]

Comme l'a dit @Mickael_Istria, ce sont les features de departs qui font la difference. En terme d'utilisation tu peux avoir une certaine difference car un plugin integrer peut plus reactif ou non que un plugin qui est limite par les API offerts.
VSCode etaient aussi fait au depart pour remplacer Visual Studio sur mac et Linux. Mais au final, ils ont mis Visual Studio pour mac. C'est ce qui rend Visual Studio un IDE pour C# quand le VScode est limite par la communaute.

Essaie de faire du Java sur VIM ou du C# sur VIM. Personnellement, j'ai pas envie de compiler l'ancienne et me faire chier a manipuler MSbuild (putain en plus, je l'ai deja fait manuellement et j'etais content d'utiliser Visual Studio). Et peronnellement, je vois plus VScode oriente languages inteprete comme PHP, NodeJS, Typescript, Ruby et Python. Quand les premieres versions sont sortis, j'ai ecrit une code C# et sur mac, il marchait bien mais plus jamais. C'est pas oriente du tout pour C#. Mais tu peux le faire.

C'est là où on est en désaccord avec le concept. Si tu te base sur les "features au départ", on peut aussi dire que ni Eclipse ni NetBeans ne sont des IDEs, ce sont des RCPs…
En soi, à relire la présentation d'Atom-IDE, ils ne présentent pas le résultat comme un "IDE" mais Atom-IDE est l'ensemble de packages qui permet d'utiliser Atom avec des fonctionnalités d'IDE. Donc on peut pinailler est-ce que c'est un IDE ou non mais moi, en tant qu'utilisateur, j'ai besoin d'outils qui font quelque chose, pas de savoir si le branding l'a mis en "IDE" ou non.

Et l'exemple Java/Vim… La compilation, quel mauvais exemple… Depuis plus de 15 ans déjà, on a des outils comme Ant puis Maven et Gradle. Le build se fait via ces outils, en soi, l'IDE ne sert à rien. Pire, si NetBeans et IntelliJ ont intégré correctement Maven assez rapidement, il y a 5 ans, c'était encore horrible à utiliser Maven dans Eclipse. Et dans tous les cas, quand tu développe autrement qu'en mode drone, tu paramètre les lancements, la CLI te sera plus efficace que le clickodrome d'un IDE.

[Mickael_Istria]

la CLI te sera plus efficace que le clickodrome d'un IDE.

Je prends le pari pour un projet Java. Donne un sujet de projet Java/Maven avec un resultat final a atteindre, on prepare chacun notre environnement (toi CLI, moi Eclipse IDE), et on voit qui finit en premier Le gros point manquant de la CLI -meme avec un editeur riche comme VIM+Language Server-, ca va etre la navigation et la non-reactivite: comment tu navigues d'une erreur de compil a une ligne de code, comment tu vas voir qu'une modif dans un fichier repare bien une erreur de compil d'un autre fichier, comment tu vas debugger...
Les IDEs sont des clickodromes, ils consomment beaucoup de jus, et quand on est dedans, on a l'impression de perdre pas mal de temps pour des trucs specifiques a l'IDE, mais quand il te propose une completion de qualite immediate, c'est 1seconde que ca te coute contre un 15aine sans, quand tu as ton erreur de compil des que tu tapes un bout de code sans relancer un build, ca te prend 5 secondes a la reperer et 10 secondes a la corriger contre tempsDeBuildMaven + 15 seconds a trouver l'erreur dans le log + 5 secondes pour revenir au bon endroit dans l'editeur + 10 secondes a la corriger + tempsDeBuildMaven a verifier qu'elle est fixee. Donc rien qu'a chaque erreur de compil, un IDE peut te faire gagner facile 30secondes. L'amortissement est extremement rapide! Meme si tu passes une heure par jour a faire marcher ton IDE, tu amortis ton heure en 120 erreurs de compil dans la journee. C'est vite fait 120 erreurs de compil, il peut suffire d'une typo...

[martopioche]

Je prends le pari pour un projet Java.

Quel pari des plus stupides…*Si j'ai la liberté, les conditions seront telles que la configuration sera nécessaire au premier run rendant la config intra-IDE la plus complexe possible (tiens, une configuration de la JVM au passage…).

Pour le reste, merci de l'explication, en 20 de pratiques, j'avais jamais remarqué ce qui était plus ou moins efficace, heureusement qu'il y a des experts sur Doctissimo…

[Mickael_Istria]

Pour le reste, merci de l'explication, en 20 de pratiques, j'avais jamais remarqué ce qui était plus ou moins efficace, heureusement qu'il y a des experts sur Doctissimo…

J'ai vu des gens utiliser un Eclipse pour Java depuis 15 ans et pas qu'on pouvait pas mettre une condition sur un breakpoint. L'experience ne fait pas necessairement l'expertise... D'ailleurs, elle cause aussi un risque d' "oeilleres": les habitudes et les workflows qu'on developpe s'ancrent tellement qu'ils dissuadent parfois d'en essayer/appredre d'autres plus modernes qui pourraient etre plus profitables.
Et du coup, je suis curieux: tu as un exemple de projet ou de pratique qui est supporte dans un IDE de qualite, avec toutes les features attendues d'un IDE, mais qui est plus efficace a developper en CLI? Je pense sincerement que si ca existe, c'est plutot lie a des limitations de l'IDE qu'a la superiorite intrinseque d'un workflow CLI.
On en revient toujours a l'idee que le workflow est tres personnel, et qu'on n'a pas de mesure objective de la productivite avec tel ou tel outil, parce qu'elle est extremement correlee a l'expertise de l'utilisateur sur cet outil. Tant qu'on n'a pas de telle mesure, on ne pourra rien conclure. Mais quand meme, donne moi un exemple et vraiment on essaye de mesurer!

[Invité]

Ben qu'un éditeur n'est qu'un composant d'un environnement de développement…

N'importe quoi. Faut arrêter de sous-entendre que les IDE sont supérieurs aux éditeurs de texte; ce sont juste des outils différents. En terme d'édition de texte la plupart des IDE sont juste tétraplégiques comparés à vim ou à emacs mais pour la complétion et le debugging les IDE sont plus efficaces.

[Mickael_Istria]

La phrase de martopioche est tout a fait vraie et n'implique rien la superiorite d'un IDE pour la simple edition de texte sans assistance.
Personne n'a dit qu'Eclipse est superieur a Vim pour editer le texte. Et d'ailleurs, il y a meme des plugins Eclipse pour que l'editeur se comporte + comme Vim par exemple.
Par contre, je suis pret a parier que pour arriver au meme resultat en *programmation*, incluant bootstrapping du projet, edition du code, debug, deploiement/livraison, un developpeur qui utilise bien un IDE qui couvre les briques technologiques uyilisees ira toujoura plus vite qu'un dev qui fait que du Vim+CLI.

[martopioche]

J'ai vu des gens utiliser un Eclipse pour Java depuis 15 ans et pas qu'on pouvait pas mettre une condition sur un breakpoint. L'experience ne fait pas necessairement l'expertise...

Et évidemment, cette observation permet sur une anecdote de généraliser à une population…

Je dirai tout de même, en 2017, s'intéresser à ce que fait un breakpoint…

D'ailleurs, elle cause aussi un risque d' "oeilleres": les habitudes et les workflows qu'on developpe s'ancrent tellement qu'ils dissuadent parfois d'en essayer/appredre d'autres plus modernes qui pourraient etre plus profitables.

Et cette remarque, si elle est juste, est à sens unique je présume…

Et du coup, je suis curieux: tu as un exemple de projet ou de pratique qui est supporte dans un IDE de qualite, avec toutes les features attendues d'un IDE, mais qui est plus efficace a developper en CLI? Je pense sincerement que si ca existe, c'est plutot lie a des limitations de l'IDE qu'a la superiorite intrinseque d'un workflow CLI.

J'en sais rien, il faut demander à ceux qui estiment que le développement d'un projet est plus efficace à la CLI qu'avec un IDE.

On en revient toujours a l'idee que le workflow est tres personnel, et qu'on n'a pas de mesure objective de la productivite avec tel ou tel outil, parce qu'elle est extremement correlee a l'expertise de l'utilisateur sur cet outil. Tant qu'on n'a pas de telle mesure, on ne pourra rien conclure. Mais quand meme, donne moi un exemple et vraiment on essaye de mesurer!

Mais bien évidemment qu'il est personnel… Et ça n'en fait pas qu'une mesure "objective" ne peut être faite. Reste quelle mesure on souhaite faire. Plus haut, tu me propose de te donner un cas et tu prépare ton IDE…*C'est sûr que si ta métrique est à partir d'un environnement préparé pour une mesure, tu peux certainement mettre en avant un clickodrome pour tous les cas. Mais dans ce cas, on va considérer que pour un employeur, le temps passé à autre chose que produire du code (configurer un IDE…) n'est pas à compter dans les heures travaillées. Tu est prêt à travailler dans ces conditions ?

Un IDE est parmi d'autres un outil destiné à mener à bien un projet et doit être choisi en fonction des besoins et contraintes de ce projet et non en fonction d'une prétendue performance. Oh, ta remarque sur l'expertise est très bonne. Si il faut avoir une expertise avancée pour faire une tâche de base avec un outil, évidemment qu'elle doit être comptée.

N'importe quoi. Faut arrêter de sous-entendre que les IDE sont supérieurs aux éditeurs de texte; ce sont juste des outils différents. En terme d'édition de texte la plupart des IDE sont juste tétraplégiques comparés à vim ou à emacs mais pour la complétion et le debugging les IDE sont plus efficaces.

Non mais si vous avez des complexes, allez consulter sur le sujet psy ! Où dans "Est un composant de…" y-a-t-il une notion de "supériorité" ?

[vin120cent]

Je comprend très bien pourquoi une véritable IDE consomme autant de RAM : il analyse votre code, ainsi que toutes les dépendances pour vous signaler un maximum de bug et pour vous proposer les bonnes commandes à taper au bon moment.
En temps qu'enseignant, et en temps que codeur, j'apprécie cela énormément. C'est beaucoup de temps gagné pour se concentrer sur le fond des algos. Alors qu'importe les économies de RAM !

[Mickael_Istria]

Mais dans ce cas, on va considérer que pour un employeur, le temps passé à autre chose que produire du code (configurer un IDE…) n'est pas à compter dans les heures travaillées. Tu est prêt à travailler dans ces conditions ?

De la meme maniere, la configuration de ta CLI, l'installation de Git, Java , les alias, les couleurs de shell et tout ca aussi doivent compter dans le temps de projet, donc l'installation de l'OS aussi.
Le temps de configuration de l'environnement, incluant l'IDE ou non, n'est cense compter qu'un fois sur le cycle de vie du projet (voire meme sur le cycle de vie du developpeur); donc quand tu mesures la productivite sur un projet reel (plusieurs mois), ca s'amortit et devient negligeable par rapport au temps de dev.

Oh, ta remarque sur l'expertise est très bonne. Si il faut avoir une expertise avancée pour faire une tâche de base avec un outil, évidemment qu'elle doit être comptée.

L'expertise en CLI est a mon avis tout a fait comparable en terme d'effort a acquerir qu'une expertise en IDE. Je ne pense pas qu'on puisse en faire un differentiateur entre le choix d'une stack dev plutot CLI ou plutot IDE.

[martopioche]

De la meme maniere, la configuration de ta CLI, l'installation de Git, Java , les alias, les couleurs de shell et tout ca aussi doivent compter dans le temps de projet, donc l'installation de l'OS aussi.
Le temps de configuration de l'environnement, incluant l'IDE ou non, n'est cense compter qu'un fois sur le cycle de vie du projet (voire meme sur le cycle de vie du developpeur); donc quand tu mesures la productivite sur un projet reel (plusieurs mois), ca s'amortit et devient negligeable par rapport au temps de dev.

L'expertise en CLI est a mon avis tout a fait comparable en terme d'effort a acquerir qu'une expertise en IDE. Je ne pense pas qu'on puisse en faire un differentiateur entre le choix d'une stack dev plutot CLI ou plutot IDE.

Non mais très honnêtement, je pense qu'avant de répondre à des intervention le minimum est de les lire… Je comprends que lorsqu'on vend un produit, l'objectif est d'imposer une rigidité "stack plutôt IDE" et de déformer l'intervention de l'interlocuteur et de balayer toute notion qui sortirait de ce cadre. Idem pour la notion de "expertise CLI"…*Enfin, si on il est nécessaire de parler "d'expertise CLI" pour une connaissance des instructions "cd path/to/project" et "maven clean install", j'imagine à qui tu t'adresse…