Tu apprends eclipse, tu apprends le système de build eclipse, l’éditeur eclipse, le SCM eclipse, le debuggueur eclipse.
vim, tu apprends gdb (ou tout autre debuggueur), make (ou tout autre système de build), git (ou tout autre SCM), l’éditeur de texte vim.
Déjà, il faut savoir ce qu’on compare : la full-stack ? éditeur-vim vs éditeur-eclipse ? éditeur-vim vs ide-eclipse ? Et quelle que soit la comparaison, est-elle pertinente ?
De plus, cette séparation des outils permet tout de même une bien meilleure compréhension globable du workflow, indispensable pour travailler en équipe AMHA. Quand un de mes projets C++ (sans IDE) ne builde pas sur la machine d’un de mes collègues, je sais immédiatement où se situe le problème. Par contre un projet eclipse, com.truc.bidule.machin.chose.PackageAuNomImbitable not found, ça peut venir :
D’une mauvaise configuration du projet de ma part
D’une mauvaise configuration de l’IDE
D’une mauvaise configuration/installation de Java
La différence entre IDE et non-IDE à ce niveau est simple : l’IDE mélange allègrement (que ce soit dans l’arborescence du système de fichiers ou dans l’interface graphique de configuration) « configuration de l’environnement de dev personnel » (préférences de l’IDE, configuration globale Java), « configuration personnelle du projet » (typiquement : configuration du SCM, mais pas que…), et « configuration du projet » (paramètres build debug/release, classpath…) et qu’il est extrèmement simple, en équipe, de se foirer à ce niveau (commiter un paramètre personnel vers tout le monde, ou au contraire avoir une configuration du projet qui ne marche que chez soi…)
[^] # Re: Non, mais ...
Posté par Moonz . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 3.
Ce n’est absodument pas comparable.
Tu apprends eclipse, tu apprends le système de build eclipse, l’éditeur eclipse, le SCM eclipse, le debuggueur eclipse.
vim, tu apprends gdb (ou tout autre debuggueur), make (ou tout autre système de build), git (ou tout autre SCM), l’éditeur de texte vim.
Déjà, il faut savoir ce qu’on compare : la full-stack ? éditeur-vim vs éditeur-eclipse ? éditeur-vim vs ide-eclipse ? Et quelle que soit la comparaison, est-elle pertinente ?
De plus, cette séparation des outils permet tout de même une bien meilleure compréhension globable du workflow, indispensable pour travailler en équipe AMHA. Quand un de mes projets C++ (sans IDE) ne builde pas sur la machine d’un de mes collègues, je sais immédiatement où se situe le problème. Par contre un projet eclipse,
com.truc.bidule.machin.chose.PackageAuNomImbitable not found, ça peut venir :La différence entre IDE et non-IDE à ce niveau est simple : l’IDE mélange allègrement (que ce soit dans l’arborescence du système de fichiers ou dans l’interface graphique de configuration) « configuration de l’environnement de dev personnel » (préférences de l’IDE, configuration globale Java), « configuration personnelle du projet » (typiquement : configuration du SCM, mais pas que…), et « configuration du projet » (paramètres build debug/release, classpath…) et qu’il est extrèmement simple, en équipe, de se foirer à ce niveau (commiter un paramètre personnel vers tout le monde, ou au contraire avoir une configuration du projet qui ne marche que chez soi…)