Sommaire
- D'autres tâches que l'édition de texte ?
- Plusieurs langages ou plateformes de développement supportés ?
- Possède un modèle de code ?
- Les plugins dans tout ça
- Configuration
- Interface graphique, usability
- Ne pas réinventer la roue pour créer des applications spécialisées
- Tableau récapitulatif
Beaucoup d'entre-nous sommes habitués à un éditeur de texte généraliste (Vim, Emacs, etc) ou un IDE généraliste (Eclipse par exemple). Voyons pourquoi des éditeurs de texte ou IDE spécialisés est ou serait une bonne chose.
Il y a plusieurs axes sur lesquels on peut différencier un éditeur de texte ou IDE. Ces axes ne doivent pas être vu comme blanc ou noir, mais plutôt comme une échelle de gris.
D'autres tâches que l'édition de texte ?
L'axe le plus simple est de différencier un éditeur de texte d'un IDE. Un éditeur de texte se focalise seulement sur l'édition de texte ou de code, tout en essayant de simplifier au maximum l'écriture de ce code. Un éditeur de texte peut par exemple avoir de l'auto-complétion, un panneau latéral avec une liste des fonctions du fichier, des outils de renommage/refactoring, etc.
Par contre, un IDE intègre d'autres fonctionnalités, comme une intégration du gestionnaire de versions, un debugger, compiler et exécuter le code (avec le build system intégré à l'IDE), avoir des schémas de classes, ou que sais-je encore.
Quand on utilise un simple éditeur de texte, on fait généralement le reste en ligne de commande, ou avec d'autres applications. Une session tmux ou Screen est donc l'environnement de développement.
Plusieurs langages ou plateformes de développement supportés ?
C'est l'axe qui détermine si l'application est généraliste ou spécialisée. Un éditeur de texte ou IDE spécialisé ne supporte qu'un seul langage de programmation, ou plusieurs langages généralement utilisés ensemble.
Un éditeur de texte ou IDE généraliste supporte plusieurs langages de programmation complètement différents, voir même plusieurs plateformes de développement différentes.
Possède un modèle de code ?
Encore un autre axe, mais selon moi il s'applique tant aux éditeurs de texte qu'aux IDEs. Il distingue juste les bons éditeurs de texte et IDEs des moins bons.
Un modèle de code, c'est le fait que l'application analyse et ait une bonne compréhension de code que l'utilisateur est en train d'écrire. Ça permet d'avoir des chouettes fonctionnalités comme une complétion intelligente, des outils de refactoring, etc. Quand le code est modifié, le modèle de code est automatiquement mis à jour.
Les plugins dans tout ça
Une application généraliste aura plutôt tendance à implémenter un système de plugins, pour que l'application soit le plus extensible possible, et convienne pour le plus grand nombre de besoins et de langages.
Pour une application spécialisée, les plugins sont moins nécessaires, du moment que les fonctionnalités sont là.
Configuration
De part la nature d'une application généraliste et le système de plugins, la configuration est plus compliquée. On passe donc beaucoup de temps à trouver, installer et configurer les bons plugins, à avoir une configuration de base qui nous convient vraiment bien, et à configurer son éditeur de texte pour qu'il se comporte d'une différente manière selon le langage de programmation.
Une application spécialisée a normalement une configuration beaucoup plus simple. Idéalement, ça Juste Marche™.
Interface graphique, usability
Pour les applications avec interface graphique, l'interface se doit d'être simple pour avoir une bonne usability. Une application généraliste doit créer une interface suffisamment générique et flexible pour les différents plugins et langages. Pour l'utilisateur, ça peut être aussi moins pratique à utiliser.
Exemple : l'application peut avoir des panneaux latéraux, et un panneau en bas. Différents composants peuvent être affichés dans ces panneaux : vue arborescente, liste de fonctions, navigateur de fichiers, sortie de compilation, etc. En LaTeX je n'aurai pas forcément envie d'avoir les mêmes composants que pour faire du C. Et si on veut faire les deux en même temps ? écrire un rapport sur le programme que je suis en train d'implémenter..
Avec des applications indépendantes pour les différentes tâches, le problème ne se pose pas. Le développeur de l'éditeur de texte ou de l'IDE a un contrôle total sur l'interface graphique (surtout s'il n'y a pas de plugins), il y a donc potentiellement une meilleure usability.
Ne pas réinventer la roue pour créer des applications spécialisées
Si l'on veut créer un nouvel éditeur de texte spécialisé, on peut se reposer sur des bibliothèques. Si une telle bibliothèque n'existe pas pour la plateforme visée, la première chose est de d'abord créer cette bibliothèque, ou en améliorer une existante.
Exemple : la bibliothèque GtkSourceView et l'éditeur de texte généraliste gedit. GtkSourceView n'est pas suffisant pour avoir un bon éditeur de texte, un projet à long terme est donc de rendre le code de gedit plus réutilisable, en le migrant dans GtkSourceView ou dans un git submodule.
Autre chose, un argument en faveur des éditeurs de texte généralistes est que tous les raccourcis clavier sont les mêmes peu importe la tâche qu'on fait. C'est tout à fait possible aussi avec des éditeurs de texte spécialisés utilisant la même bibliothèque, si les raccourcis clavier sont définis dans la bibliothèque.
Tableau récapitulatif
tl;pl: (trop long, pas lu)
| Plusieurs langages | D'autres fonctionnalités | Configuration | |
|---|---|---|---|
| Éditeur de texte spécialisé | Non | Non | Simple |
| Éditeur de texte généraliste | Oui | Non | Plus compliquée |
| IDE spécialisé | Non | Oui | Assez simple |
| IDE généraliste | Oui | Oui | Plus compliquée |
Ce qui est expliqué ici s'applique surement à d'autres domaines. Et il y a surement d'autres axes possibles pour différencier les différents IDEs et éditeurs de texte.
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Emacs
Posté par Zylabon . Évalué à 2.
L'éditeur de texte d'emacs est entièrement configurable. Il peut même se comporter comme vi.
Please do not feed the trolls
[^] # Re: Emacs
Posté par saltimbanque (site web personnel) . Évalué à 2.
oui mais (totalement) comme vim
[^] # Re: Emacs
Posté par Reihar . Évalué à 1.
Pas sûr qu'un éditeur de texte où le mode par défaut n'est pas l'édition de texte, soit un bon choix.
[^] # Re: Emacs
Posté par swilmet . Évalué à 7.
Si tu te réfères à Vi, par défaut c'est le mode d'édition de texte. Pour passer en mode insertion, il faut appuyer sur i.
[^] # Re: Emacs
Posté par Maclag . Évalué à 9.
Si on doit ajouter les OS à la liste des IDE, on n'a pas fini!
[^] # Re: Emacs
Posté par fearan . Évalué à 6.
Oui il fait tout, pas mal de truc 'de base', sans rien avoir à configurer (debugger, completion semi-intelligente…), (d'autre avec une configuration minimale BROWSE, j'ai pas encore trouvé d'équivalent dans les IDE, compilation, flymake, patrons de code), et enfin certain avec une configuration lourde (CEDET + clang pour la complétion intelligente, refactoring de base (semantic) )…
Emacs possède énormément de fonctionnalités, qui font que je continue de l'utiliser en parallèle d'intellij (notamment les macros), la capacité de tout faire au clavier, rends l'utilisation des macros (et de son compteur automatique) très pratique.
Pour avoir utilisé eclipse, j'ai l'impression d'une perte de place monumentale; même quand je met l'édition en 'plein écran' j'ai l'impression d'avoir que 2/3 de mon écran dispo, là ou avec intellij j'ai du 90% et emacs 95% (et encore je peut cacher la menubar et les scrollbar, me laissant juste 2 lignes.
Une autre fonctionnalité que j'aime bien c'est la capacité de rendre un buffer en read-only pour éviter les modifs intempestives, le split sur le même fichier pour voir 2 endroit du même fichier en même temps, faire du highlight sur des regexp, et pas seulement une ou deux mais autant que je veux, la possibilité d'envoyer une fenêtre sur un autre PC (oui quand on se déplace, j'ai toujours le même éditeur, avec les buffers et tout), la possibilité de bosser sur du code distant, tetris (oups).
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Emacs
Posté par laurent laffont (site web personnel) . Évalué à 3.
Pour moi le gros avantage d'Emacs est qu'on peut le spécialiser facilement pour le projet sur lequel on travaille et ainsi gagner énormément de temps. C'est un environnement "plastique" et à part les environnements Smalltalk je n'ai pas trouvé d'IDE aussi malléable.
# À propos des éditeurs de texte généralistes
Posté par Zylabon . Évalué à 10.
Emacs avec l'installation par défaut peut :
* contrôler le gestionnaire de version du fichier sur lequel on travail
* s'interfacer avec le débugger (gdb pour c/c++ au moins, d'autre surement)
* s'interfacer avec le système de compilation et si le compilo détecte un problème, l'éditeur peut placer le curseur au bon endroit dans le bon fichier (et je ne parle même pas de flymake).
Il y a aussi un gestionnaire de package avec, qui permet d'étendre le bouzin super facilement, c'est aussi simple que M-x package-install RET haskell-mode RET.
Bref, soit emacs est à rangé dans les "IDE généraliste" soit j'ai grand mal à trouver du sens à ton billet.
Please do not feed the trolls
[^] # Re: À propos des éditeurs de texte généralistes
Posté par freem . Évalué à -2.
Ça dépend, est-ce que emacs inclue un éditeur de texte?
[^] # Re: À propos des éditeurs de texte généralistes
Posté par Troy McClure (site web personnel) . Évalué à 6.
Peut être qu'il sous-entendait que l'IDE s'occupe typiquement de gerer les projets (l'outil de build fait partie de l'ide), ne donne pas la sensation d'etre un assemblage de scripts heteroclytes qui marchent plus ou moins, et que l'IDE est pleinement fonctionnel sans qu'on passe 3 semaines à écumer le net pour se faire un .emacs special dev aux petits oignons.
On pourrait croire que je deteste emacs mais ce n'est pas le cas, je l'utilise 99% du temps plutot que xcode / visual c++ / eclipse etc. Mais ça reste un bete éditeur de texte.
[^] # Re: À propos des éditeurs de texte généralistes
Posté par swilmet . Évalué à 1.
Oui c'est vrai qu'avec les descriptions que j'ai donné, Emacs est plutôt un IDE. Pourtant on le présente plus comme un éditeur de texte, au même titre que Vim. La différence entre Emacs et Eclipse est le fait qu'Eclipse a une GUI, tandis qu'Emacs s'utilise plus en mode texte/commandes. C'est un autre point de différenciation, et comme je l'ai dit au début du journal, ce sont plutôt des niveaux de gris.
Dans tous les cas, Emacs est généraliste, il y a moyen de le configurer pour faire plein de tâches différentes, on est bien d'accord là-dessus.
# Différence entre IDE et éditeur simple
Posté par flan (site web personnel) . Évalué à 8.
Pour moi, la grosse différence entre les deux, c'est qu'un éditeur de texte concerne un fichier, alors que l'IDE va s'occuper de projets.
Avec un éditeur de texte, tu peux ouvrir n'importe quel fichier de façon unitaire, sans te soucier de l'endroit où tu es (il n'y a pas de contexte). L'IDE possède un contexte (par exemple les bibliothèques externes, la version du langage utilisée, du compilateur, où sont situés les tests, les réglages choisis pour les warning, etc.), ce qui change tout en termes de productivité.
[^] # Re: Différence entre IDE et éditeur simple
Posté par swilmet . Évalué à 1.
Le concept de projet, encore un autre axe de différentiation.
Une chose que je n'ai pas dit, c'est qu'avec le temps (ajouts de fonctionnalités), ou avec des plugins, il y a moyen de transformer un éditeur de texte en un IDE.
Par exemple gedit est considéré comme un simple éditeur de texte, mais avec des plugins il y a moyen de le configurer comme un IDE léger pour Vala.
# Exemple
Posté par stopspam . Évalué à 2. Dernière modification le 26 février 2014 à 23:30.
J'utilise les 2 dans ma vie de tous les jours :
[^] # Re: Exemple
Posté par freem . Évalué à 4.
Pas bien d'utiliser VS sans licence !
[^] # Re: Exemple
Posté par Atem18 (site web personnel) . Évalué à 1.
MSDNA.
[^] # Re: Exemple
Posté par freem . Évalué à 1.
Héhéhé, je n'ai pas dit mon dernier mot:
Pas bien de se laisser embrigader par les politiques commerciales et de favoriser ainsi la vente liée ( on est trolldi depuis 1H, ouf suis sauvé )
[^] # Re: Exemple
Posté par dave_null (site web personnel) . Évalué à 1.
La version express est gratuite. Mais vu la concurrence ils devraient avoir une seule version de visual studio, gratuite. Les fonctionnalités de la version ultimate ne justifient pas le prix et devraient être disponible gratuitement.
[^] # Re: Exemple
Posté par Atem18 (site web personnel) . Évalué à 10.
Ouais, mais c'est plus rassurant pour les DSI de se dire qu'ils ont payé cher un logiciel et que donc, ça marche mieux qu'un logiciel gratuit.
[^] # Re: Exemple
Posté par tyoup . Évalué à 1.
Bah si c'est la boîte qui paye, pourquoi s'en priver ? En plus tu te fais quelques weekends relais châteaux…
[^] # Re: Exemple
Posté par Zylabon . Évalué à 2.
Il faudrait voir les raisons qui poussent la boîte à payer…
Please do not feed the trolls
[^] # Re: Exemple
Posté par stopspam . Évalué à 2.
Je n'ai pas assez précisé : licence sublime achetée perso avec laquelle je travaille en pro. VS c'est du MSDN payé par le pro.
[^] # Re: Exemple
Posté par dave_null (site web personnel) . Évalué à 4. Dernière modification le 27 février 2014 à 08:46.
T'as essayé Visual Studio avec Resharper ? Tu obtiens le meilleur d'IntelliJ dans VS et ça devient rapidement indispensable.
J'ai aussi acheté Sublime Text après l'avoir utilisé plus d'un an sans payer. Il n'est pas libre et j'aimerais bien qu'un concurrent libre se développe (je n'ai pas le temps ni l'envie pour ça ;) ) mais en attendant il est excellent.
[^] # Re: Exemple
Posté par RonanLP . Évalué à 5.
Un concurrent libre de Sublime Text est déjà en développement : Lime Text.
Je ne l'ai pas testé mais c'est un projet intéressant.
[^] # Re: Exemple
Posté par swilmet . Évalué à 1.
D'après les (plus vieux) développeurs de gedit, il ne manque pas grand chose à gedit pour être à la hauteur de sublime text. C'est juste une question de découvrir les différents plugins disponibles, et de s'habituer aux raccourcis clavier. Et gedit existe depuis plus longtemps que sublime text…
[^] # Re: Exemple
Posté par dave_null (site web personnel) . Évalué à 2.
J'aime bien gedit, mais je ne suis pas d'accord avec leur point de vue.
SublimeText est très performant, il gère les très gros fichiers sans problème, il se lance rapidement et peut gérer de nombreux fichiers ouverts en même temps sans difficulté.
Il a un système de plugin simple et efficace avec une comptabilité pour pas mal de plugins TextMate. C'est beaucoup plus complet que ce que l'on peut trouver pour Gedit.
Il est multiplateforme est a un sélecteur de fichier intégré au système.
Et surtout, il vient de base avec plein de fonctionnalités. Pas la peine de le modder pendant des heures pour avoir quelque chose de puissant.
[^] # Re: Exemple
Posté par pepp . Évalué à 1.
100% d'accord. Si les dév de gedit le considèrent presque à la hauteur de ST, ils manquent clairement de recul.
J'ai utilisé gedit comme éditeur de code pendant longtemps, et après avoir testé ST 1 heure il est impossible de revenir en arrière.
Alors bien sûr les 2 savent éditer du texte, à part ça :
* mode hexadécimal sur gedit ?
* curseurs multiples ?
* ouverture des fichiers en utilisant uniquement le clavier + prévisualisation instantanée des fichiers ?
* super rapide (même sur des gros fichiers) ?
* minimap du fichier ouvert à droite ?
* gestion minimale de projet ? Pour ceux qui ne connaissent pas : ça permet d'appliquer une configuration à un ensemble de fichier, d'exclure certains fichiers, etc…
Et c'est juste ce qui me vient à l'esprit en réfléchissant 2 minutes.
[^] # Re: Exemple
Posté par stopspam . Évalué à 2.
J'ai un point de vue différent :
Bref, avec tous ces avantages je me fou qu'il ne soit pas libre.
# vision simpliste
Posté par freem . É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 :)
[^] # Re: vision simpliste
Posté par ckyl . Évalué à -1.
Si les deux sont insignifiants sur une machine moderne ;)
[^] # Re: vision simpliste
Posté par saltimbanque (site web personnel) . Évalué à 2.
mardown
dictionnaire
pour commencer…
[^] # Re: vision simpliste
Posté par fearan . Évalué à 4.
Sauf que pas mal d'entreprise tardent à changer les PCs, ce qui fait que je me retrouve avec une machine avec 2Go de ram, tu prends les 700Mo d'intellij, les 800Mo de JBoss, et quand tu compiles le code C++ à coté, tu pleures parce que ça swap au link (et même avant si le distcc n'a pas envoyé le gros fichier sur une autre machine).
Bon le changement est prévu pour cette année.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: vision simpliste
Posté par ckyl . Évalué à 1.
4Go de RAM c'était déjà la config standard il y a 7 ans ! Si on fait un calcul simple:
Donc en gros si tu passes plus de 2h à swapper ou configurer ta machine pour cause de limitation RAM en 3 ans, soit 10s par jour, c'est débile.
Le poids d'un IDE sur une machine moderne est très faible. Et le poids d'un IDE par rapport à un environnement standard est faible (Un environement SOA typique c'est 10..30 composants lancés, des DB etc). Donc sauf cas particulier qui peut se résoudre facilement, le poid d'un IDE de nos jour c'est rien. C'était pas vrai il y a 10 ans mais c'était il y a 10 ans… D'un point de vu cout, le gain de productivité d'un IDE est énorme par rapport au cout matériel (combien de temps pour configurer parfaitement vim ou emacs pour TOUT tes employés ?).
[^] # Re: vision simpliste
Posté par fearan . Évalué à 6.
Je ne dis pas le contraire, mais les grosses structures ont tendance à tirer au max sur la corde, au final, ça fait perdre du temps et de l'argent, mais cette perte est invisible, alors que l'achat de mémoire (un poil plus que 100€ vu qu'il faut la gestion de parc, l'immobilisation de la machine (1H), lui est bien visible… mais je suis d'accord pour dire que c'est ridicule comparé au temps perdu.
On retrouve la même problématique qui pousse les responsable des achats prendre des presta plutôt que des embauchés.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: vision simpliste
Posté par freem . Évalué à 5.
Si je rappelle qu'il n'y a pas que les entreprises qui font du dev, je passe pour un abruti, je suis hors sujet, ou j'ai raison? ( notez que je suis plus habitué au 2 1ers qu'au 3ème, je pense même que j'aime ça :p )
[^] # Re: vision simpliste
Posté par lasher . Évalué à 3.
On n'a clairement pas bossé dans les mêmes boites. :-) En stage de fin d'étude vers 2005, ma machine de développement c'était un Céléron ou un Duron à 600MHz, et 512Mio de RAM. En milieu de stage, on nous a royalement doublé la RAM (1Gio, WOUHOU!). Mon environnement de travail c'était à l'époque : Eclipse, Hibernate, JBoss, SVN. Le tout sous Windows 2000. Alors certes je bossais pour une startup, etc., et certes je parle d'il y a 8 ans et des cacahuètes et pas 7 ans, mais c'est pour dire que 4Gio il y a 7 ans, c'était clairement pas une config. standard dans beaucoup de boites.
[^] # Re: vision simpliste
Posté par fearan . Évalué à 3.
Y a 5 ans j'avais la même machine qu'aujourd'hui : sempron, 2Go de ram.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: vision simpliste
Posté par freem . Évalué à 8.
Le rPI, c'est moderne ou pas?
Oui, c'est limite trollant, j'avoue, mais, pour me justifier, les gens confondent souvent moderne et ayant une valeur commerciale élevée.
Et moi, je me dis que vu qu'on pouvais dev il y a 20 ans, pourquoi ne le pourrait-on plus avec des machines de même puissance, maintenant?
Alors, bien entendu, je sais que, je cite Mr dupond ( et pas dupont ) "Les applications modernes ont besoin de machines modernes pour tourner!" sauf que la raison principale de cet état de fait, c'est qu'on ne sais plus faire autrement que faire des trucs lourds j'ai l'impression.
Allez, un exemple pour accompagner mon argument: combien d'utilisateurs de word utilisent des fonctionnalités coûteuses en terme de CPU qui n'existaient pas il y a, disons, 10 ans? En pourcentage estimé, hein, pas en chiffres bruts.
Moi, je gage qu'on est largement en dessous des 25%, autrement dit, que la puissance consommée par ce logiciel à l'heure actuelle pourrait être réduite drastiquement dans 75% des cas.
Et ça, je suis incapable d'estimer l'impact que ça aurait énergétiquement et économiquement parlant sur notre planète. Moins de gaspillage, c'est la seule chose dont je sois persuadé ( pas convaincu, je manque de preuves pour ça ).
Ca vaut pour toutes les suites bureautiques, d'ailleurs.
Et pour revenir au dev, et à des cas concrets, la machine sur laquelle j'ai le plus codé ces 3 dernières années est un netbook, 1Go de RAM, dual core dual thread cadencé à 1.5GHz. Je t'assure que sur cette machine, ça à un impact non négligeable. Et je ne vois pas pourquoi je devrais m'interdire de coder dessus sous prétexte qu'elle m'a coûté que 210€ il y a 4 ans.
PS: vu le smiley, j'imagine que c'était de l'humour ta réponse, mais je tenais malgré tout à saisir l'occasion pour exprimer mon ras-le-bol des bloatwares et l'énervement que m'a toujours causé les gens qui disent "ne vous occupez pas des perfs, le client rachètera du matos", genre de mots entendu de mes profs, il y a presque 10 ans… et qui m'enragent toujours autant… oups :)
[^] # Re: vision simpliste
Posté par ckyl . Évalué à 5. Dernière modification le 28 février 2014 à 08:50.
C'est pas une station de travail. C'est comme filer une trottinette à un commercial.
Je ne vois pas le rapport. L'équation est simple: si je peux avoir du matos adapté à mon besoin pour un coût négligeable alors le problème n'existe pas. En l’occurrence aujourd'hui pour 500€ HT tu as une bête de course où tu peux lancer en parallèle 2VM, Eclipse, Netbeans et Intellij sans même le sentir. Le problème n'existe donc plus.
Même pour un particulier ce prix est ridicule. Ça fait le prix de la redevance TV par an en lissant…
Pas forcément et ce n'est pas le débat ici. La remarque initiale était " à 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. " ce qui pour moi est un très mauvais critère de choix puisqu'il n'est plus pertinent depuis des années. Si tu as besoin d'un IDE, utilise un IDE. Si ta machine est limite, cours investir 100€ plutôt que de passer 3 mois à bidouiller pour arriver à un truc qui fait la moitié de l'autre solution et où tu aurais pu faire des trucs utiles à la place.
Maintenant si "vim+i3+lxterminal+bash" répondent exactement à ton besoin, c'est ce qu'il faut utiliser ! La selection se fait sur la pertinance de l'outil par rapport au besoin.
C'est vrai pour certaines choses. Maintenant si on revient à notre sujet, regarde la conso/rapidité d'intellij pour ce qu'il est capable de faire et trouve moi quelque chose qui a fait notablement mieux. Grosso modo ce genre de logiciel à un surcoût important sur de tout petit projets, mais l'empreinte n'évolue presque pas quand tu passes à plusieurs très gros projets.
Tu fais ce que tu veux et personne ne t'as dicté le choix que tu devais faire ni n'a dit quel était le bon outil pour ton besoin. Simplement si tu as BESOIN de cet outil alors c'est un faux problème de nos jours.
Si tu passes 3 mois à configurer ton emacs pour arriver à une productivité équivalente. Tu as juste décidé d'investir 3 mois plutôt que 100€. C'est un choix sur ton temps personnel. En milieu pro la question ne se pose pas une seconde, le temps est extrêmement cher.
C'est ce que je faisais il y a dix ans quand je faisais majoritairement du C. Ça avait un sens puisque les IDE étaient de toute façon poucraves et que le résultat final était nettement meilleur avec un setup maison. Mais ça consommait déjà monstre de temps. Alors quand tu passes sur des langages ou l'IDE est excellent va falloir s'accrocher sévère pour m'expliquer le gain final.
Maintenant ce ne sont que des outils. Ils ne regardent donc que la personne qui les utilise. Tant que tu suis la qualité et la productivité des autres c'est une boite noir dont on se fou. Tu pourrais même écrire dans Notepad si tu veux.
[^] # Re: vision simpliste
Posté par Letho . Évalué à 2. Dernière modification le 28 février 2014 à 01:15.
Encore heureux que ça existe, j'utilisais encore XDebug la semaine dernière ^^
(et je dois dire que sans, je me serais pendu, parce que PHP, hein, déjà, alors bon, voilà quoi, donc sans debugger en plus, rholala)
http://xdebug.org/
[^] # Re: vision simpliste
Posté par freem . Évalué à 1.
Merci bien, je me sentait désespéré à l'idée de devoir manipuler un langage non typé sans débogueur, j'allais même sûrement binder une combo de touches de vim pour insérer des print, vu que le taf m'obligera sûrement à toucher à ce langage… ( quoique le client avait l'air heureux quand j'ai dit que je préfère utiliser d'autres langages a titre perso… peut-être que… avec quelques TU pour assurer mon coup, il y a moyen de vendre une migration de langage sur ce code crado, histo et phpo… )
# Euh… ?
Posté par barmic . Évalué à 7.
Quel est l'intérêt de ce genre de question ?
Ça sert à quoi de poser une étiquette ainsi ?
Ça change en quoi la vie des utilisateurs de savoir que ce qu'ils utilisent est un IDE ou un éditeur de texte ?
Personnellement j'ai arrêté de me poser la question. On travail avec un environnement de développement, le fait qu'il soit plus ou moins intégré et comment n'a d'intérêt que pour l'utilisateur. C'est une question de goût et de fonctionnalité. Typiquement les gros IDE Java vont être imbattables sur le refactoring Java (vim/emacs avec les outils clang commencent à faire quelque chose de correct, mais c'est loin fonctionnellement de ce qu'est capable de proposer IntelliJ), les environnements non intégrés utilise les différents outils en mode « raw » donc utilise potentiellement toute la puissance de chaque outil et pas simplement celles qui sont disponibles via leur environnement intégré.
Ce qui est intéressant c'est de savoir ce dont tu as besoin et comment tu répond à ton besoin en fonction de tes goûts et de tes compétences.
Y coller une étiquette est assez futile.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Euh… ?
Posté par swilmet . Évalué à -2. Dernière modification le 27 février 2014 à 13:44.
Donner un nom à une chose est important. Les design patterns en POO est très important par exemple. Si je te parles de méthode factory, tu comprends tout de suite de quoi je parle.
Une autre chose importante est de trouver des axes de différentiation. J'en ai donné quelques uns dans le journal, et d'autres en ont donné d'autres dans les commentaires.
Par exemple, savoir qu'un certain IDE possède un modèle de code est intéressant, car ça implique qu'il puisse y avoir des fonctionnalités plus intéressantes.
[^] # Re: Euh… ?
Posté par barmic . Évalué à 4.
Non ce qui est intéressant c'est de donner des noms différents à des choses différentes. Si tu donne un nom, mais que tu n'es pas en mesure de le définir clairement c'est au contraire contre productif. Les design patterns sont justement très clairement définis. L'important c'est de pouvoir communiquer donc si tu n'a pas de définition claire au mot que tu utilise, il y a une probabilité non-nul que ton interlocuteur n'ai pas la même. Tu ne crois pas que c'est gênant.
Là où le questionnement du journal n'est pas pertinent c'est que « éditeur de texte » est une fonctionnalité d'un logiciel et « IDE » est un ensemble de fonctionnalités pas clairement défini, mais dont on peut être sur qu'il inclut « éditeur de texte ». Se demander si un logiciel est un éditeur de texte ou un IDE c'est comme se demander si un véhicule est une voiture ou si il a des roues.
Bref à mon avis tu défini une frontière qui n'existe pas.
Pouvoir comparer les logiciels est intéressant par contre mais c'est une tâche relativement complexe vu la diversité des fonctionnalités et que chacune ne peut pas être évaluer de manière linéaire (l'intégration du builder peut être différentes dans 2 logiciels sans permettre de dire la quelle est la meilleure, je pense par exemple à l'intégration de maven dans intellij et netbeans). Il y a de plus des fonctionnalités assez exotiques netbean/eclipse permettent de se connecter à une base de données ou un annuaire LDAP, emacs permet des choses assez folles aux développeurs lisp.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Euh… ?
Posté par fearan . Évalué à 1.
Ça existe ?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Euh… ?
Posté par swilmet . Évalué à 3. Dernière modification le 27 février 2014 à 17:57.
Si on prend deux extrêmes, gedit sans aucun plugin, et Eclipse, l'un est clairement un éditeur de texte et l'autre un IDE. Les termes éditeurs de texte et IDE existent, on les utilise dans la vie courante. Essayer de donner une définition à ces mots est donc un comportement normal.
Le but principal du journal était plutôt d'expliquer la différence entre généraliste et spécialisé. La plupart des éditeurs de texte et IDE disponibles actuellement sont généralistes. L'idée du journal était de donner envie à certains développeurs de développer des applications spécialisées, plus simple de configuration et plus pratique à utiliser que des usines à gaz.
[^] # Re: Euh… ?
Posté par Zylabon . Évalué à 2.
Plus simple de configuration… certes. Mais pourquoi ? La productivité dans un langage donné ne s'augmente pas en raccourcissant le temps de configuration mais l'efficacité une fois qu'on est lancé.
Pour faire des outils pédagogiques, d'accord, montrer comment utiliser un langage L dans un cliquodrome qui intègre éditeur de texte, compilateur, et débogueur, mais dès qu'on le connait un peu, on a besoin d'outils puissants pour envoyer la purée, de pouvoir scripter, l'écrire des fonctions qui vont chercher dans la doc en ligne…
Please do not feed the trolls
[^] # Re: Euh… ?
Posté par freem . Évalué à 1.
Mais un outil spécialisé dans un langage particulier incluera probablement nombre d'automatismes particuliers à ce langages, de raccourcis pour ses idiotismes et que sais-je encore.
Dans le cas de C++, il serait même imaginable qu'un nouveau moteur d'autocomplétion spécialisé puisse être réellement efficace ( j'ai bien dit: nouveau ;) )
En soit ça ne me semble pas idiot, de spécialiser l'outil… jusqu'a ce que je me rappelle qu'en général, un développeur professionnel n'utilise pas qu'un seul langage, et que changer d'outil en fonction du langage est assez ennuyeux, voire pénible.
[^] # Re: Euh… ?
Posté par Zylabon . Évalué à 2.
genre ça ? https://llvm.org/svn/llvm-project/cfe/trunk/utils/clang-completion-mode.el
(pas encore testé c'est sur ma todo list)
Please do not feed the trolls
[^] # Re: Euh… ?
Posté par barmic . Évalué à 2.
Je n'ai pas dis que c'était pas normal juste inutile. Crier quand on tombe du toi ne sert à rien, mais c'est normal de le faire.
Tu virevolte entre 4 concepts éditeur de texte/IDE et généraliste/spécifique, alors que tu ne veux parler que des 2 derniers, c'est dommage ça brouille ton message (pour preuve le nombre de commentaires sur la ce qu'est ou pas un IDE).
Néanmoins je pense que tu passe à coté de quelque chose.
Utiliser des outils spécifiques c'est consommateur en temps car il faut continuellement apprendre de nouveaux outils. Avant de se lancer dans la création d'un éditeur spécifique il faut bien comprendre ce que l'on souhaite apporter fonctionnellement :
Et il faut garder en tête qu'avec l'utilisation d'un outil généraliste on a une forte capitalisation.
Il faudrait à mon avis regarder du coté d'eclipse qui a beaucoup de versions spécialisée (pour LDAP, pour le minde mapping, etc).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Euh… ?
Posté par freem . Évalué à 1.
Faux.
Tu pars du principe que tout langage de dev n'est constitué que de caractères ascii, la, voire de caractères tout court.
Ce n'est pas le cas. Les logiciels permettant de créer des programmes pour des automates industriels ne sont pas nécessairement textuels. Je ne connais que peu ce type de techno ( en fait, que de nom ) mais mon frère à fait ce genre de choses en bts électrotechnique ( il me semble qu'il me parlait de graphset, ou un truc du genre ).
Ce qui est amusant, c'est que je te contredis pour apporter de l'eau à ton moulin: un IDE est loin d'être évident à définir précisément. Après tout, le logiciel qui lui permettait de créer ces diagrammes qui étaient le source d'un programmes, n'avaient rien à voir avec un éditeur de texte, et étaient pourtant ce que l'on appellerai des IDE.
Lors d'une formation de chef de projet ( merci le pseudo anonymat internet, je préfère ne pas en parler si on peut m'identifier, tellement ça m'emmerderait que ça arrive aux mauvaises oreilles ) j'ai aussi vu des outils générant des programmes sans une once de texte, à base de schémas ( gestion de process en entreprise, de flux, bref, des trucs chiants… mais ça marche ) .
Donc, il n'y a pas qu'en industrie, mais aussi en service. Vraiment, non, un IDE n'inclue pas nécessairement un éditeur de texte.
Ah, ne pas oublier de citer access, que tout le monde ici doit connaître et qui permet de créer une DB ainsi qu'une IHM sur cette DB sans taper de coder si on le souhaite.
[^] # Re: Euh… ?
Posté par barmic . Évalué à 2.
Je vois très bien de quoi tu veux parler. Oracle est le roi de ce genre de choses avec OracleBPM, Oracle Service Bus et autres, mais tout ceux-là ont un éditeur de texte, mais tu as raison, il y a aussi les outils de création d'interface comme glade.
Mais bon c'était un détail de mon commentaire :)
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Euh… ?
Posté par Lutin . Évalué à 2.
Ça existe aussi à partir de schémas électroniques.
Repenser à LabView me donne des frissons, ce fut une période douloureuse.
[^] # Re: Euh… ?
Posté par robin . Évalué à 1.
brrr !
bépo powered
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.