17 créateurs de langages de programmation disent ne pas utiliser de débogueurs interactifs

[yan]

Envoyé par gorgonite

ben tu diras ça aux personnes dont il est question dans le post initial... je me demande s'ils en riront

Ils ont de l'humour?
En cherchant Bjarne Stroustrup et debugger je suis tombé sur cette page :
http://www.artima.com/intv/abstreffi2.html

[Guardian]

Envoyé par gorgonite

ben tu diras ça aux personnes dont il est question dans le post initial... je me demande s'ils en riront

Nous en tout cas, on a bien ri

[jokoon]

Honnetement je n'ai jamais vraiment compris l'interet d'un debugger.

Il y a aussi une citation qui dit "un debuger n'enleve pas les bug, il les fait defiler au ralenti"

Je crois pas que ces gens qui inventent des languages ont "plus de stack" ou quelque chose dans le genre.

C'est peut etre parce que j'ai appris a programmer sous linux avec la ligne de commande, mais meme, je trouve plus sense d'afficher des valeurs et des messages dans une console plutot que d'afficher tout ce qui s'est passe dans un programme, et de laisser le programmeur regarder le programme "au ralenti".

Et je trouve meme beaucoup plus pertinent de bien penser son code, meme si evidemment il est plus pertinent de relire son code que d'utiliser un debugger.

En revanche, un individu aura toujours du mal a relire le code d'un autre, donc je vois mal comment un programmeur ne pourrait pas relire son propre code.

[jblecanard]

Envoyé par jokoon

Honnetement je n'ai jamais vraiment compris l'interet d'un debugger.

Il y a aussi une citation qui dit "un debuger n'enleve pas les bug, il les fait defiler au ralenti"

[...]

C'est peut etre parce que j'ai appris a programmer sous linux avec la ligne de commande, mais meme, je trouve plus sense d'afficher des valeurs et des messages dans une console plutot que d'afficher tout ce qui s'est passe dans un programme, et de laisser le programmeur regarder le programme "au ralenti".

Ce n'est aucunement une critique, mais ça prouve que tu n'as jamais vraiment utilisé de débugger. Le programme ne tourne pas "au ralenti". Il ne s'arrête sur des breakpoints que si tu le demandes. La plupart du temps, celà revient exactement au même que de faire défiler des valeurs, à ceci près que tu n'as pas besoin d'ajouter des instructions dans ton code, et que tu peux faire des "pauses" sans utiliser des instructions système dégueu.

Un débugger permet de filtrer, extraire et classe des informations dont on peut avoir besoin, il ne te balance pas une pâtée immangeable (à moins de ne pas savoir s'en servir). Bien sûr qu'il ne corrige pas les bugs puisqu'il ne modifie pas le code ! C'est un outil de diagnostic.

J'ai aussi appris sur linux en ligne de commande. Si ça peut t'encourager à essayer...

Envoyé par jokoon

meme si evidemment il est plus pertinent de relire son code que d'utiliser un debugger.

L'utilisation d'un debuggeur inclus la relecture de ton code. Tu le vois s'exécuter, c'est une relecture enrichie, et en aucun cas appauvrie.

Globalement, je pense qu'il est difficile de désavouer les débuggers si on n'a pas un minimum d'expérience avec.

[Chatanga]

Indépendamment de l'intérêt plus ou moins marqué qu'on peut trouver à un debuggeur, je ne vois pas comment certains font pour s'en passer complètement (ou bien ils exagèrent pour forcer le trait). Par exemple, dans le cas d'une bibliothèque tierce, on peut évidemment lire son code mais je me vois mal y ajouter des "printf" et la recompiler. Je ne prendrais d'ailleurs même pas cette peine pour explorer un bug dans le code d'un module maison mais dont le projet n'est pas ouvert sous mon EDI. Dans un tel contexte et pour un besoin aussi basique, je vois mal comment on peut se détourner d'un debuggeur (à part s'il est vraiment mal intégré à son EDI).

Envoyé par jokoon

Honnetement je n'ai jamais vraiment compris l'interet d'un debugger.

Il y a aussi une citation qui dit "un debuger n'enleve pas les bug, il les fait defiler au ralenti"

Pour moi, c'est justement l'intérêt d'un débuggeur. Non pas corriger magiquement un code évidemment, mais pouvoir le faire tourner au ralenti, avec la touche pause et la capacité de faire l'équivalent de tas de "printf" dans tous les sens. Ca n'est pas miraculeux mais c'est quand même plus simple de comprendre un mécanisme qu'on ne comprend pas en le regardant fonctionner, non ? Plus simple que de partir des seuls résultats en sortie et son plan de construction. Bien-sûr, une fois qu'on sais précisément comment tourne (ou plutôt devrait) un code, le débuggeur devient parfois encombrant.

[remi.a]

Je trouve cela étonnant, en tout cas pour les langages compilés. Je crois qu'ici un paramètre important est le temps de compilation. Lorsqu'on est en phase de débogage, et qu'on aimerait connaitre le contenu d'une variable qui n'est pas dans notre ligne de printf, hé ben, il faut recompiler, et ça peut parfois être un peu long... Avec un IDE + debug, suffit d'un break et faire un hoovering sur la variable en question. Pratique.

De plus le contexte générant un bug peut être parfois difficilement reproductible, surtout lorsqu'on travaille sur un prog multithread. Avec un débogueur, lorsque le bug apparaît, on pause, on navigue dans les piles et on accède à l'état des variables et on arrive généralement à comprendre ce qui se passe. Et sans recompiler, j'appelle cela un gain de temps.

C'est sur que si je codais un truc bien de base, comme un container de la lib standard ou les fonctions bas niveau d'une classe de maillage en half-edge, je baserais le code sur la théorie et j'aurais de gros scrupules à utiliser un débogueur. Car dans ces cas rien ne doit être fait à la légère, chaque contexte d'utilisation doit être étudié et cela doit fonctionner point barre.

Mais la plupart du temps, étudier exhaustivement les cas d'évolutions possibles d'un très gros morceau de code est du domaine de l'impossible et serait de toutes manière contre productif. Il y a donc forcément des choses auxquelles on ne pense pas, et ça plante parfois. En fait, on vit dans le désir de faire du beau code tout beau tout parfais mais la dead line nous remet trop souvent les idées en place. Il y a malheureusement un compromis à faire. La réalité est parfois un peu triste j'en conviens.

[mteirek_m]

Dans Delphi :
if condition then begin showmessage('condition'); end;

Dans les autres languages idem (print, etc ...).

[SurferIX]

... Mais attendez, moi, quelque chose me choque : si ces gens créent des langages, comment voulez vous qu'ils utilisent des débogueurs sur des langages qu'ils créent, puisque par définition même il ne peut pas y avoir de débogueurs existants pour ces langages ? ...

Sinon c'est évident qu'on va plus vite avec un débogueur que sans. C'est juste le contexte. Moi aussi je suis sous vim et je fais du trace à la "echo", mais sous Delphi, je vais toujours sans exagérer, presque 4 à 5 fois plus vite. Par contre, c'est indéniable, on réfléchit bien plus sans débogueur, parce que, justement, comme c'est plus long à déboguer à la main, on fait plus attention. Sous Delphi, c'est genre je fais mon code, je mets un breakpoint là où il faut, et je lance, on verra bien en mode pas à pas si tout est ok. En Php, je relis bien deux fois mon code avant de lancer, et je fais bien sûr moins d'erreurs en Php (idem pour Python).

[Vil'Coyote]

lorsque je développais en c/c++ le debugger était obligatoire.

Depuis que je suis sous php et ce depuis quelques année maintenant je ne disposais pas de debugger donc j'ai appris à m'en passer. Depuis quelques année j'utilise zend studio qui dispose d'un debugger mais malheureusement j'ai tellement pris le plis que je ne m'en sert jamais.

[iznogoudmc]

Comment expliquez-vous que ces « masterminds » disent ne pas utiliser des débogueurs interactifs ?
Les utilisez-vous ou déboguez-vous, vous aussi, « à la main » ?


J'ai commencé à programmer en C avec comme seul débogueur "adb" qui ne me permettait que d'analyser succinctement un dump..... Ceci m'a donné l'habitude de mettre aussi des "printf" pour savoir ce qui se passe et surtout de tester mon code le plus souvent possible, pour ainsi dire à chaque fonction.... un peu ce qu'on appelle aujourd'hui du développement piloté par les tests, mis à la mode par pas mal de méthodes dites "agiles", comme l'eXtreme Programming.
Et franchement je trouve cela beaucoup plus efficace que de pondre un gros plat de spaghettis et d'utiliser un débogueur intéractif !

[Eulmich]

Un debugger est pour moi un outil indispensable dans la trousse à outil du développeur.

Quand j'étais encore étudiant, je me contentais de débugger à coup de printf et autres sysout. C'est une mauvaise solution dans un contexte pro car on pollue son programme et on risque bien de laisser un jour quelques unes de ces lignes inutiles en production.
Puis j'ai découvert les systèmes de log, ce qui m'a permis d'avoir des sorties diverses pour les informations de mes programmes. Mais une fois de plus, l'usage n'est pas le même qu'un débugger : les logs permettent l'identification des problèmes et de l'éxécution d'un programme en production.

Ensuite, j'ai découvert le débugger en Java, puis en PHP, qui s'intègrent très bien à Eclipse. Quelle facilité de simplement mettre un point d'arrêt dans le programme, de pouvoir examiner la stack trace, de faire du pas à pas dans l'exécution, etc. Et tout ça sans polluer son code!

Enfin, ma dernière étape a été la découverte des tests unitaires et du TDD : en vérifiant mon code avant de l'écrire, j'ai tout simplement beaucoup de bugs. Mes tests me servent de garde-fou et bien souvent lorsque j'ai un bug en phase de développement, je l'identifie immédiatement en relisant le test associé.

Mais je garde le debugger sous la main pour les interventions en mode pompier : bug plutôt complexe, code que je n'ai pas écrit, application gigantestque, etc...

Finalement, pour moi tout ça est une question de productivité des développements : il faut savoir s'outiller en fonction de la situation.

Pour revenir au sujet initial, j'ai plusieurs suppositions pour expliquer que les créateurs de ces langages n'utilisent pas de debugger:

• ce sont vraiment des cracks
• ils sont vraiment de la "vieille" école
• ils n'ont pas vraiment suivi les évolutions qui vont autour des langages eux-mêmes
• peut-être qu'ils n'interviennent pas sur des projets de dev de très grande ampleur?

[parrot]

Les créateurs mentionnés ici ont créé ces langages il y a pas mal de temps. Avant l'arrivée d' EDI efficaces, équipés de débogueurs interactifs. Ils ont peut être fait une religion du débogage au printf.

Je pense que l'utilisation d'un débogueur devient d'autant plus utile que le bogue est complexe. Ainsi, corriger le dépassement d'index d'un vecteur ne nécessite pas de dégogueur. Dans ces cas-là, le message de l'exception est suffisamment explicite. Mes tests unitaires (dans l'esprit TDD) se chargent de mettre au jour ces bogues-là, et je n'y utilise que rarement le débogueur.

Par contre, il est des erreurs plus complexes, soit parce qu'elles proviennent de données complexes ou mal connues, ou parce que le cheminement dans le code n'est pas évident. Dans des cas comme ceux-là, un débogueur est vraiment utile. On arrive à vérifier plusieurs hypothèses, en accédant à plusieurs variables, en avançant pas à pas dans le code. Avec des println (ou son équivalent printf), soit on ne met pas assez de sorties, ou pas au bon endroit, et il faut en rajouter et relancer un cycle de compilation, soit on en met trop, et on se noie sous le nombre!

Ceci dit, les problèmes de concurrence sont quelque fois impossibles à reproduire avec un débogueur. Là, il ne reste plus que les println! Et encore, il m'est arrivé de ne pas pouvoir reproduire une erreur après avoir inséré un println!

[MiniCesc]

J'avoue que je ne pourrais sans doute pas me passer d'un IDE. Mais ce ne serait sans doute pas pour le coté débogueur mais plus pour l'auto-complétion. Visual Studio est énorme pour ça.
Franchement, trouver les noms de classes et namespace sans cela serait vraiment trop galère. Notamment quand on trouve du code sur la toile, qu'il n'y a pas forcément tous les "includes" et que VS les retrouve tout seul... c'est le pied. J'ai refait un peu de Java l'autre jour avec Eclipse... beurk !

[philou06000]

Dans certain cas (type d'application) le lancement du débogueur, et / ou le placement d'un point d'arret, est trop intrusif, et il est necessaire de creer soit une trace fichier, soit trace console activé sur option (d'autant plus qu'en production celà peut aussi identifier des problemes de haut niveau, en cas de crach).
Par contre, il me semble vital de faire au moins une fois la vérification, avec le débogueur de la non existance de memory leaks, sur fermeture de l'application. (quand je vois le nombre de devellopeur qui laisse ce genre de bogue, j'ai les cheveux qui frisent...)

[SurferIX]

Envoyé par MiniCesc

J'avoue que je ne pourrais sans doute pas me passer d'un IDE. Mais ce ne serait sans doute pas pour le coté débogueur mais plus pour l'auto-complétion. Visual Studio est énorme pour ça.
Franchement, trouver les noms de classes et namespace sans cela serait vraiment trop galère. Notamment quand on trouve du code sur la toile, qu'il n'y a pas forcément tous les "includes" et que VS les retrouve tout seul... c'est le pied. J'ai refait un peu de Java l'autre jour avec Eclipse... beurk !

Allez le bon gros "Lolilol" des familles : ne pas se passer d'un environnement principalement pour l'auto complétion ? vim a ça intégré depuis oh disons... euh... vingt ans ? Peut être plus ? (ctrl "p"). Et des fonctions d'auto complétion ultra avancées : soit tu définis un répertoire dans tes préférences, et il prend en compte toutes les variables de tous les fichiers de ce répertoire pour l'auto complétion, et tu peux évidemment afficher les variables avec l'aide, et j'en passe et des meilleures (ctrl "n" ctrl "p" pour une complétion plus spécifique) etc.
Bien sûr quand tu parle des namespace etc si tu configure, pour vim, l'aide de Php, en quelques minutes tu as en Php ce que tu as sous Visual Studio. Mais c'est sûr y'a pas les zolies bordures des fenêtres Windows (je te charrie).

Ah non, Visual Studio ne peut pas, en deux touches, enregistrer de macros (q[touche de 'a' à 'z' pour la macro 'a' à 'z'])... euh peut être mais il ne peut pas, en deux touches, la rejouer (@[touche de 'a' à 'z' pour rejouer la macro 'a' à 'z'])... ou enregistrer et rejouer jusqu'à 26 macros facilement... je ne sais pas... et X fois, n'en parlons pas.... ([nombre]@['a' à 'z'] = jouer [nombre] fois la macro ['a' à 'z'])

Ah non, Visual Studio ne peut pas, en une touche, aller chercher l'occurence suivante du mot sur lequel tu es...

Ah non, Visual Studio ne peut pas, en une touche, aller chercher l'occurence précédente du mot sur lequel tu es...

Ah non, il est impossible sous Visual Studio de faire des rechercher / remplacer extrêmement complexes (expressions régulières avancées, je parle pas des regexp de base destinées au Marcel moyen) (voir vimgolf ou les types se donnent des challenges tout simplement impossibles (peut être que je me trompe) à réaliser sous Visual Studio)

Euh il est impossible sous Visual Studio de rejouer en une seule touche la même séquence d'édition du texte ("." sous vim). Encore pire en X fois ([nombre]"." sous vim pour le faire [nombre] fois)

Euh il est impossible sous Visual Studio de sélectionner en trois touches tout un texte entre guillemets quelque soit la position du curseur dans le texte (vi" pour sélectionner sans les guillemets, va" pour sélectionner avec les guillemets)

Euh il est impossible sous Visual Studio de sélectionner en trois touches tout un paragraphe selon l'ouverture/fermeture d'un bloc (vi{ pour sélectionner sans les crochets, tout le bloc, va{ pour sélectionner avec les crochets, même chose pour les parenthèses "vi(" et "va(" )

Euh il est impossible sous Visual Studio d'aller d'une parenthèse ou accolade ouvrante/fermante à l'autre en une seule touche (% sous vim)

Plus fort de chez fort : à n'importe quel endroit dans une fonction, si tu est dans un "if {}" en plein milieu des accolades, tu tapes "v2a{" alors tu lui dit "sélectionne ce qu'il y a entre crochets deux crans en arrière, crochets inclus". Et il te sélectionne le code complet de ta fonction. Tu fais "v3a{" il te sélectionne toute ta classe. C'est tout bonnement impossible à faire sous VS.

Et je ne parle pas des patterns, ou, sous vim, lorsque tu tapes un mot clé, pof il te joue toute une macro. Exemple concret de quelqu'un qui a bien configuré vim ? Il tape xml et hop ! Tout le squelette d'un fichier xml 1.0 strict + le bon positionnement + toujours pareil, dès qu'il commence à taper une balise connue, hop => application d'un pattern (href => "<a href=""></a>") etc. Bref on a un intervenant qui nous a crée une page html en, sans éxagérer moins de 2 secondes, puis, avec les liens qu'on lui demandait "à la volée", il a rempli la page aussi vite qu'on demandait les liens. Comme quoi quand on connait vim, et qu'on le configure bien, on arrive vraiment à faire tout ce que les environnement actuels hurlent comme étant des "nouveautés jamais vues" .

Je m'arrête là, j'ai à peine effleuré tout ce que tu peux faire avec un logiciel qui a plus de trente ans d'âge, et que tu ne pourras JAMAIS faire sous Visual Studio. Les créateurs de Visual Studio n'étaient même pas encore nés que vim existait déjà, c'est pour ça peut-être qu'ils croient inventer des choses nouvelles alors que ça existe déjà ?

Dernière cerise sur le gâteau : tu ne pourras jamais, absolument JAMAIS éditer un texte en entier uniquement avec un clavier alphanumérique (comme on en a souvent dans les systèmes embarqués) sans les flèches et autres "home insert fin pgup pg down") sous VS, alors que sous vim, c'est galette. Pour peu qu'on se force à gérer un peu les touches hjkl.

Ne m'en veut pas, mais franchement vim, faut y consacrer un peu de temps et après... bah on a un autre outil en main, et il me sert très souvent même pour des choses assez futiles (dernière en date : plus de 300 fichiers avec des commentaires en bas qu'il fallait remonter en début de page, sachant que les commentaires pouvaient tous commencer de façon différente (j'entrerai pas dans les détails)) : temps pris : 5 minutes. Mon chef de projet avait planifié deux heures .

[Xitog]

McDonough, qui avoue humblement ne pas faire le poids devant ces gourous du développement, s'étonne tout de même qu'ils n'utilisent pas les débogueurs interactifs, pourtant pratiques et qui lui « sauvent la mise à chaque fois ». Il affirme même que de ne pas les avoir serait pour lui « terrible ».

Une explication possible, d'après McDonough, serait que ces esprits supérieurs de la programmation ont plus de "stack space" dans leur cerveau qui peuvent contenir plus de code que ceux des programmeurs qui utilisent les débogueurs.

Mais qu'est ce qui ne faut pas lire ! Bon allez, je vais parier sur un second degré mais quand même... Les "esprits supérieurs" devant lequel il faut être "humble", il y en a (Einstein me vient à l'esprit) mais c'est très très rare. Il n'y a pas cette déférence infecte à avoir devant des gars qui ont réalisé un langage de programmation, surtout qu'avec le temps, cela devient de plus en plus facile (à lex et yacc ont succédé xtext et autres plugins eclipses qui vous génèrent jusqu'à l'éditeur pour votre langage !!!).

Non, le vrai coup de chapeau c'est à adresser aux communautés respectives. Vous pouvez avoir le meilleur langage au monde (et Python n'est qu'un langage (=outils) parmi d'autres, plutôt mal foutu avec ces erreurs "invisibles" lorsque les éditeurs nous mixent l'indentation) sans la communauté pour faire les packages autours, ce n'est rien.

Alors oui, je m'incline devant Jex0023 et Bob27, devant Zembla96 et Seymour28, devant tous ces "petits gens" dans l'ombre des "idoles" qui ont contribué, par leurs commits, leurs patches et leurs ajouts à la création d'outils puissants.

Mais sincèrement, il y'en a qui ont la béatification facile. Vous voulez pas vous prosternez non plus ?

[souviron34]

Envoyé par Xitog

Mais sincèrement, il y'en a qui ont la béatification facile. Vous voulez pas vous prosternez non plus ?

Je ne sais pas si ton second degré sera compris

Mais j'ajouterais que la plupart des remarques du style que tu cites sont le fait de personnes ayant peu développé...

Quand on en est à plus de 10 millions de lignes de code écrites dans sa carrière, ce qui est le cas des personnes mentionnées et de tout un tas d'autres sur ce forum et dans le monde informatique en général, comme je l'ai mentionné plus haut, quelque soit le langage, bien entendu un debugger est utile de temps en temps, mais l'écrasante majorité du temps on sait non seulement où chercher, mais aussi quoi.. D'où l'intérêt et la rapidité du printf..

Quant aux arguments de "temps de compil", ils passent à la trappe justement pour les très gros logiciels, pour lesquels le temps de "step by step" ou le temps de se trouver proprement (et clairement) au bon endroit est bien supérieur même à 10 ou 20 min de compilation...


En bref, l'usage du débuggeur décroît avec l'expérience..

[sjrd]

Aaaah le débogage !

En fait moi ça dépend beaucoup du langage que j'utilise, et du support au niveau débogueur interactif qui existe pour ce langage. Exemples extrêmes : PHP, vive le "echo" ; Delphi, vive le débogueur interactif

Quant à savoir pourquoi ces grands noms disent ne pas en utiliser, je parierais personnellement plus sur la fameuse image de marque. La connaissance du langage et leurs capacités sans doute surhumaines doivent jouer ; cependant j'ose prétendre que je maîtrise le Delphi (j'ai écrit un compilo Delphi, quand même), ce qui ne m'empêche pas d'utiliser fréquemment le débogueur interactif quand je code en Delphi.

D'après moi, il y a aussi un autre facteur : la qualité des stack trace en cas d'exception fatale.
Sous Java ou Python par exemple, la qualité des stack trace est telle que j'ai rarement besoin d'invoquer quelque sorte de débogage que ce soit (ni interactif, ni print) : je trouve l'erreur directement. C'est d'autant plus vrai si le code est organisé correctement.
En C par contre, je commence par faire une analyse statique, comme certains ont dit, et si je ne trouve pas comme ça, je fais une recherche dichotomique à base de printf

[tomlev]

SurferIX, as-tu vraiment utilisé Visual Studio ? (une version récente)
Au moins la moitié de tes affirmations sont fausses

Concernant l'autocomplétion, VS fait tous ce que tu dis, sauf qu'il n'y a rien à configurer, ça fonctionne tout seul directement...

Envoyé par SurferIX

Ah non, Visual Studio ne peut pas, en deux touches, enregistrer de macros (q[touche de 'a' à 'z' pour la macro 'a' à 'z'])... euh peut être mais il ne peut pas, en deux touches, la rejouer (@[touche de 'a' à 'z' pour rejouer la macro 'a' à 'z'])... ou enregistrer et rejouer jusqu'à 26 macros facilement... je ne sais pas... et X fois, n'en parlons pas.... ([nombre]@['a' à 'z'] = jouer [nombre] fois la macro ['a' à 'z'])

Tu peux enregister des macros via des raccourcis clavier, et affecter une raccourci aux macros que tu veux... Mais bon, perso je connais pas grand monde qui utilise les macros dans VS, il y a d'autres fonctionnalités qui les remplacent avantageusement.

Envoyé par SurferIX

Ah non, Visual Studio ne peut pas, en une touche, aller chercher l'occurence suivante du mot sur lequel tu es...

Non, c'est vrai, il faut 2 touches... Ctrl+F3 (mais tu peux toujours modifier ce raccourci pour utiliser une seule touche...)

Envoyé par SurferIX

Ah non, Visual Studio ne peut pas, en une touche, aller chercher l'occurence précédente du mot sur lequel tu es...

Ctrl+Shift+F3 (mais tu peux toujours modifier ce raccourci pour utiliser une seule touche...)

Envoyé par SurferIX

Ah non, il est impossible sous Visual Studio de faire des rechercher / remplacer extrêmement complexes (expressions régulières avancées, je parle pas des regexp de base destinées au Marcel moyen) (voir vimgolf ou les types se donnent des challenges tout simplement impossibles (peut être que je me trompe) à réaliser sous Visual Studio)

La fonction rechercher/remplacer fonctionne avec les regex, tu peux faire des trucs à peu près aussi avancés que tu veux...

Envoyé par SurferIX

Euh il est impossible sous Visual Studio de rejouer en une seule touche la même séquence d'édition du texte ("." sous vim). Encore pire en X fois ([nombre]"." sous vim pour le faire [nombre] fois)

Tu peux faire la même modification sur plusieurs lignes de code à la fois. Je ne vois pas vraiment quels sont les autres cas d'utilisations auxquels tu penses...

Envoyé par SurferIX

Euh il est impossible sous Visual Studio de sélectionner en trois touches tout un paragraphe selon l'ouverture/fermeture d'un bloc (vi{ pour sélectionner sans les crochets, tout le bloc, va{ pour sélectionner avec les crochets, même chose pour les parenthèses "vi(" et "va(" )

Ctrl + Shift + ^

Envoyé par SurferIX

Euh il est impossible sous Visual Studio d'aller d'une parenthèse ou accolade ouvrante/fermante à l'autre en une seule touche (% sous vim)

Ctrl + ^

Envoyé par SurferIX

Et je ne parle pas des patterns, ou, sous vim, lorsque tu tapes un mot clé, pof il te joue toute une macro. Exemple concret de quelqu'un qui a bien configuré vim ? Il tape xml et hop ! Tout le squelette d'un fichier xml 1.0 strict + le bon positionnement + toujours pareil, dès qu'il commence à taper une balise connue, hop => application d'un pattern (href => "<a href=""></a>") etc. Bref on a un intervenant qui nous a crée une page html en, sans éxagérer moins de 2 secondes, puis, avec les liens qu'on lui demandait "à la volée", il a rempli la page aussi vite qu'on demandait les liens.

Jamais entendu parler des code snippets ?

Envoyé par SurferIX

Dernière cerise sur le gâteau : tu ne pourras jamais, absolument JAMAIS éditer un texte en entier uniquement avec un clavier alphanumérique (comme on en a souvent dans les systèmes embarqués) sans les flèches et autres "home insert fin pgup pg down") sous VS, alors que sous vim, c'est galette. Pour peu qu'on se force à gérer un peu les touches hjkl.

C'est vrai que ça m'arrive tous les jours de développer sur un clavier comme ça... D'ailleurs, comment peux-tu affirmer qu'on ne pourra JAMAIS le faire ? Tu en as discuté avec les équipes qui développent VS, et ils t'ont dit qu'ils ne le feraient jamais ? Même si effectivement ils ne le feront sans doute jamais, c'est juste une supposition de ta part, alors ne la présente pas comme une vérité absolue...

D'ailleurs, il est possible d'installer des plugins dans VS pour combler les manques éventuels de l'IDE. Est-ce possible sous vim ? (je suppose que oui, car contrairement à toi je n'ai pas de préjugés négatifs sur les outils que je ne connais pas bien)

Alors oui, bien sûr que vim est un excellent outil, je l'ai moi-même utilisé avec plaisir quand je développais sous UNIX (sans arriver au niveau de maitrise que tu sembles avoir...), mais ça ne veut pas dire que tout le reste est forcément de la merde... Evite donc de faire ce genre d'affirmation sur des trucs que tu ne connais visiblement pas !

Au fait, qu'en est-il des fonctionnalités de refactoring dans vim ? Et pour revenir au sujet de départ, peux-tu utiliser le debugger directement dans vim, en surlignant la ligne en cours d'exécution, en modifiant le code à la volée sans avoir à recompiler pour continuer ?... Bref, vim est un excellent éditeur, mais c'est juste un éditeur... ce n'est pas vraiment comparable avec un IDE complet.

[Jay13mhsc]

Vous croyez vraiment au mythe de "j'ai un gros cerveau, donc tout ce que je code fonctionne sans test" ?
En fait le problème c'est que c'est la mentalité du développeur moyen, qui, une fois qu'il se barre, laisse un merdier qu'on est obligé de réécrire...

Sinon les vrais gros cerveaux (et j'ai entendu parler de Martin Fowler, Bjarne Stroustrup, etc.), faut pas rêver les gars ! Ils ne font que du test unitaire ! Et du TDD qui plus est ! Et quand on fait du TDD à outrance, on se rend compte a posteriori que le débugueur est inutile...

Je vous invite à lire le bouquin de Kent Beck sur le TDD (l'un des "fondateurs" d'XP et signataire du manifeste Agile).
Cela apporte BEAUCOUP d'humilité, et ça tord le coup à l'idée reçue qu'écrire un test unitaire est plus coûteux en temps ! C'est FAUX ! Ce n'est qu'un argument de développeur frustré qui a l'impression qu'on veut le fliquer, et qui a surtout peur de montrer que son code ne marche pas, ou pire, ne sert à rien !

Encore une fois, si on utilise des langages et des plateformes de haut niveau, avec un haut niveau d'abstraction et des langages avec des termes en anglais (bizarrement...) c'est pas pour écrire du code que seule la machine et le mec qui l'a écrit comprennent. C'est pour que le plus grand nombre de personnes puissent lire et comprendre le code très rapidement. Donc finies les méthodes de plus de 10 lignes (et encore c'est beaucoup trop !) et le nommage à la con, genre _ptdcs ! Et les tests unitaires concourent à écrire du code de meilleure qualité (pour qu'il soit testable), et s'assurer qu'un gus comprennent les cas d'utilisation et ne viennent pas tout casser en voulant modifier un truc...