Voici pourquoi certains développeurs utilisent toujours Vim

Nicolas Furno |

Pourquoi est-ce que certains développeurs utilisent vi, cet éditeur de code qui date des années 1970 ? Souvent, ils utilisent plutôt Vim, une version améliorée des années 1990, mais cela reste ancien à l’échelle de l’informatique. De fait, c’est l’un des plus vieux outils destinés aux développeurs et même s’il existe aujourd'hui des dizaines et des dizaines d’éditeurs de code plus récents, plus modernes et plus complets. Ces développeurs restent pourtant toujours avec cette interface austère et uniquement textuelle.

Vim dans toute sa splendeur, avec ce même article en cours de rédaction. Cliquer pour agrandir
Vim dans toute sa splendeur, avec ce même article en cours de rédaction. Cliquer pour agrandir

Certains, parce qu’ils n’arrivent pas à sortir de Vim comme le veut la blague très répandue dans le milieu*. D’autres, parce que malgré son grand âge, ou plutôt grâce à son grand âge, Vim conserve quelques solides arguments à faire valoir. L’un de ces développeurs a publié récemment un article où il expose ses arguments que l’on pourrait qualifier sans appel.

Déjà, Vim est partout et notamment sur tous les serveurs. N’importe quelle distribution GNU/Linux est fournie avec ce vétéran et un développeur web retrouvera ses marques partout. Mais surtout, Vim est léger, étant dépourvu de toute interface et surtout ayant été créé à une époque où il n’y avait pas le choix, il fallait optimiser au maximum n’importe quelle application.

Léger, à quel point ? Ces tests de performance démontrent bien l’écart énorme entre Vim et les nouveaux acteurs du secteur, Atom de GitHub et Visual Studio Code de Microsoft. Précisons que ces deux logiciels sont multiplateformes et ils n’exploitent pas du code natif, mais des technologies du web. Ce qui a un impact significatif sur les performances, comme vous pourrez le constater vous-même…

Premier test : combien de mémoire vive consomme chaque éditeur de code pour ouvrir un fichier de 60 octets ? 349 Mo et 256 Mo pour Code et Atom, contre 5 Mo pour Vim. Cliquer pour agrandir
Premier test : combien de mémoire vive consomme chaque éditeur de code pour ouvrir un fichier de 60 octets ? 349 Mo et 256 Mo pour Code et Atom, contre 5 Mo pour Vim. Cliquer pour agrandir
Deuxième test, cette fois pour ouvrir un fichier de 6 Mo. Vim se contente de 12 Mo environ, quand Atom consomme à lui seul 845 Mo de mémoire vive rien que pour ouvrir ce fichier. Cliquer pour agrandir
Deuxième test, cette fois pour ouvrir un fichier de 6 Mo. Vim se contente de 12 Mo environ, quand Atom consomme à lui seul 845 Mo de mémoire vive rien que pour ouvrir ce fichier. Cliquer pour agrandir

Dans ses tests, notre développeur a aussi intégré Nano, un autre éditeur uniquement textuel plus récent, et Sublime Text, un éditeur plus moderne, mais développé avec du code natif. Vim n’est pas toujours en tête, par exemple il prend quatre fois plus de temps à ouvrir ce même fichier de 6 Mo. Néanmoins, il n’a besoin que de quatre secondes, quand Visual Studio Code fait attendre son utilisateur pendant vingt secondes.

Troisième test : combien de temps faut-il attendre pour pouvoir éditer ce fichier de 6 Mo ? Deux clans se distinguent à nouveau très bien. Cliquer pour agrandir
Troisième test : combien de temps faut-il attendre pour pouvoir éditer ce fichier de 6 Mo ? Deux clans se distinguent à nouveau très bien. Cliquer pour agrandir
Dernier test, une opération pour rechercher/remplacer 100 000 occurrences d’un même mot dans un fichier. Vim n’a besoin que de quatre secondes, là où Atom a nécessité environ 800 secondes. Oui, deux cents fois plus. Cliquer pour agrandir
Dernier test, une opération pour rechercher/remplacer 100 000 occurrences d’un même mot dans un fichier. Vim n’a besoin que de quatre secondes, là où Atom a nécessité environ 800 secondes. Oui, deux cents fois plus. Cliquer pour agrandir

Conclusion sans appel de ce développeur : apprenez Vim (ou si vous y tenez vraiment, Emacs, un concurrent qui date aussi des années 1970), ce sera forcément positif. Il est vrai que cet outil nécessite un apprentissage tant il est éloigné de nos habitudes modernes. Pour les personnes intéressées, il recommande cet ouvrage consacré entièrement à Vim.

* Si jamais vous êtes présentement coincé dans Vim, rappelons le raccourci pour quitter l’éditeur de code : :q. De rien.

avatar eugenemr | 

J'imagine que vim joue toujours dans la cour des grands dès qu'il s'agit de jouer du remote ssh ou de regexp dans le code...

Mais ça c'est pas tous les jours ?

avatar Shew | 

Vous connaissez un moyen d'utiliser matlab sans son interface ? Par exemple, écrire le code dans sublime et l'exécuter avec sublime également c'est possible ? Où le mieux est de l'écrire avec sublime et de le compiler avec matlab ? Je n'en peux plus de la lourdeur de l'interface de matlab et je dois l'utiliser toute la journée...

Merci !

avatar Bilbo | 

Je ne résiste pas :
https://fr.wikipedia.org/wiki/Guerre_d%27%C3%A9diteurs

Longtemps grand fan d'Emacs, je n'utilise plus que Vim. Il faut dire que je ne code plus beaucoup et que piloter un serveur "out of the box" plutôt que d'installer Emacs est un vrai argument pour moi.

À+

avatar Phiphi | 

J'installais "less" pour remplacer à la fois "more" et "vi" mais quand je me retrouve sur une console je suis bien comptant de trouver encore "vi".
Au fait pour "q!" On prononçait "q bang".

avatar sailor29 | 

J'utilise Nano sur les serveurs que je trouve plus sympa que Vim et plus simple surtout (cmd+x pour sortir) mais pour developper sur mon mac je suis passé par coda puis sublime et maintenant Atom.

J'adore Atom, la personnalisation est hors norme (beaucoup plus de possibilité que sublime que j'utilise uniquement pour les fichiers lourds type gros csv/xml) mais il faut reconnaitre que la consommation de ram est catastrophique... Au point que j'ai troqué mon macbook air 2011 avec ses 4go pour un macbook pro 2017 8go spécialement pour ça.

Mais bon, y'a aucun équivalent leger. Les mecs qui developpent avec VIM sont sacrement courageux et borné... Et souvent sous linux. J'ai jamais compris ce qu'ils avaient contre les interfaces les mecs qui bossent sous linux.

avatar bunam | 

bon je l'avoue j'utilise cat

créer un fichier

cat > monfichier.txt

on tape ce que l'on veut et on finit par control+c

éditer un fichier

cat monfichier.txt && cat - >> monfichier.txt

on ajoute ce que l'on veut et on finit par control+c

avatar byte_order | 

dans une autre vie j'ai dû configurer une machine Solaris sur laquelle il n'y avait pas de vi (et encore moins vim, même pas encore né à cette époque).

cat + echo >> + sed

ca fait tout drôle, mais on y arrive.

avatar william57m | 

"Utiliser" est un grand mot, si quelqu'un écrit une application Android, iOS ou même un site web ou un serveur avec Vim il est complètement perdu le pauvre... En revanche je suis d'accord sur le fait qu'on utilise encore tous Vim/Nano pour modifier certain fichiers (config nginx, bash_profile, .gitignore et ce genre de fichier)

avatar kiddsoso | 

C’est vrai que c’est plus facile de sortir d’une prison que de Vim ??

Nan plus sérieusement, je trouve qu’il est temps de s’adapter. Pour du web sublime est très bien et a pleins de plugins sympa donc je ne vois pas pourquoi utiliser Vim, emacs ou nano...

De meilleures performances.. On est en 2017 et la puissance n’est pas ce qui manque ...

avatar jerome74 | 

"De meilleures performances.. On est en 2017 et la puissance n’est pas ce qui manque": tout dépend du type de fichiers que tu traites. Pour quelques dizaines ou même centaines de Ko de code, ça va très bien, mais si tu t'en sers pour traiter des fichiers de log de centaines de Mo, Atom et compagnie c'est totalement inenvisageable!

avatar byte_order | 

> De meilleures performances.. On est en 2017 et la puissance n’est pas ce qui manque ...

Ca change rien.

Sur la même machine, même hyper puissante, ce n'est pas sans impact de devoir attendre 200x plus long pour faire une grosse opération de chercher/remplacer (genre refactoring).

La question c'est plus est-ce que cette boulimie de puissance est proportionnelle aux fonctionnalités nettement plus avancées afin de justifier ce besoin de puissance.

Et c'est loin d'être vraiment le cas pour tout un pan de cas d'usages relativement normaux d'un éditeur de texte orienté développement.

Par ailleurs, quand vous bosser en environnement contraint / embarquée, on a plus guère le choix que de devoir composer avec des ressources nettement plus limitées et donc des outils plus économes pour répondre aux mêmes besoins ou presque.

Attention à ne pas confondre confort et productivité. C'est pas toujours lié.

avatar bonnepoire | 

Je programme en python sous vim. C'est mal?

avatar byte_order | 

Très.
Faut arrêter tout de suite !

avatar Alex Giannelli | 

- tu joues à GTA 1 ?
- oui ! C'est bien mieux que GTA V : à l'époque le jeu était bien plus simple, et ça utilisait très peu de RAM comparé à aujourd'hui !

...

Bon allez, je retourne sur Coda 2.

avatar bonnepoire | 

Il y a plein de mères morale ici. il faudrait utiliser un programme plutôt qu'un autre. Au final c'est juste l'égo qui s'exprime.

J'utilise vim tous les jours sur un serveur linux sans interface graphique et je m'en porte bien. Sur Mac j'utilisais coda que j'ai lâché pour atom mais au final, chacun son usage.

avatar olivierfaure | 

TextWrangler est vraiment impressionnant pour sa performance en rechercher / remplacer, j'ai pas trouvé + rapide dans les éditeurs en mode graphique, les autres rament rament surtout si les occurences sont nombreuses genre remplacer TAB par ; dans un fichier CSV.

C'est qu'avant sur OS9, y'avait un équivalent ultra rapide mais je suis plus sûr du nom "qedit" je crois mais suis pas sûr.

avatar docmib | 

Grand utilisateur de Vim surtout sur mes serveurs pour éditer des fichiers de configuration (serveurs Mac et Linux) je ne saurais que le recommander ! Tellement léger et rapide...
Quelques petites habitudes à prendre mais en quelques minutes on saisi l'astuce et c'est parti !

avatar Jean-Jacques Cortes | 

Sur mon pc, j'utilise Notepad++

avatar XiliX | 

@Jean-Jacques Cortes

Idem :D

avatar radar | 

Y a vim et emacs. Deux clans. Je suis du premier et n'ai jamais su utiliser (sortir du) second. C'est deux outils très puissants mais nécessitent d'être maîtrisés.
PS : Il faut dire à celui qui est bloqué de faire "Esc" avant le ":q", sinon, ça ne va pas trop l'aider ;)

avatar CR_B | 

Au final a bien lire les resultat, c'est plutot nano qui est bon :)

avatar Forest218 | 

Emacs ici
Alors oui je suis d'accord on psse du temps pour personnaliser optimiser ces éditeurs (Vi/Vim/Emacs et sublime s'en rapproche beaucoup) mais ce n'est pas nécessairement du temps perdu...
Config de Emacs -> Apprendre un nouveau langage (lisp).
Et je ne suis pas d'accord avec certaine personnes qui prétende qu'avec les machine qu'on a maintenant, ça ne sert à rien d'optimiser autant que possible.
Quand Chrome arrive à prendre 21Go de RAM sur 64, je me dis qu'il y a un raté quand même.
Après en effet, il esst plus "rapide" d'installer un IDE, encore que certain mettent un temps impressionnant pour ouvrir un simple fichier text ou faire des opérations simples, comme le montre les graphiques de cet article.
Je suis pro optimisation, dès que j'ai un peu de temps, j'optimise mon code pour faire moins d'appel system/base entre autres, une base pour un fonctionnement cohérent selon moi.

Pour matlab + sublim, regarde dans les add-on, la liste est assez conséquente, mais il y aura forcément de quoi te combler. Eclipse se remplace complètement avec Sublime + Mavensmate par exemple pour developper sous salesforce je crois (pas certain du nom, c'est un pote qui utilise ça, je suis sous un bon vieux terminal avec emacs )

Ctrl-s + Ctrl-x rpz

avatar toptophe | 

Le principal attrait de VI c'est que "N’importe quelle distribution GNU/Linux est fournie avec ce vétéran" ! Il suffit de se connecter à une machine distante et de lancer VI pour ne pas avoir à se poser la question de savoir quel(s) éditeur(s) est/sont installés. Quand on a besoin de faire deux modifs, VI rempli alors bien sa tâche ! Maintenant, ok, si l'on doit bosser plusieurs heures avec un éditeur, il y a mieux et plus joli.

avatar jerome74 | 

En ce qui me concerne, nano quand je n'ai pas d'interface graphique (via ssh par exemple), infiniment plus simple a utiliser que vim ou emacs; Xcode pour la gestion du projet et l'intégration avec le compilateur, et BBEdit pour tout le reste. Ce dernier est d'une puissance extraordinaire, je l'utilise par exemple pour enchaîner (via AppleScript) une suite de rechercher/remplacer avec des regex très complexes, sur des fichiers de log de plusieurs centaines de MB. J'attend juste une version 64-bit pour le faire sur des fichiers de plusieurs GB!

avatar Sergio_bzh | 

oui, c'est un des arguments principaux en faveur de vi mais l'article n'en parle absolument pas : vi s'exécute dans n'importe quel terminal de n'importe quelle distrib unix. Pas d'interface graphique.
Quand on fait du ssh en permanence , la connaissance de vi est indispensable.

avatar marc_os | 

Ce qui m'étonne, c'est que personne ne parle de LA particularité de vi, les expressions régulières pour la recherche ou le remplacement.
À ma connaissance il n'y a pas des masses d'éditeurs qui les supportent. Un seul nom me vient à l'esprit : Comme per hasard il s'agit de TextWrangler / BBEdit déjà cité.
vi, c'était aussi l'époque de lex et yacc...

avatar françois bayrou | 

Sublime text les supporte ! :)

avatar BeePotato | 

@ marc_os : « Ce qui m'étonne, c'est que personne ne parle de LA particularité de vi, les expressions régulières pour la recherche ou le remplacement.
À ma connaissance il n'y a pas des masses d'éditeurs qui les supportent. Un seul nom me vient à l'esprit : Comme per hasard il s'agit de TextWrangler / BBEdit déjà cité. »

Parmi les éditeurs de texte pour Mac incluant un bon support des expressions régulières, il y a aussi SubEthaEdit.

avatar fte | 

@marc_os

Les JetBrains, Xcode, TextMate, Sublime... après, une bonne fonction de refactoring comme JetBrains est généralement plus efficace, plus sûre, prévisualisable... les regex il faut aimer quand-même, et c’est super vite fait de se foirer.

avatar StephanMart | 

@fte

Je cherche depuis un moment comme on peut avec Textmate ajouter une extension pour qu'il prenne en charge le langage la mise en forme du langage Swift ?

avatar BeePotato | 

@ fte : « une bonne fonction de refactoring comme JetBrains est généralement plus efficace, plus sûre, prévisualisable... »

Tout à fait… quand c'est du code qu'on modifie.
Mais on utilise aussi un éditeur pour d'autres types de données (les tests sur des fichiers de plusieurs Mo, voire Go, ne correspondent pas à du code source). C'est là qu'un support efficace des expressions régulières est utile.

« les regex il faut aimer quand-même, et c’est super vite fait de se foirer. »

C'est pour ça qu'un éditeur avec un bon support des ER fournit de l'aide pour les écrire, ainsi qu'une prévisualisation du résultat.
Sans parler de la fonction d'annulation, une des meilleures inventions de l'histoire de l'informatique.

avatar fte | 

Chacun choisi ses combats, pour ses propres raisons.

Vi peut être très puissant. Une fois configuré. Et aucun autre vi lui ressemblera.

Pour ma part, au fil de la journée, ce qui rythme mon travail et éventuellement me ralenti sont les cycles édition - compilation - exécution.

L’édition en elle-même n’a aucun impact, cette phase est limitée par mon cerveau et non par l’éditeur. Je réfléchis à ce que je code et le plus rapide des éditeurs ne me fera pas réfléchir plus vite. Il ne doit pas être rapide, il doit être moins lent que moi. La navigation dans le code, les outils de refactoring, l’integration des compilateurs et simulateurs / VM / debuggers sont beaucoup plus importants pour ma productivité.

La compilation ma foi depend de pas mal de choses, du système de build et compilateur au SSD en passant par le CPU voire le réseau. Le SSD a changé ma vie. Point besoin d’un SSD ultra-rapide, le gain n’est pas réalisé sur les transferts mais sur le nombre d’opérations sur petits fichiers, et n’importe quel SSD même médiocre met une raclée épique au plus rapide des disques dur. 4 cores 8 threads c’est bien, 6 cores 12 threads serait idéal. Il n’y a pas que la compilation dans la vie, sinon j’aurais un Threadripper en commande déjà.

Quant à l’exécution, c’est beaucoup une question d’intégration dans le flux de travail. L’IDE peut grandement aider, des bons gestes plus encore, et du tooling soigneusement configuré... et de la mémoire, beaucoup de mémoire, pour jamais n’avoir à relancer ou charger l’outillage.

Après, chacun mesure les choses selon son envie. Pour ma part je recherche des cycles courts et efficaces en premier lieu, plus de cycles dans une journée résulte en plus de lignes de code éditées et exécutées. C’est mécanique.

avatar Stardustxxx | 

@fte
Tout a fait, ce n'est pas l'éditeur qui pense le code, il est juste la pour l'écrire. C'est donc une question de préférence, de workflow, ...
Chaque développeur a ses habitudes (bonnes et mauvaises), sa façon de penser, et donc utilisera des outils différents.

avatar marc_os | 

J'adore celle-là :
Using vi is like seeing the matrix, not everyone can do it, but those of us who can feel like we know kung foo!

avatar XiliX | 

La vache 3 pages de commentaire pour vi/vim...

Il y en des veterans ici :D

avatar flapy | 

VIM est indispensable dès qu'on rentre dans des scripts système sous Linux ou même sous Mac. Par contre, il est à oublier pour coder des applications entières. Les outils cités, plus modernes, permettent de gagner un temps monstre, avec la doc intégrée ou les références des fonctions.

avatar fif | 

Je m’éloigne de l’édition de texte. Toutefois comme on parle d’IDE et donc de GUI, pour le Python et le Java j’utilise Eclipse et c’est pas mal pour coder, refactoriser etc. Les classes sont reconnues et les méthodes sont proposées automatiquement. On sait tout de suite si ça compilera, c’est un bon indicateur. D’autres le font également mais j’accroche moyen.

avatar fif | 

@fif

"m’éloigne"

Dans le temps également… purée le boulet…

Pages

CONNEXION UTILISATEUR