Discussion :

[hegros]

Les programmeurs savent ils encore développer avec un éditeur de texte ?

oui : cela ne fait pas d'eux des programmeurs de génie ou des dinosaures
non : cela ne fait pas d'eux de piètres programmeurs ou des jeunots qui connaissent rien


Le développement logiciel ce n'est pas une activité ooù il y a 100% de programmation, j'ai envie de dire on s'en fout que le programmeur sache ou pas développer avec un éditeur de texte ce qui compte c'est qu'il sache développer tout court ! Parce que éditeur de texte ou pas c'est toujours les mêmes problèmes qui se posent : bug, régression, cout, délai, qualité...


Pour l'instant l'avenir évolue plutôt en faveur de développement sans éditeur de texte (comprenez avec un éditeur graphique) car c'est plus intuitif, plus facile à apprendre, plus facile à prendre en main il suffit de sortir un arbre qualimétrique pour s'en rendre compte.

A l'heure de la 3D à la tv on va pas faire de la 3D en mode texte dans 10 ans, cela paraîtra probablement ridicule ou sinon pour se souvenir d'une époque qu'on appellera mystique

[deadalnix]

Nouveau ne signifie pas mieux.

Je ne vois par exemple aucun moyen graphique digne de ce nom remplacer grep. Je ne suis pas en train de glorifier les vieux truc, avoir une interface graphique, c'est nettement plus pratique pour un tas de truc.

Mais parfois, il faut savoir investir de son temps pour apprendre à se servir d'un outil. Cela est particulièrement pertinent dans le cas d'éditeurs comme vim ou emacs, qui, si on se donne la peine de les connaitre, sont d'une efficacité redoutable, et je ne crois pas qu'un éditeur graphique soit capable de remplacer cela. (ou alors faire la même chose dans un fenêtre graphique).

EDIT: d'ailleurs, on voit arriver de plus en plus d'outils alliant les deux, tels que gnome-do. Et c'est vraiment une merveille.

[ok.Idriss]

(ou alors faire la même chose dans un fenêtre graphique).

Bah le pire c'est que Emacs et vim ont leur interface graphique (Gvim pour vim) ... et, ça ne change pas grand chose (ça ne m'apporte rien personnellement) ...

[souviron34]

A l'heure de la 3D à la tv on va pas faire de la 3D en mode texte dans 10 ans, cela paraîtra probablement ridicule ou sinon pour se souvenir d'une époque qu'on appellera mystique

Entre pré-séquencer/monter une séquence / film, créer des effets, et créer le programme qui effectue les opérations, les besoins ne sont pas les mêmes

Donc vraisemblablement dans 10 ans on fera encore de la 3D en mode texte.. re.

Essaye de programmer un ray-tracing ou une projection ortho-cylindrique uniquement en visuel, ça va être coton

[toham]

Alalala, je me bidonne en lisant tous les gens qui disent qu'ils codent tout à la main, ba ecouté , c'est bien sa prouve que vous connaissez parfaitement votre language, mais c'est completement inutile, la puissance d'un développeur c'est de pouvoir développer dans tous les langages, c'est pas pour rien qu'on dit qu'un informaticien reste un étudiant toute sa vie, et je sais plus qui à dit une tel connerie : "Je developpe tout moi meme, je n'aime pas l'auto-complétion...." n'importe quoi, ba ecoutez moi tous, le jour ou on vous demandera de developper une application dans un langage que vous ne maitrisez pas, vous allez faire comment, apprendre par coeur le langage pour tout faire dans un éditeur de texte........ vous êtes zero.
Je comprend ceux qui disent qu'un developpeur qui ne comprend pas le code généré par un EDI n'est pas un vrai développeur. Mais de la a dire qu'un vrai developpeur ne developpe qu'avace un editeur de texte, faut arrété, sa voudrait dire que les 3/4 des developpeur de moins de 35 ans ne sont pas des developpeurs.......

Un developpeur sait se servir d'une documentation, et un developpeur abruti est celui qui apprend par coeur un langage.
Perso je travaille en Java (eclipse), Php (ecplise), C# et VB (VS).... et j'en passe, pourtant je connais pas entierement le langage mais je sais m'adapter.

Et pour ceux qui code encore avec un éditeur de texte, j'aimerais bien savoir combien de temps vous prennez pour créer une interface... et codé l'evenementiel et le traitement deriere.

Bref, je veux bien croire qu'un dreamweaver soit bidon pour généré du HTML, et je suis totalment d'accord de le faire à la main, mais d'une c'est pas a un developpeur de faire le code html mais au designer, vous votre taff c'est de developper le traitement et l'évenementiel deriere...

[BainE]

vous êtes zero.

Nan ca c'est ta note en dictée (sauf si tu n'es pas francophone de naissance).

Par contre c'est bien là toute le différence entre un bon développeur et un mauvais développeur. Le bon développeur, il voit un clavier, il code, le mauvais développeur, il voit un clavier, il code mais c'est un mauvais développeur, c'est pas pareil.

[ok.Idriss]

Par contre c'est bien là toute le différence entre un bon développeur et un mauvais développeur. Le bon développeur, il voit un clavier, il code, le mauvais développeur, il voit un clavier, il code mais c'est un mauvais développeur, c'est pas pareil.

C'est comme pour la chasse à la galinette .

Bon sinon, comme ça a été dit, c'est une affaire de préférence et mieux vaut coder avec ce avec quoi on n'est le plus performant ...

On ne peut cependant pas nier que beaucoup de codeurs ne savent pas ce qui se passe derrière un EDI (ce qui n'est pas toujours important certes, mais ce n'est pas non plus inutile), mais ce n'est pas le cas de tous. Certains codeurs hors pairs préfèrent travailler sur Eclipse/NetBeans/etc, ce n'est pas pour autant qu'ils sont incompétent. De même pour ceux qui préfèrent coder sur un éditeur, ce servir des Makefile, de la ligne de commande.

Enfin il est bien aussi de savoir coder des deux façons pour s'adapter à n'importe qu'elle plateforme de développement (C'est un manque de ne pas savoir se servir d'un EDI, comme c'est un manque de ne pas savoir développer sur un éditeur en se servant aussi de la ligne de commande même si combler ces manques n'est pas forcement indispensable à notre travail).

Cordialement,
Idriss

[dams78]

Ce qui serait intéressant à savoir c'est si il y a une différence réelle de qualité. Parce que si un IDE performant permet de coder une application de qualité tout en restant dans les clous (je pense notamment au checkstyle d'eclipse) et tout ceci rapidement, moi je dis bingo !!!

A vouloir tout faire sois même n'est ce pas la meilleur façon de tout faire moins bien? (Ceci est une vraie question).

[deadalnix]

Si je pense aussi.

A mon avis, l'important c'est d'avoir le contrôle, mais pas forcement de contrôler.

J'avais cette discutions avec un autre dev il y a pas longtemps. On se disait que la plupars du code devrait être managé (comme C# ou Java). Le soucis c'est que parfois, cela à un impact négatif. Mais en fait rarement, cela concerne quelques lignes de code, la partie du code qui s'exécute des millions de fois.

Je pense qu'il est raisonnable, et même souhaitable de laisser faire la machine dans la plupart des cas. Mais il est important d'avoir le contrôle, pour pouvoir reprendre la main quand il le faut.

Il en va de même avec l'éditeur. On doit être aidé par notre éditeur, et pas en être esclave. La est tout le problème.

Je tiens aussi à dire que quand on parle d'éditeur de texte, on ne parle pas de notepad la, mais bien d'éditeurs tels que vim ou emacs.

[toham]

Nan ca c'est ta note en dictée (sauf si tu n'es pas francophone de naissance).

Par contre c'est bien là toute le différence entre un bon développeur et un mauvais développeur. Le bon développeur, il voit un clavier, il code, le mauvais développeur, il voit un clavier, il code mais c'est un mauvais développeur, c'est pas pareil.

Je vois que tu as beaucoup de repartit, obliger de critiquer l'orthographe pour rendre moins pertinent un post .. c'est bien.
Quand tu aura une critique à faire sur ce que j'ai dit , je serais la pour la lire et l'accepter mais si c'est pour lire encore ce genre de bétises ....
Sinon j'ai kiffé ta réference aux inconnus lol
Mais pour revenir su rle sujet, tout à été dit, un developpeur doit controler, comprendre tout ce qui se passe sur tous les niveaux, mais de la à dire que developper dans un editeur de texte tels que notepad prouve qu'on est developpeur , sa c'est la grosse blague du siècle.

[Luc Hermitte]

mais de la à dire que developper dans un editeur de texte tels que notepad prouve qu'on est developpeur , sa c'est la grosse blague du siècle.

Ce qui n'est ni ce dont parle l'article (encore faut-il chercher qui sont ces gens et ce qu'ils utilisent en vrai pour le voir), ni ce que le "camp" "éditeurs" a défendu ici (et ce n'est pas une question d'être "développeur", mais d'être productif)

[hegros]

C'est plus la méthode de travail et les personnes plus que l'outil (éditeur texte ou graphique) qui défini la plus grande part de la productivité d'une équipe ou d'un logiciel en partant du principe que les coûts pour les compétences et outils sont les mêmes.

[hegros]

Entre pré-séquencer/monter une séquence / film, créer des effets, et créer le programme qui effectue les opérations, les besoins ne sont pas les mêmes

Donc vraisemblablement dans 10 ans on fera encore de la 3D en mode texte.. re.

Essaye de programmer un ray-tracing ou une projection ortho-cylindrique uniquement en visuel, ça va être coton

En fait pour la partie graphique j'ai une préférence pour l'écriture en mode texte quand il s'agit de telles spécificités (les états d'impressions aussi par exemple je préfère en mode texte) ensuite pour la construction d'une IHM cela se discute, on peut-être productif avec les 2 car les 2 le permettent techniquement.

Enfin pour faire du prototypage c'est quand même plus pratique d'avoir un éditeur graphique et il n'est pas normal de ne pas faire de prototypage IHM car c'est une des premières spécification qui est faite en début de projet. Mais j'imagine avec emacs/vi on fait des IHM en 2 ou 3 raccourcis claviers ?

Edit : Pour UML je préfére aussi utiliser un éditeur graphique mais avec un éditeur de texte on peut faire pleins d'autres choses comme écrire des xmi

[Zartan]

Le problème que j'ai avec les EDI c'est qu'ils me ralentissent sans arrêt.

Si je tape : <br /> au lieu de "<br />", mon ordinateur se met en veille une dizaine de secondes le temps que l'EDI consulte ses docs... En fait on est forcé de taper son code comme les auteurs l'ont imaginé et pas comme on veut.

Bon après c'est bien sympa les parenthèses qui se ferment toutes seules, la doc de la fonction quand on passe la souris dessus, etc... mais le prix est là quand même.

C'est d'ailleurs comparable avec les programmes de traitement de texte/mise en page : on peut taper son texte au kilomètre dans un éditeur tout simple et puis le mettre en forme après dans un programme Wysiwyg qui va nous signaler chaque faute d'orthographe, ce qui est particulièrement agaçant quand on n'a pas fini de taper son mot.

On peut utiliser les deux donc.

[_skip]

Le problème que j'ai avec les EDI c'est qu'ils me ralentissent sans arrêt.

Si je tape : <br /> au lieu de "<br />", mon ordinateur se met en veille une dizaine de secondes le temps que l'EDI consulte ses docs...

Alors là, soit tu emploies un très mauvais éditeur, soit ton ordinateur est une vieille brouette.

Bon après c'est bien sympa les parenthèses qui se ferment toutes seules, la doc de la fonction quand on passe la souris dessus, etc... mais le prix est là quand même.

C'est vrai, un lookup dans les caches qui prend 100 millisecondes, ça ralentit beaucoup le développeur.
Si tu voulais dire, en consommation mémoire tu as raison mais personellement je trouve que 100-300mo pour un IDE en fonctionnement, c'est loin d'être bloquant.

[Zartan]

Alors là, soit tu emploies un très mauvais éditeur

Non ce n'est pas un éditeur c'est un EDI qui fait 1,846,471,555,684,952 opérations quand je tape un seul caractère. C'est ce que j'explique dans mon message précédent.

Un exemple de ce que fait un EDI et que ne fait pas un éditeur simple, c'est la gestion des TODO et des FIXME : il va parcourir le code à la recherche de ces mots clefs et mettre à jour la liste des tâches.

soit ton ordi est une vieille brouette.

Elle a moins d'un an la brouette, et même quand je tapais du code sur mon VIC 20 ça ne mettait pas 10 secondes à s'afficher.

C'est vrai, un lookup dans les caches qui prend 100 millisecondes, ça ralentit beaucoup le développeur.

Ca n'a rien à voir avec les caches : on utilise un cache quand l'info existe *déjà*. Mais quand il ne trouve rien dans ses caches il cherche *partout*. Et évidemment ne trouve rien ce qui fait que l'ordi se met en veille une dizaine de secondes.

Autre exemple: si je copie colle un gros fichier source, il est susceptible de ramer pendant longtemps car il va vérifier toute la syntaxe, la mettre en forme, la colorier et éventuellement l'indexer, ce qui est normal, et c'est ce qu'on attend d'un EDI, mais pour modifier trois lignes j'espère que vous serez d'accord avec moi qu'un éditeur c'est bien plus simple, et rapide.

[Luc Hermitte]

Bon après c'est bien sympa les parenthèses qui se ferment toutes seules, la doc de la fonction quand on passe la souris dessus, etc... mais le prix est là quand même.

Une fois de plus les "éditeurs de texte" font le premier sans broncher, et le second avec plus ou moins de succès : il faut des gens pour écrire des outils qui savent interpréter le code de langages complexes, et le résultat laisse parfois à désirer.

Un exemple de ce que fait un EDI et que ne fait pas un éditeur simple, c'est la gestion des TODO et des FIXME : il va parcourir le code à la recherche de ces mots clefs et mettre à jour la liste des tâches.

man grep ...
Au pire un plugin pour vim est vite écrit (si ce n'est déjà fait) si en plus tu dois pouvoir maintenir une liste de priorités. Mais pour cela, je préfère encore passer par une forge qui gèrera aussi les anomalies à régler.

[shiro_]

J'ai commence par coder en PHP sous Notepad++ pour ensuite passer sous Eclipse pour apprendre le JAVA. Maintenant je code sous vim en C/Perl/Python/...


Pensez vous que les environnements visuels de programmation soient une mauvaise chose ?
Clairement oui, pour moi les environnements visuels font references aux point-and-click plus qu'a Eclipse. Un integrateur n'est pas un developpeur, et un developpeur doit pouvoir aligner les lignes de codes de facon logique et propres, ce afin de produire un programme concit, maintenable et performant.
Certes, comme certains le soulignent, dans la vraie vie il faut etre productif et un environnement visuel peut donner un rendu qui parrait tres bien. Mais la qualite sous-jacente est mediocre, le client ne le verra jamais, pour moi c'est juste du foutage de gueule.

On va pas restaurer Notre Dame avec un jet d'eau haute pression, meme si c'est plus rapide. Sinon les gens qui sont dans le metier voudront vous assassiner, vous clouer sur une autoroute avec un camouflage couleur bitume (euthanasie ?).

Pour vous, n'est-on programmeur que si l'on sait développer avec un éditeur de texte ?

Oui. Mais pour etre efficace, un vrai editeur est indispensable.
VIm permet d'ouvrir des onglets, c'est ma feature preferee, auto-completion lors de la recherche du fichier a ouvrir, buffer commun a tous les onglets.
Chaque onglet peut etre splitte, dans la partie gauche on met un XML et dans la partie droite on code le parseur par exemple.

Apres le JAVA sous vim j'ai jamais tente, ca me semble un peu galere par contre. J'utilise Eclipse pour le moment, meme si j'en ai raz-le-bol de voir des erreurs alors que je n'ai pas finit de coder le bloc d'instruction.
L'important c'est que les fichiers sources restent lisibles/compatibles avec d'autres IDE et que le projet reste compilable avec des outils tiers.
Pour s'en assurer, il faut savoir compiler a la main et il faut savoir ouvrir un fichier source avec un editeur simple.

J'imagine que vous etes tous plus ou moins passiones par votre boulot, sinon vous ne seriez pas ici. J'ai du mal a comprendre que vous ne cherchiez pas a savoir "comment ca marche" et ce qu'il se passe lorsque vous compilez votre programme puis quand il est execute (interprete pour les moins chanceux ).

[hegros]

J'imagine que vous etes tous plus ou moins passiones par votre boulot, sinon vous ne seriez pas ici. J'ai du mal a comprendre que vous ne cherchiez pas a savoir "comment ca marche" et ce qu'il se passe lorsque vous compilez votre programme puis quand il est execute (interprete pour les moins chanceux ).

Ce n'est pas parce que le développeur utilise un outil visuel qu'il ne comprends rien de ce qui se passe derrière, qu'il ne connaît pas le processus de compilation ou d'exécution, s'il est passé au visuel c'est aussi parce qu'il maîtrise suffisamment ce qui se passe derrière. C'est une question de confort.

En plus savoir ce qui se passe derrière est plus que souvent inutile en production (donc en entreprise) c'est plus souvent d'autres problématiques que la compilation qui sont posées.

Pour moi la productivité c'est l'automatisation des tâches rien à voir avec l'utilisation d'un outil graphique ou textuel à la emacs/vim puisque souvent les 2 le permettent.

[_skip]

Etrangement, presque tous ceux qui utilisent des éditeurs de texte ont tendance à se croire tellement meilleurs que les gens qui utilisent un IDE...

Ca fait peur franchement de constater les clichés qu'on se mange tout au long de ce topic. Juger un outil ou une catégorie d'outils en partant de l'idée que ceux qui les utilisent sont des adeptes de la qualité minimale qui ne cherchent qu'à cacher leur incompétence en faisant travailler des programmes à leur place c'est sûr que c'est très réaliste.