Pour certains, vim n'en est pas uns, pour d'autres si. C'est le premier truc qui viens à l'esprit.
Si on prend l'acronyme et qu'on le déplie, ça donne Integrated Development Environment, ce qui signifie que tout dois déjà être intégré. Donc, si on prend vim, de base, non, ce n'est pas un IDE.
Sauf que ce n'est pas si simple, puisque les IDE actuels se basent très souvent sur des mécanismes de plug-in, poussant la technique au maximum. Donc, si on les prends "de base" aussi, sans leurs plug-in, ils ne sont pas non plus des IDE…
Bon, évidemment, vim viens sans une palanquée de ces ajouts, contrairement aux logiciels qui se réclament IDE. Pour moi, c'est ça le point à retenir pour distinguer un IDE d'un autre logiciel: le fait que tout soit intégré par l'installateur officiel (donc, pour moi, vim n'est pas un IDE).
Pour revenir à la question posée par le titre de l'article: non, un IDE n'est pas indispensable.
Si on mets ensemble nos outils, qu'on les configure pour qu'ils interagissent aisément, on obtiens un environnement tout à fait utilisable, et aussi efficace, voire plus, qu'un IDE ou l'intégration est faite par d'autres.
Pour autant, ce n'est pas un IDE puisque tout n'es pas intégré à l'origine.
Ceux qui n'utilisent pas (quand on a le choix j'entends) d'IDE pour coder ne se passent pas pour autant de manipuler plusieurs fichiers en même temps, ni de débogueur, et encore moins de système de build ou de contrôle de version!
On passe plus de temps au début à prendre en main chacun de nos outils séparément, là où un utilisateur d'EDI va pouvoir coder en moins de 5 minutes, donc de ce point de vue, c'est moins efficace.
Par contre, ce que j'ai constaté c'est un coût largement réduit au niveau des ressources à l'utilisation, et les logiciels séparés que l'on utilise ont tendance à être plus mûrs et moins exposés au bugs, ce qui fait qu'a l'utilisation on finit par être plus efficace avec nos solutions maison qu'avec un outil dédié à toutes ces tâches.
Je viens du monde windows, voire DOS: les 1ers EDI que j'ai utilisés ont été QBasic et TurboC, puis j'ai testé devcpp ou un truc du genre, qui était graphique mais bien plus pénible que turboC pour gérer un projet.
En BTS j'ai utilisé Visual Studio et KDevelop, puis j'ai découvert Code::Blocks et QtCreator, et récemment j'ai été contraint (y'a pas d'autres mots) à utiliser eclipse en reprenant des études. Celui-ci m'a tellement gonflé (lourd, lent, instable sur la machine que j'avais, pourtant pas une bas de gamme niveau proc et 4 bon Go de ram…) que j'ai cherché une alternative, trouvée avec l'outil netbeans.
Parallèlement, j'ai commencé à utiliser vim pour l'administration de ma Debian, et au fur et à mesure je me suis retrouvé à ne plus utiliser que vim.
Pourtant, vim à de sacrés soucis par rapport à un véritable IDE:
auto-complétion de merde (il faut dire ce qui est) qui ralentit quand on programme (mais qui au moins ne se lance pas intempestivement, contrairement aux IDE que j'ai essayés)
interaction avec les autres logiciels optionnelle (je pense surtout au copier/coller qui est une plaie, surtout avec les options de smart-indent activées)
complexité du bouzin (3 tonnes de raccourcis clavier pas si simples que ça a changer, quoiqu'en diront les experts, par exemple)
des ralentissements/blocages quand je code (le logiciel se bloque pendant une demi seconde on sais pas trop pourquoi. Problème qui n'apparaît pas sur la même machine avec un IDE plus lourd.)
fonctionnalités qui semblent absentes par rapport aux outils basés sur Scintilla (je pense précisément à l'édition multiple, mais je rappelle que j'ai employé le mot "semblent". En plus cette édition multiple de scintilla est quand même limitée: le moindre retour chariot par exemple et il n'y a plus rien…)
remplacement de chaînes de caractères extrêmement pénible (devoir échapper les caractères spéciaux parce que c'est regex par défaut, c'est lourd)
bref, toujours pas la panacée, mais vu qu'il s'agit avant tout d'un éditeur de texte, il offre des fonctionnalités et une simplicité d'usage (paradoxalement) que je n'ai jamais pu atteindre avec les EDI, surtout au niveau de la vitesse de déplacement dans le code source.
Combiné à CMake pour la gestion de projet, qui, contrairement aux IDE que j'ai testés, permets d'utiliser les masques de fichiers et évite donc d'avoir à modifier le projet dès qu'on crée un fichier, on arrive vraiment à une simplicité et un confort que je n'ai jamais atteins avec un outil intégré.
Pour en revenir à vim, un certain nombre des défauts cités dans les commentaires précédents, et que je confirme (auto-complétion) ne sont pas si gênants que ça, ou plutôt ne le sont plus pour moi, parce qu'en m'apercevant de ce défaut, ma façon de programmer s'est adaptée plus ou moins naturellement, par exemple mes classes sont devenues beaucoup moins entremêlées (vu que c'est moins simple de compléter un nom d'un autre fichier, évitons de créer des dépendances si on peut s'en passer), les noms des méthodes plus explicites, des méthodes mieux documentées…
Bref, j'ai retrouvé une grande part de mon confort en améliorant ma façon de faire les choses (je ne dis pas que c'est valable pour tout le monde hein, mais je codais vraiment comme un porc avant) et je fais les choses de façon plus atomiques. Enfin, ça, c'est peut-être dû aussi à git :)
J'ai compensé le manque de débogueur intégré (de toute façon, les débogueurs en IHM sous linux sont à des années lumières de ceux dispo sous windows niveau confort d'utilisation. En tout cas, je n'ai jamais vu quoique ce soit qui approche ollydbg… ) par le fait de toujours vérifier les valeurs de retour des fonctions que j'appelle si elles héritent de la méthode C, et dans mon propre code, je lance une exception si les pré-conditions ne sont pas respectée, avec un message d'erreur unique qui décrit la violation en question, de sorte que si un problème arrive, je sais de quoi il s'agit… sauf en cas de sigsegv.
Pour les outils de refactoring, je suis resté au bête chercher/remplacer, mais vu que je m'arrange pour ne pas emmêler mes dépendances (sur les bons conseils de cccc) il n'y a pas besoin de fouiller dans 3000 fichiers.
Après, pour l'auto-complétion… sincèrement, je n'ai pas encore vu le moindre outil qui soit capable de gérer l'auto-complétion du C++ correctement, alors je préfère ne pas trop m'y fier. Une bonne vieille documentation de référence sur une fenêtre est tout aussi bien. Et pour l'aspect de panneaux si cher aux IDE, bah j'utilise un tiling window manager, donc je l'ai de toute façon.
# Il faut commencer par définir ce qu'est un IDE...
Posté par freem . En réponse au journal Point de vue : un IDE est il un outil de programmation indispensable ?. Évalué à 5.
Pour certains, vim n'en est pas uns, pour d'autres si. C'est le premier truc qui viens à l'esprit.
Si on prend l'acronyme et qu'on le déplie, ça donne Integrated Development Environment, ce qui signifie que tout dois déjà être intégré. Donc, si on prend vim, de base, non, ce n'est pas un IDE.
Sauf que ce n'est pas si simple, puisque les IDE actuels se basent très souvent sur des mécanismes de plug-in, poussant la technique au maximum. Donc, si on les prends "de base" aussi, sans leurs plug-in, ils ne sont pas non plus des IDE…
Bon, évidemment, vim viens sans une palanquée de ces ajouts, contrairement aux logiciels qui se réclament IDE. Pour moi, c'est ça le point à retenir pour distinguer un IDE d'un autre logiciel: le fait que tout soit intégré par l'installateur officiel (donc, pour moi, vim n'est pas un IDE).
Pour revenir à la question posée par le titre de l'article: non, un IDE n'est pas indispensable.
Si on mets ensemble nos outils, qu'on les configure pour qu'ils interagissent aisément, on obtiens un environnement tout à fait utilisable, et aussi efficace, voire plus, qu'un IDE ou l'intégration est faite par d'autres.
Pour autant, ce n'est pas un IDE puisque tout n'es pas intégré à l'origine.
Ceux qui n'utilisent pas (quand on a le choix j'entends) d'IDE pour coder ne se passent pas pour autant de manipuler plusieurs fichiers en même temps, ni de débogueur, et encore moins de système de build ou de contrôle de version!
On passe plus de temps au début à prendre en main chacun de nos outils séparément, là où un utilisateur d'EDI va pouvoir coder en moins de 5 minutes, donc de ce point de vue, c'est moins efficace.
Par contre, ce que j'ai constaté c'est un coût largement réduit au niveau des ressources à l'utilisation, et les logiciels séparés que l'on utilise ont tendance à être plus mûrs et moins exposés au bugs, ce qui fait qu'a l'utilisation on finit par être plus efficace avec nos solutions maison qu'avec un outil dédié à toutes ces tâches.
Je viens du monde windows, voire DOS: les 1ers EDI que j'ai utilisés ont été QBasic et TurboC, puis j'ai testé devcpp ou un truc du genre, qui était graphique mais bien plus pénible que turboC pour gérer un projet.
En BTS j'ai utilisé Visual Studio et KDevelop, puis j'ai découvert Code::Blocks et QtCreator, et récemment j'ai été contraint (y'a pas d'autres mots) à utiliser eclipse en reprenant des études. Celui-ci m'a tellement gonflé (lourd, lent, instable sur la machine que j'avais, pourtant pas une bas de gamme niveau proc et 4 bon Go de ram…) que j'ai cherché une alternative, trouvée avec l'outil netbeans.
Parallèlement, j'ai commencé à utiliser vim pour l'administration de ma Debian, et au fur et à mesure je me suis retrouvé à ne plus utiliser que vim.
Pourtant, vim à de sacrés soucis par rapport à un véritable IDE:
bref, toujours pas la panacée, mais vu qu'il s'agit avant tout d'un éditeur de texte, il offre des fonctionnalités et une simplicité d'usage (paradoxalement) que je n'ai jamais pu atteindre avec les EDI, surtout au niveau de la vitesse de déplacement dans le code source.
Combiné à CMake pour la gestion de projet, qui, contrairement aux IDE que j'ai testés, permets d'utiliser les masques de fichiers et évite donc d'avoir à modifier le projet dès qu'on crée un fichier, on arrive vraiment à une simplicité et un confort que je n'ai jamais atteins avec un outil intégré.
Pour en revenir à vim, un certain nombre des défauts cités dans les commentaires précédents, et que je confirme (auto-complétion) ne sont pas si gênants que ça, ou plutôt ne le sont plus pour moi, parce qu'en m'apercevant de ce défaut, ma façon de programmer s'est adaptée plus ou moins naturellement, par exemple mes classes sont devenues beaucoup moins entremêlées (vu que c'est moins simple de compléter un nom d'un autre fichier, évitons de créer des dépendances si on peut s'en passer), les noms des méthodes plus explicites, des méthodes mieux documentées…
Bref, j'ai retrouvé une grande part de mon confort en améliorant ma façon de faire les choses (je ne dis pas que c'est valable pour tout le monde hein, mais je codais vraiment comme un porc avant) et je fais les choses de façon plus atomiques. Enfin, ça, c'est peut-être dû aussi à git :)
J'ai compensé le manque de débogueur intégré (de toute façon, les débogueurs en IHM sous linux sont à des années lumières de ceux dispo sous windows niveau confort d'utilisation. En tout cas, je n'ai jamais vu quoique ce soit qui approche ollydbg… ) par le fait de toujours vérifier les valeurs de retour des fonctions que j'appelle si elles héritent de la méthode C, et dans mon propre code, je lance une exception si les pré-conditions ne sont pas respectée, avec un message d'erreur unique qui décrit la violation en question, de sorte que si un problème arrive, je sais de quoi il s'agit… sauf en cas de sigsegv.
Pour les outils de refactoring, je suis resté au bête chercher/remplacer, mais vu que je m'arrange pour ne pas emmêler mes dépendances (sur les bons conseils de cccc) il n'y a pas besoin de fouiller dans 3000 fichiers.
Après, pour l'auto-complétion… sincèrement, je n'ai pas encore vu le moindre outil qui soit capable de gérer l'auto-complétion du C++ correctement, alors je préfère ne pas trop m'y fier. Une bonne vieille documentation de référence sur une fenêtre est tout aussi bien. Et pour l'aspect de panneaux si cher aux IDE, bah j'utilise un tiling window manager, donc je l'ai de toute façon.