IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

17 créateurs de langages de programmation disent ne pas utiliser de débogueurs
Comment déboguez-vous ?

Le , par Idelways

249PARTAGES

6  3 
« 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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de jblecanard
Membre expert https://www.developpez.com
Le 21/01/2011 à 18:28
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.

Citation Envoyé par spidermario Voir le message
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.
14  1 
Avatar de Fabllot
Membre éclairé https://www.developpez.com
Le 21/01/2011 à 17:55
Citation Envoyé par zarathoustroy Voir le message
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 !!!
13  3 
Avatar de jblecanard
Membre expert https://www.developpez.com
Le 25/01/2011 à 15:38
Citation Envoyé par jokoon Voir le message
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...

Citation Envoyé par jokoon Voir le message
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.
11  1 
Avatar de TropMDR
Membre éprouvé https://www.developpez.com
Le 26/01/2011 à 14:16
Citation Envoyé par SurferIX Voir le message

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 ?
13  3 
Avatar de TropMDR
Membre éprouvé https://www.developpez.com
Le 22/01/2011 à 14:41
Citation Envoyé par tulipebleu Voir le message
Il me semble que s'ils ne développent pas avec un débogueur, c'est :
...
-soit parce qu'ils sont fermés dans leur esprit, et ne veulent pas progresser en utilisant un outils complexe. Ils ont un blocage purement idéologique.
Effectivement, ne trouver comme seul explication à la question "pourquoi ne fait-il pas comme moi" que "c'est parce qu'il est fermé dans son esprit", c'est une bonne preuve d'ouverture du tiens ! Surtout face à des gens qui font évoluer l'informatique en créant de petits langages, comme C++ par exemple...
8  1 
Avatar de jblecanard
Membre expert https://www.developpez.com
Le 26/01/2011 à 14:30
Citation Envoyé par SurferIX Voir le message
[...]Ne m'en veut pas, mais franchement vim, faut y consacrer un peu de temps et après...
Hou le bon gros troll !

J'ai utilisé VIM par le passé, et j'ai fait l'effort, des raccourcis, macros, etc. Et je peux vous le dire d'emblée, la vieille école "VIM c'est plus puissant qu'un IDE", c'est une vraie connerie. La preuve SurferIX: tu t'es lancé dans une diatribe sans connaître Visual Studio.

Les raisons sont multiples:
- VIM n'est pas multiplateforme bien qu'il le prétende, l'implémentation windows est naze (et je sais de quoi je parle, j'ai essayé). VS ne prétend pas être multiplateforme, et Eclipse + CMake font des merveilles en C++ sur Linux.
- VIM est un éditeur de texte. Les macros ne font pas tout : un IDE fournit aussi un environnement visuel qui permet de naviguer aisément dans les arcanes du projet, de ne pas avoir à switcher de fenêtres pour maintes opérations etc.
- Le langage de macros de VIM n'a rien d'intuitif et l'apprendre et l'exploiter n'est pas une gageure.
- Il faut le configurer, alors que les IDE fournissent ça de base. On change de machine ? On n'a plus sa config. Pratique dis donc !
- L'auto-complétion, quelle blague ! Elle est ridicule comparée à la richesse de l'auto complétion de VS ou d'Eclipse, non pas à cause d'un manque de qualité de VIM, mais parce que VIM est en console et que ça limite d'emblée beaucoup de possibilités visuelles.
- Parlons donc de débugguer dans une fenêtre VIM (puisque c'est le sujet). Une partie de plaisir...

Je ne dis PAS que VIM c'est le mal, mais il faut arrêter de dire "y a rien de plus puissant", c'est de la propagande.

Citation Envoyé par SurferIX Voir le message
(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 .
Un script bash ou python, ou une instance de VIM pour l'occasion, bien sûr ! Mais ce n'est pas suffisant pour le consacrer à un usage auquel il n'est pas destiné. C'est un cas trop ponctuel.

Conclusion par rapport au débat (car mon but n'est pas de nourrir le troll ) : il y a des tas d'outils, et chacun sont puissants pour des utilisations données. L'outil magique qui fait tout et qui est mieux que les autres pour tout, si ça existait, ça se saurait !

Edit : Cross post avec celui de TropMDR, auquel j'adhère à 100%.
8  1 
Avatar de gorgonite
Rédacteur/Modérateur https://www.developpez.com
Le 21/01/2011 à 14:40
Citation Envoyé par Idelways Voir le message
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
8  2 
Avatar de TropMDR
Membre éprouvé https://www.developpez.com
Le 02/02/2011 à 14:17
Citation Envoyé par super_bus Voir le message

Réponse à TropMDR :
[...]
b) Je crois que vous confondez l'écriture d'un programme et sa mise au point. Une telle erreur en C ne nécessite pas un débogueur. L'anomalie détectée lors de l'exécution, vous savez automatiquement la nature de cette erreur.
Euh non, un dépassement de tampon ou un double free, justement, on ne sait pas "automatiquement la nature de cette erreur". Et même si on sait que c'est un double free, dans un programme de 10 000 lignes, 100 000 lignes, ou encore plus, ça ne veut pas pour autant dire qu'on sait où il se trouve...

Citation Envoyé par super_bus Voir le message
d) Je crois que vous n'avez pas une grande expérience dans la recherche des anomalies.
Je l'admet, puisque quand je prouve mes programmes, quand il y a un problème, je vois exactement où il se trouve.

Citation Envoyé par super_bus Voir le message
Il arrive qu'une erreur est détectée à un endroit précis du programme mais que la cause est ailleurs.
D'où l'intérêt du débuger et de sa pile d'appel, voir même de sa capacité à remonter dans le temps !

Citation Envoyé par super_bus Voir le message
Le débogueur ne vous sera d'aucune utilité pour son identification. Vous constaterez simplement le fait.
J'ai un peu l'impression que pour vous, débuger == le message "segmentation fault"... En vrai, c'est un peu plus informatif que ça...

Citation Envoyé par super_bus Voir le message
e) Pour un "length" au lieu d'un "length -1", ce sont les tests fonctionnelles qui vous dirons la nature du problème. Je ne vois pas à quoi sert dans ce cas un débogueur.
Pour la n-ième fois, les tests permettront de détecter qu'il y a un problème, pas forcément où il se trouve.

Un gros programme est un peu plus que la somme de ses partie. Ont ne peut pas écrire toutes les sous parties d'un programme de façon parfaitement modulaire et indépendante. Il y a bien un moment où il va falloir que ça communique hein ! Alors tester chaque sous partie indépendement, c'est bien sur indispensable, et comme ça, quand un tête fait claquer une assertion ou fait segfaulter, on sait où on est. Mais il y a aussi un moment où il va falloir tester l'ensemble. Et là, bizarrement, c'est moins précis.

Je ne sais pas dans quel langage vous programmez, mais il me semble que par exemple dans les langages à gestion manuelle de la mémoire, il est assez facile de se tromper dans la politique de désallocation. Pour peu qu'un module A ait habilement conservé un pointeur vers une structure qu'un module B pense pouvoir supprimer, on aura un problème uniquement une fois que les deux modules seront "ensemble" dans le programme global.

Citation Envoyé par super_bus Voir le message
f) Ah OUI ! Alors expliquez moi, gros malin que vous êtes, pourquoi les concepteurs de langage n'utilisent pas les débogueurs ? Puisque c'est le thème de ce thread !
Plein de raisons ont été proposés. Peut être qu'ils ont la chance de travailler dans des milieux calmes, où ils n'ont pas obligations de pondre un code énorme en un temps microscopique, ce qui les obligerait à utiliser des lib extérieurs dont les invariants sont malheureusement implicites. Peut être qu'ils sont tout simplement tellement meilleurs que le commun des mortels qu'ils ne font plus jamais de double free, de dépassement de buffer, de fuite de pointeur vers stackframe, mais que des bugs "fonctionnels", où le débugger est éventuellement moins utile. Ou peut être même qu'ils sont les créateurs de langages beaucoup plus sûr, où le débugger est encore moins utile. Voir même juste inexistant (par exemple en Coq, je n'ai pas de débugger, mais je n'ai pas non plus de printf ) Et puis ce n'est pas parce qu'un maitre n'utilise pas un outil que ceux qui l'utilise sont des débiles ou des incompétents. Ca veut peut être dire qu'ils ne sont pas des maîtres. Et encore.
8  2 
Avatar de TropMDR
Membre éprouvé https://www.developpez.com
Le 05/02/2011 à 14:10
Il semble que mon point de vue se soit noyé dans les différents messages et ait été interprété plutôt à mon désavantage. Je vais donc essayer de le résumer :

J'utilise des méthodes formelles (en l'occurrence Coq) pour prouver mes programmes. Ces méthodes apportent une certitude proche de 100% que les programmes n'ont pas de bug. Ce que j'entends par là: déjà, ils n'ont pas de dépassement de tampon, pas d'overflow, pas de déréférencement de pointeurs nuls, pas de double free, etc. Là c'est plus le langage qui l'assure que vraiment la preuve. Ensuite, on sait qu'ils satisfont leur spécification (j'insiste sur le fait qu'on ne prouve pas un algorithme qu'on implémente ensuite. On prouve directement le programme).

Néanmoins, il reste toujours un risque d'erreur : une spécification erronée ou incomplète. Dans l'exemple que je donnais plus haut sur les optimisations, c'est une spécification incomplète (on demande à l'optimisation de ne pas altérer la sémantique du programme, mais on ne s'assure pas qu'elle optimise effectivement). Mais les spécifications sont écrite en langage mathématique, sans ambiguité, et sont (du moins dans l'idéeal) nettement plus concise que le programme les implémentant (voir la spécification de add sur un AVL, comparée à son implémentation).
Il est enfin possible que l'outil lui même soit bogué, mais là, la probabilité est *vraiment* faible (la TCB (trusted computing base) est vraiment réduite)

Donc non, on n'est pas à 0% de chance d'avoir un bug, on est tout de même à beaucoup, beaucoup, beaucoup moins qu'avec des programmes non prouvés.

Néanmoins, ces méthodes sont extrêmement lourde à mettre en place. Il est par exemple très compliqué de prouver un programme impératif (surtout un programme C...). Rien que spécifier un algo de tri (je ne parle même pas de le prouver), est une opération complexe (je parie mon poids en choucroute que la moitié des programmeurs sont incapable de donner une spécification correcte du premier coup). Alors prouver un quick-sort en place, boarf. Et en plus, ce n'est qu'une sous sous sous partie d'un vrai programme. Il y a donc encore un travail de titan à faire avant que ces méthodes soient accessibles au plus grand nombre.

D'ici là, je suis comme tout le monde, je veux continuer à voir l'informatique progresser et de nouveaux programmes arriver. Et dans ces programmes, il y aura toujours des bugs (puisqu'on n'a pas encore trouvé de programmeurs infaillible. La plupart reste humains...). Et donc oui, il faudra des outils pour aider à débuguer ! Bien sûr, le "good ol'" printf fonctionne dans plein de cas. Il me parait quand même bizarre de rejeter pour autant des outils un brin plus "moderne", comme un débogueur, surtout qu'ils ont quand même fait des progrès, principalement en terme d'interface !

Et puis il y a aussi une percolation progressive des différentes méthodes. Par exemple, le compilo C d'Apple incorpore un analyseur statique pour aider à trouver des causes classique d'erreurs. Tous ces outils permettent de limiter les cas où un déboguer est utile. Mais on est encore bien loin de le rendre inutile dans tous les cas.
8  2 
Avatar de Logan Mauzaize
Rédacteur/Modérateur https://www.developpez.com
Le 10/05/2011 à 9:37
Encore plus en retard

Un débogueur n'est pas indispensable mais fait gagner énormément de temps. Et le modèle économique d'une entreprise étant ce qu'il est, le temps c'est l'argent.
L'argent étant indispensable.
Tout informaticien devant être assez logique pour résoudre ses simples implications, je vous laisse faire la conclusion.

Pour la méthode trace il faut des pré-conditions :
  • Il faut pouvoir modifier le code, le compiler et le déployer dans un environnement de test
  • Il faut savoir localiser les endroits qui contiennent l'information
  • Il faut savoir localiser les endroits où se trouve les erreurs. L'erreur n'est pas toujours, par expérience rarement, là où l'erreur est détectée.


Je me demande comment font ceux qui n'utilisent pas de débogueur pour "tracer"
  • une librairie tierce ?
  • un bout de code appelé 1000 fois par 1000 contexte ?


Pour ceux qui disent j'ai pas de débogueur, je connais pas ou je ne sais pas m'en servir alors vous n'êtes pas concernés par la question ...
Avant j'avais pas de perceuse, je bricolais quand même mais j'aurais pas répondu à une question "Utilisez-vous une perceuse ou un tournevis ?"
J'en viens également à un autre "détournement" de la question : ce n'est pas parce que j'utilise la perceuse que j'ai laissé tomber le tournevis ;-)
6  0