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

[Idelways]

17 créateurs de langages de programmation disent ne pas utiliser de débogueurs interactifs
Et vous, comment déboguez-vous ?



« Masterminds of Programming » est un livre à succès qui regroupe un ensemble d'interviews exclusives avec les créateurs de 17 langages de programmation. Parmi eux, les très populaires Bjarne Stroustrup (C++), James Gosling (Java) ou encore Guido van Rossum, le créateur du langage Python, qui vient par ailleurs d'être sacré langage de l'année 2010 par Tiobe.

Les questions posées à ces créateurs portent sur des thèmes variés du monde de la programmation allant de la conception à la concurrence en passant par le débogage... C'est ce dernier point, pourtant ingrat, qui a interpellé un blogueur et développeur Python à la lecture du livre.

Chris McDonough a en effet constaté que tous ces créateurs affirment déboguer en relisant le code ou en insérant de simples instructions "print". La plupart d'entre eux nient, en somme, utiliser un débogueur interactif.

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.

L'autre explication, diront les mauvais esprits, est que ces maitres du développement prennent soin de leur image de développeurs hors-normes.

Il y a certainement un peu des deux.




Et vous ?

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

Source : le blog de Chris McDonough

[Paul TOTH]

je fais les deux, parfois en même temps

notamment je n'utilise jamais les breakpoints conditionnels j'utilise plutôt un test dans le code

Code :

1
2
3
  if Condition then
    ShowMessage('Ici'); // break point sur cette ligne

[Scalap]

Je suis développeur C++/Qt sous LInux et effectivement dans ma boite on code avec vi (gvim pour moi) et nous n'utilisons pas de debugger.
Les printf( qDebug() avec Qt ) sont énormément utilisés
Très rarement, même vraiment très très rarement, je lance un gdb.

Au début cela était étrange de ne pas en utiliser. Surtout que je venais du monde Windows et sous IDE (notamment Visual studio).
Le break point a cette époque était vraiment un ami. Mais bon ! loin des yeux loin du cœur.

[gorgonite]

Envoyé par Idelways

Chris McDonough a en effet constaté que tous ces créateurs affirment déboguer en relisant le code ou en insérant de simples instructions "print". La plupart d'entre eux nient, en somme, utiliser un débogueur interactif.

déjà le niveau moyen des personnes dont il parle est particulièrement élevé, et ils ne se "contentent" pas de savoir utiliser la langage, mais en comprennent les subtilités en terme de sémantique opérationnelle et modèle-mémoire... par ailleurs, ils ont certainement des méthodologies de développement ad-hoc qui intègrent une analyse très poussée des raffinements "sûres", voire de l'analyse statique. du coup il y a certainement moins de bugs déjà dans leur premier jet

[chaplin]

Comment expliquez-vous que ces « masterminds » disent ne pas utiliser des débogueurs interactifs ?
- Parce qu'ils ont beaucoup de pratique.

Les utilisez-vous ou déboguez-vous, vous aussi, « à la main » ?
- Oui, quand on a pas le compilateur sous la main et qu'il faut expliquer soit à son collaborateur, soit au prestataire où il s'est planté.

[el_slapper]

Je programme en COBOL et en VBA. En VBA, j'utilise abondamment le debuggeur. En COBOL, je n'en ai pas, je mets des DISPLAY(équivalent du print) partout. Donc j'alterne entre les deux

Eh bien ça se vaut, à mon sens. Juste, il faut avoir les outils qui vont bien. COBOL sous Z/OS, j'ai déjà vu des débuggeurs, ils sont lourds, délicats à utiliser, alors qu'on peut faire des DISPLAY massifs qui permettent de suivre l'intégralité de l'éxécution d'un coup d'oeil. VBA, c'est l'inverse; le débuggeur permet d'avoir une vision rapide et efficace de la situation, alors que les "traces"(j'ai même oublié comment on fait tellement j'ai trouvé ça faible) sont illisibles.

Ca donne aussi une différence de manière d'appréhender : dans une trace, on a d'un coup l'execution complète, avec tout l'historique. Dans un débuggeur, on vit le moment ou se produit le bug, et on est concentré dessus. Cette différence de philosophie explique, AMHA, pourquoi certaines préfèrent telle ou telle approche.

[Haseo86]

Personnellement je code (ou plutôt j'ai codé :p) principalement en C++, Java et C#, et je n'ai jamais utilisé de déboggeur.

Sans doute la meilleure raison à cela est que je n'ai jamais eu à entreprendre d'énormes projets, et j'ai toujours pu trouver rapidement mes erreurs "à la main".

[MokuJin]

J'ai codé en PHP nous notepad (sans debuggeur donc) et quand j'ai pu avoir un debuggeur digne de ce nom ça a été un vrai bonheur.
J'ai vraiment eu l'impression d'aller plus vite dans mon développement.

Depuis je fait du c# sous visual studio et sans débuggeur ce ne serais tout bonnement pas possible.

J'ai un ami qui fait du delphi, et qui a un niveau nettement supérieur au mien, lui il est plutot sans debuggeur, mais il a toujours fait comme ça.

Je pense sincèrement que ce n'est qu'une question d'habitude et de maitrise.

Envoyé par gorgonite

ils ont certainement des méthodologies de développement ad-hoc qui intègrent une analyse très poussée des raffinements "sûres", voire de l'analyse statique. du coup il y a certainement moins de bugs déjà dans leur premier jet

Je suis carrément d'accord avec toi.

[martopioche]

D'un autre coté, il me semble que c'est Martin Fowler qui qualifiait de temps perdu le temps passé sur le débuggeur. J'utilise très rarement le débuggeur en Java et Python, plus souvent en C++. Mais finalement dans tous les cas, c'est du fait d'une méconnaissance de ce qui se passe. Cette méconnaissance est soit due à mon ignorance de la techno (C++ par exemple), soit à de la reprise de code spaghetti. Si Bjarne Stroustrup parlait de C++, James Gosling de Java et Guido van Rossum de Python ou C, je présume que leur maîtrise de leur tachno est bien suffisante.

[Fabllot]

Allez, je saute à pieds joints dans la mare !

Et bien, moi franchement, je préfère largement débugger avec un bon débuggeur, intégré à un ide. Je pense particulièrement à Visual Studio !

Et je m'explique :

J'ai fait pas mal de C il y a quelques années en débuggant au printf, puis suis passé au C++/Qt intégré à Visual et là j'ai redécouvert la programmation. Les débuggeur et breakpoints permettent un gain de temps considérable sur le débuggage.

Je travail aujourd'hui sur des plateformes type Bada (avec eclipse) où le débuggueur est lamentable, et fait régulièrement du PHP (là c'est pire)... Et je peux vous dire que je regrette énormément un débuggeur digne de ce nom !

[abriotde]

Personellement même si je suis pas un grand programmeur je n'utilise quasiment pas les débogueur car en général ils ne sont pas installé. Pour les utiliser il faut un IDE complet et méticuleusement soigné. Deplus dans 90% des cas on se dit ah oui c'est vrai j'ai pas traité ce cas en relisant le code alors que le déboggeur nous plonge trop dans le cambouis en empêchant de prendre de la hauteur. Le println complète assez bien. Après le débogueur c'est vrai que c'est partique quand c'est au point. (En javascript ils sortent à peine, pour les serveurs d'application web, ils sont inexploitables...) En Java c'est utile, en C l'appli gdb me permet de savoir ou ça plante pour le HTML vive firebug. Mais dans tous les cas (même avec un déboggeur) il arrive q'un println soit plus rapide.

[zarathoustroy]

Bonjour,

Pour ma part, j'utilise le moins possible les débuggers. Simplement parce qu'une fois l'application déployée, ce n'est plus possible de les utiliser. Dans ces cas là, ce sont les logs qui me sauvent. Des logs pertinents (log4j ou similaire) et une relecture du code permettent la plupart du temps de comprendre d'où vient le problème.

Un bug en phase de développement, franchement ce n'est pas très grave et il n'y a pas d'urgence à le corriger... Un bug sur une appli déployé peut avoir des conséquences dramatiques... Et reproduire le bug avec un débugger peut s'avérer extrèmement long et complexe (avec pendant ce temps précieux un utilisateur (très) énervé).

Zarathoustroy

[noOneIsInnocent]

J'avoue que j'ai aussi du mal avec les débuggers. Je préfère les fichiers de logs et avoir une vue d'ensemble de la cinématique

[TheDrev]

je n'utilisait pas de debiggeur jusqu'a l'année dernière, la raison principale est que mes cheres professeurs n'en ont meme pas prononcer le mot pendant mes etudes.
Avec des langages type python.perl.ruby on peut a la limite s'en passer, mais pour trouver d'ou viens un plantage au runtime quand vous programmer en C, il faut plus que des prints

[spidermario]

Avec un langage tel que Haskell et des implémentations comme GHC, le besoin d’utiliser un débogueur est considérablement diminué.

En cas de problème : "ghci youpi.hs", et voilà le module chargé dans la boucle intéractive où vous pouvez tester chaque élément du programme isolément (avec auto-complétion des symboles disponibles ).

Vous pouvez ensuite apporter des modifications au programme dans votre éditeur externe et entrer ":reload", et vos modifications sont prises en compte. Vous pouvez alors tester à nouveau.

[Fabllot]

Envoyé par zarathoustroy

Un bug en phase de développement, franchement ce n'est pas très grave et il n'y a pas d'urgence à le corriger...

Ouah ! Celle là, je la garde dans mes annales et la punaise sur mon bureau !!!

[jblecanard]

Je pense qu'on est d'accord pour centrer le débat sur la phase de développement. Dire qu'on n'utilise pas les débuggueurs parce qu'on ne peut plus s'en servir une fois déployé n'est pas très malin : c'est comme dire je n'achète pas de caisse à outils pour mon garage parce que quand je roule avec ma caisse, si je tombe en panne, je ne peux pas m'en servir -_-. Utiliser un débuggueur ne veut pas dire qu'on se prive de fichiers de logs parce qu'on en a un. L'utilisation n'est pas la même.

Envoyé par spidermario

En cas de problème : "ghci youpi.hs", et voilà le module chargé dans la boucle intéractive où vous pouvez tester chaque élément du programme isolément (avec auto-complétion des symboles disponibles ).:

Pour moi, c'est un débuggueur. Avec une interface peu commune, certes, mais débuggueur quand même.

J'utilise intensivement les débuggueurs et ils me sont très utile.

• L'argument "c'est à cause de la méconnaissance de blabla" n'est pas valable à mes yeux. Quand on découvre un framework et/ou le code de ses collègues, code pas toujours documenté vu le contexte et/ou bugué, un débugueur est extrêmement utile.
• Quand le programme est long à compiler et à se lancer, là ou un printf ou équivalent demande une récompilation, le débuggueur n'en demande pas. Il est utile.
• Lorsqu'il y a des centaines de millier de lignes de code, la pile d'appel est énorme, que le code passe par des callback, une couche composant, etc, et qu'un segfault sort de nulle part, le débuggueur s'arrête dessus. Il est utile.

Le contexte de programmation de ces messieurs est précis et nous ne le connaissons pas. Que développent-ils ? Dans quel contexte ? Et puis il faut se replacer dans notre cadre. Ils n'ont pas besoin de débuggueurs ? Tant mieux pour eux. Moi, ils me font gagner un temps énorme,comparés à l'autre méthode (dont j'ai usé pendant longtemps). Je n'ai pas de raison de m'en priver.

Je pense que ces mecs là n'utilisent pas de débuggueurs pour deux raisons:

• Ils ont une méthode qui leur convient et qui fonctionne (à défaut d'être potentiellement plus lente). Pourquoi changer ?
• Ce genre de type veut savoir comment tout marche précisément. Un débuggueur, c'est compliqué, ça dépend de l'IDE, de la plateforme et ça dénature les optimisations. Donc caca.

[rawsrc]

Bonsoir,

Fabllot :

Je travail aujourd'hui sur des plateformes type Bada (avec eclipse) où le débuggueur est lamentable, et fait régulièrement du PHP (là c'est pire)... Et je peux vous dire que je regrette énormément un débuggeur digne de ce nom !

Pour le PHP je peux t'assurer avoir essayé un paquet d'IDE avec ou sans debug, je me suis fixé sur PHPEd de Nusphere à cause d'ailleurs du debugger intégré. C'est le panard une fois bien configuré.

[Terry-Slipknot]

Personnellement, je debug mes programmes, selon les cas avec gdb ou avec des print.
J'utilise plus les print que gdb car on arrive plus rapidement a voir l'endroit qui pose problème.

[Kelevra]

Quand je code en COBOL, avec IBM PCOM, il n'y a pas de débuggeur !
Il faut placer des DISPLAY, aux points clé de l'application ou du module.

Par contre quand je code en C#, le débuggeur de VS est toujours le bienvenu.

Si le débuggeur est là pourquoi ne pas l'utiliser ?

Quand il n'y en pas, on se débrouille autrement !