Permets-moi de t'avouer que tes distinctions sont, à mon humble avis, simplistes.
Un éditeur de texte, on lui demande juste de créer, lire, et modifier un série de caractères sur un disque dur.
D'afficher de la coloration syntaxique ou une liste de suggestions, à mon sens ce ne sont pas des choses qui ont trait à l'édition de texte, mais à l'édition de code, chose très différente.
Après tout, un éditeur de texte ne sert pas qu'a créer du code, il y a aussi les todolist, les readme, etc.
Pour prendre un exemple "théoriquement concret", imagines un éditeur de texte qui fonctionne sur le même principe que mpd/mpc/ncmpc, c'est à dire un démon ( mpd ) qui à le contrôle total sur le texte ( 1 démon, 1 fichier, pour prendre un truc simple ), et des clients, qui communiquent avec le démon. Ces clients pourraient très bien s'interfacer à un autre outil qui aurait, lui, le rôle de soumettre des suggestions ( auto-complétion ) et laisser la coloration syntaxique à leur IHM.
Comment pourrais-tu dans un tel cas classer cet éditeur de texte théorique dans une de tes cases? Il est capable de traiter plusieurs langages, puisqu'il ne s'agit que de texte, donc il est généraliste. Pourtant, il n'inclue pas lui-même de système de plug-in et encore moins de coloration syntaxique, choses qui ne seraient gérées que par les clients voire d'autres outils.
Ensuite, la notion d'IDE est, elle aussi, délicate à définir. Selon le langage, on ne compile pas forcément ( interprété ), ne débug pas forcément ( je ne sais pas si ça existe, un débuggueur php par exemple? ), n'utilise pas forcément de diagrammes ( pour du code LaTeX je doute qu'on puisse faire des diagrammes pour représenter le code par exemple ) etc.
J'ai aussi connu des IDE qui n'ont pas la notion de contexte, de projet ( turboC par exemple, que j'ai longtemps préféré a devcpp ou un truc du genre parce que c'était justement moins prise de tête pour compiler/debugguer avec, pas besoin de s'emmerder à créer un projet pour un code de 500 lignes... ).
Alors qu'un simple éditeur de texte, dans un environnement configuré correctement, offrira à son utilisateur ( probablement aguerris aux twm et lignes de commandes ) autant de facilité qu'un IDE.
Du coup, quelle différence entre IDE et "DE" spécialisé pour le dev?
Les seules choses qui permettent à mon avis de différencier un outil qui permets de gérer son code d'un autre, c'est:
_ à quel point il est efficace par défaut. Caractéristique des IDE, ils sont très efficaces out-of-the-box. Par contre, quand on commence a vouloir un truc plus à son goût, ça commence à bloquer comparé à la config totale de son environnement de bureau à coups de scripts et d'outils respectant la philosophie UNIX.
_ à quel point il pèse sur les performances de la machine. Genre, on ne peut pas comparé eclipse ou visual studio avec vim+i3+lxterminal+bash.
Ceci dit, je te remercie parce que j'ai bon espoir de lire des choses très intéressantes en réaction à ton billet :)
# vision simpliste
Posté par freem . En réponse au journal {éditeurs de texte, IDE} ×ばつ {généralistes, spécialisés}. Évalué à 2. Dernière modification le 27 février 2014 à 00:19.
Permets-moi de t'avouer que tes distinctions sont, à mon humble avis, simplistes.
Un éditeur de texte, on lui demande juste de créer, lire, et modifier un série de caractères sur un disque dur.
D'afficher de la coloration syntaxique ou une liste de suggestions, à mon sens ce ne sont pas des choses qui ont trait à l'édition de texte, mais à l'édition de code, chose très différente.
Après tout, un éditeur de texte ne sert pas qu'a créer du code, il y a aussi les todolist, les readme, etc.
Pour prendre un exemple "théoriquement concret", imagines un éditeur de texte qui fonctionne sur le même principe que mpd/mpc/ncmpc, c'est à dire un démon ( mpd ) qui à le contrôle total sur le texte ( 1 démon, 1 fichier, pour prendre un truc simple ), et des clients, qui communiquent avec le démon. Ces clients pourraient très bien s'interfacer à un autre outil qui aurait, lui, le rôle de soumettre des suggestions ( auto-complétion ) et laisser la coloration syntaxique à leur IHM.
Comment pourrais-tu dans un tel cas classer cet éditeur de texte théorique dans une de tes cases? Il est capable de traiter plusieurs langages, puisqu'il ne s'agit que de texte, donc il est généraliste. Pourtant, il n'inclue pas lui-même de système de plug-in et encore moins de coloration syntaxique, choses qui ne seraient gérées que par les clients voire d'autres outils.
Ensuite, la notion d'IDE est, elle aussi, délicate à définir. Selon le langage, on ne compile pas forcément ( interprété ), ne débug pas forcément ( je ne sais pas si ça existe, un débuggueur php par exemple? ), n'utilise pas forcément de diagrammes ( pour du code LaTeX je doute qu'on puisse faire des diagrammes pour représenter le code par exemple ) etc.
J'ai aussi connu des IDE qui n'ont pas la notion de contexte, de projet ( turboC par exemple, que j'ai longtemps préféré a devcpp ou un truc du genre parce que c'était justement moins prise de tête pour compiler/debugguer avec, pas besoin de s'emmerder à créer un projet pour un code de 500 lignes... ).
Alors qu'un simple éditeur de texte, dans un environnement configuré correctement, offrira à son utilisateur ( probablement aguerris aux twm et lignes de commandes ) autant de facilité qu'un IDE.
Du coup, quelle différence entre IDE et "DE" spécialisé pour le dev?
Les seules choses qui permettent à mon avis de différencier un outil qui permets de gérer son code d'un autre, c'est:
_ à quel point il est efficace par défaut. Caractéristique des IDE, ils sont très efficaces out-of-the-box. Par contre, quand on commence a vouloir un truc plus à son goût, ça commence à bloquer comparé à la config totale de son environnement de bureau à coups de scripts et d'outils respectant la philosophie UNIX.
_ à quel point il pèse sur les performances de la machine. Genre, on ne peut pas comparé eclipse ou visual studio avec vim+i3+lxterminal+bash.
Ceci dit, je te remercie parce que j'ai bon espoir de lire des choses très intéressantes en réaction à ton billet :)