Discussion :

[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 ...).

[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.

[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?

[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 !

[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 !

[SurferIX]

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 .

[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...

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.

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...)

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...)

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...

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...

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 + ^

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 + ^

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 ?

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.

[SurferIX]

SurferIX, as-tu vraiment utilisé Visual Studio ? (une version récente)

Non Donc tu as raison j'ai dit des trucs faux.

Jamais entendu parler des code snippets ?

Ah oui c'est le mot que je cherchais, le terme "à la" commercial. Enfin comme tout le monde dit ça, je suppose qu'il faut que je me mette au diapason .

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...

Oui ici aussi tu as raison : je devrais dire "aucune version de toute l'histoire de VS ne donne cette possiblité", toutes mes excuses.

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)

vim est un moteur, avec une tonne de plugins autour, pas autant que emacs (qui est un tout petit moteur excellent, et qui ne fonctionne que par plugins, si je ne me trompe pas), donc tu as raison.

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 !

Je n'ai jamais dit que tout était de la merde, j'ai juste dit que s'extasier devant des fonctions qui existent déjà depuis des années, voire des dizaines d'années, je trouve ça surprenant, et surtout, au même titre que tout ce que Microsoft essaie de nous faire gober de manière lamentable, ça existe déjà. Et les gens pro Microsoft et qui se sont laissé berner convaincre par eux, et qui proclament que c'est super, je ne peux pas m'empêcher de dire, pour résumer : ça existe depuis très longtemps, et au moins aussi puissant, voire plus.

Au fait, qu'en est-il des fonctionnalités de refactoring dans vim ?

Modifier une variable / et / ou fonction = la modifier partout. Waah le chercher remplacer multi fichier, trop de la balle, ça existe pas sous vim Je te charrie !

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.

Bien sûr. Interaction avec gcc pas native, mais pas loin. Encore une fois : quelques ajouts de modules, et on y est. Boh j'imagine que VS a tout d'origine, y'a rien à faire, on est immédiatement productif. "Monsieur le patron d'entreprise vous serez immédiatement productif vous imaginez le gain d'argent"... Boh ok on payait à l'époque 10000 francs par an pour avoir toujours les docs sur CD de Microsoft, ce qui coûtait très largement plus cher que le temps d'installer quelques plugins à vim , mais je ne sais pas ce qu'il en est aujourd'hui, je suppose qu'il doit y avoir un abonnement à la hotline ou un autre truc de ce genre, en plus des coûts des mises à jour.
Je ne crache pas sur Windows, attention, je crache sur leur politique commerciale où il vendent des choses qui existent déjà ailleurs et au moins aussi bien, en disant que c'est nouveau et que ça n'existe pas ailleurs, c'est ça qui me dégoûte. Je déteste me faire prendre pour un con. De toutes façons tous les commerciaux m'ont toujours dégoûté ("un bon vendeur est un bon menteur"). Et je fais tout pour m'en éloigner, à cause principalement de ça, même si je ne m'en sépare toujours pas encore totalement. On a même été obligés d'acheter Seven pour tester IE9. Encore un autre débat où on a ce dialogue de sourds en boucle :
- "si tu veux pas le tester tu l'achète pas",
- et où je réponds : "mais si je suis obligé vu que je veux voir comment apparaissent mes sites sur IE9, donc je suis implicitement obligé, même si officiellement rien ne me force à le faire" (=> boucle infinie sur le début)

A l'inverse, cite moi quelque chose sous Visual Studio que vim ne peut pas faire

A+

[tomlev]

Modifier une variable / et / ou fonction = la modifier partout. Waah le chercher remplacer multi fichier, trop de la balle, ça existe pas sous vim Je te charrie !

Le refactoring ce n'est pas que ça, ça peut être l'extraction de méthodes dans un classe de base ou une interface, la modification de la signature d'une méthode, etc...
Mais même pour renommer une variable, si tu t'amuses à faire des rechercher/remplacer sur tous les fichiers d'une solution, tu risques d'avoir des mauvaises surprises (il peut très bien y avoir des variables de même nom dans des scopes différents)

A l'inverse, cite moi quelque chose sous Visual Studio que vim ne peut pas faire

Juste un exemple, et là pour le coup je peux sans trop de risque supposer que vim ne le fera jamais : les designer visuels (pour les IHM, data models, etc)
Bon, évidemment c'est lié à la nature de l'éditeur, vim n'ayant pas d'interface graphique à proprement parler... Et si tu codes sous vim c'est probablement pas pour créer des IHM

[TropMDR]

A l'inverse, cite moi quelque chose sous Visual Studio que vim ne peut pas faire

Permettre à un utilisateur qui ne veut pas passer 6 mois à apprendre à se servir d'un éditeur aux racourcis adaptés aux "clavier alpha numériques de l'embarqué" de coder efficacement dès le début ?

On peut pas arrêter 5 minutes d'être des intégristes cinglés ? J'utilise emacs. J'aime emacs. Je suis un peu efficace avec emacs. Quand quelqu'un arrive sous linux et me demande comment il peut éditer ses fichiers de conf, je lui conseille d'utiliser... nano. Au moins il a les racourcis classique directement à l'écran.
Quand un élève commence à faire du java, je l'envoie vers...eclipse. Parce que même s'il ne saura jamais se servir de plus de 2% des fonctionnalités de cette énorme usine à gaz, au moins il aura, sans rien faire, une mise en valeur instantané des erreurs de syntaxe, ainsi que la ligne où une exception a été lancée, etc, etc.

Quand un élève commence à faire du coq et ne connais pas emacs, je l'envoie vers coqide, joli cliquodrome

C'est si difficile de se dire qu'il existe des gens avec une façon de penser différente de la notre, qu'un outil adapté à l'un ne l'est pas forcément à l'autre ? Et on pourrait pas élever le débat un peu plus haut que "avec mon éditeur à moi, j'appuie sur deux touches seulement pou faire ça, alors que toi c'est trois, t'es trop nul mec" ?

Surtout qu'en informatique, il y a quand même pléthore de question technique où l'on peut avoir un véritable débat (parfois même constructif , avec de vrais arguments techniques. Venez, on se concentre un peu là dessus ?

[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...)

[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]

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

[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...

[souviron34]

...
snip
...

J'espère que c'est du second degré



Sinon, tu as beaucoup d'illusions...

[pcdwarf]

Je programme essentiellement en C/C++ sous linux.

Je n'emploie pas de débogueur mais je compile exclusivement avec -Wall.
Généralement, un programme qui compile sans aucun warning mais qui ne fait pas ce qui est attendu révèle un problème de raisonnement et non de codage.

Je n'ai jamais éprouvé le besoin d'utiliser un debogueur ni pris le temps d'apprendre à m'en servir.


Pour donner à manger au troll, j'ai employé vim pendant des années et je l'emploie toujours pour éditer des fichiers distants en ssh mais je lui préfère quand même des éditeurs texte plus graphiques tels que gedit sous linux ou notepad++ sous windows. En revanche, je n'emploie presque jamais d'IDE, généralement excessivement lourds.

[daminetreg]

J'utilise les deux, j'aime bien utiliser gdb avec Kdevelop, avancer ligne par ligne visuellement et faire des petits print avec l'interpreteur de commandes gdb. Je ne fais jamais de breakpoint conditionnel.

J'utilise beaucoup le debugger parce que j'ai tendance à écrire beaucoup de code d'abord et ensuite de corriger point par point ce qui ne va pas. Tout dépend cependant toujours de la situation bien entendu.

Je pense qu'ils ont juste le langage dans le sang, ils comprennent ce que chaque instruction fait exactement, je travaille avec des électroniciens & développeurs qui sont à même de dire ce que chaque ligne de C représente exactement côté asm puis côté hardware au niveau processeur, quel registre est impliqué etc. Je vise cette perfection aussi, mais j'en suis très très loin.

Depuis que j'ai 15 ans quand je suis en vacances, je ne peux pas compiler alors je décompose dans ma tête au bord de la plage toutes les actions que font les programmes que j'écris sur papier. Et quand je rentre je scanne, un coup de ROC ça compile et ça tourne.

Cela met plus de temps mais pour avancer dans ses projets persos c'est sympa au bord de la mer.