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

**souviron34** · 16/02/2011, 11h42

Envoyé par IDontLikeYou

Ou pas, puisque je parlais bien d'un environnement concurrentiel... Donc à moins que pour tous ces langages tu es certain de n'utiliser que des threads légers pour lesquels le runtime à la mainmise complète sur les I/O (et encore, si elles sont bufferisées), tu ne peux garantir l'aspect synchrone.

if you say so...

En tous cas, c'est toi qui me remontres sur le fait que tu parlais de "généralités", alors que c'est toi qui indique un cas particulier

en intevenant dans un débat de généralités...

Mais, de toutes façons je le maintiens, même ce cas est, dans la plupart des cas, synchrone...

Tes "hypothèses" de travail sur le traitement par les OS sont ça, des hypothèses... Et donc poussent le bouchon un peu loin dans le cas général...

En déduire une "aberration d'usage" relève donc d'une approximation pour le moins tendancieuse... et exagérée..

ça me fait penser aux gens qui veulent optimiser des switch ou des if, mais qui oublient d'optimiser l'algo...

PS: qu'est-ce qu'un environnement "concurrentiel" ??? A part M$ il y a bien longtemps, cela fait belle lurette que tous les autres OS sont multi-tâches... et pour avoir longtemps fait du debugging de clients/serveur sur unixoides, mais aussi sur VMS , en 20 ans je n'ai pas noté de problèmes particuliers..

**lilington** · 17/02/2011, 02h45

je plusois, je n'ai pas 20 d'experience mais pour le moment dans mon cas printer sur la sortie erreur a jusqu'a present ete synchrone a 100% dans je suis dans les 99.999% des cas.
d'ou la generalite c'est que c'est synchrone et dans le cas particulier ca ne l'est ptre pas.

**davcha** · 19/02/2011, 17h06

Franchement, synchrone ou pas, on s'en fiche non ?
Sauf si c'est pour faire du printf("pouet !"); mais c'est quand même un peu plus utile de faire un printf de quelques variables utiles...

**Luc Orient** · 19/02/2011, 20h42

Envoyé par souviron34

... PS: qu'est-ce qu'un environnement "concurrentiel" ??? A part M$ il y a bien longtemps, cela fait belle lurette que tous les autres OS sont multi-tâches... et pour avoir longtemps fait du debugging de clients/serveur sur unixoides, mais aussi sur VMS , en 20 ans je n'ai pas noté de problèmes particuliers..

Pareil ... Je suis loin du C et de son printf, étant sur Mainframe IBM (z/OS et COBOL) et je dirais exactement la même chose que souviron34.

**taha1** · 09/04/2011, 21h29

en retard comme d'hab
euh, je trouve que si on a inventé des débogueurs c'est que c'est utile ( vu que la majorité des développeurs c'est des feignants

pas taper !!!!) donc il y a un vrai besoin derrière;
J'avais un bout de code à déboguer (1000 lignes sans commentaire, 15 variables et je comprenait pas trop la signification de certaines opération, avec le débogueur, en suivant la variation des valeur et les cas limites, j'ai compris le pourquoi du traitement et j'ai même mis des commentaires :p, pour la correction il fallait ajouter +1 à une division entière, il fallait la majorer sinon on n'affiche pas tout à l'écran

)

je suis fan des débogueurs

**Logan Mauzaize** · 10/05/2011, 09h37

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

**lilington** · 10/05/2011, 10h01

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

j'ai mis +1 car je pense que j'ai bien compris ce que tu veux dire:
"enfin utiliser les deux selon le cas".
si j'ai bien compris alors tu m'as convaincu et je devrai apprendre a me servire d'outil selon le cas. Merci

**Logan Mauzaize** · 10/05/2011, 10h55

En résumé, si tu peux utiliser un débogueur utilise le, il ne peut que faire mieux qu'un maigre printf/echo/cout/display/etc. qui t'affichera uniquement l'information que t'auras estimé avoir besoin au moment d'écrire la trace et sans possibilité d'y mettre une condition dynamique (comme l'adresse d'un pointeur par exemple).

En revanche le débogueur peut pervertir le comportement d'un programme multi-threadé ... Cependant l'ajout de trace également, l'ordonnanceur accordant parfois plus de priorité aux morceaux de code exécutant des opérations I/O.

**cs_ntd** · 10/05/2011, 17h29

Tiens puisque je (re)tombe sur ce post, je voudrais partager une expérience :

Je travaille actuellement a reprendre un projet, le "mettre a jour", refactoring, tests... Et j'ai rencontré un cas bien particulier ou le debugger intéractif a été fort utile. Et meme indispensable.

Grace a lui, j'ai pu découvrir un bug que je n'aurais jamais découvert sinon je pense. J'ai transformé volontairement l'histoire, dans le but de la simplifier, mais le bug était plus subtil que raconté :

Quand on lancait le programme normalement, en éxécution normale, il n'y avait aucun soucis. Pas de plantages ni rien, tout était OK.
Quand j'ai lancé le programme en mode debug pour la première fois, PAF plantage, NullReferenceException. J'ai relancé le programme en mode debug. Et ce coup-ci pas d'erreur

Sachant que l'informatique est déterministe (en théorie

), le bug rencontré etait susceptible de se reproduire. J'ai donc regardé le code plus en détails, et je me suis rendu compte qu'il y avait un Timer initialisé au tout début du programme, qui tickait toute les 10 secondes.
Et la métode associée au tick cherchait a lire des valeurs "supposée" initialisées.

En fait le développeur initial a du considéré que au bout de 10 secondes, tout le programme serait parfaitement initialisés, tous les objets construits, etc...
Sauf qu'en mode Debug la premiere fois, j'ai mis plus de 10 secondes a initialiser les objets. Et le timer a tické, et a cherché a lire ces objets...

Ca a changé mon point de vue sur les debuggers intéractifs :o

**sylvain230** · 10/05/2011, 17h37

Le débuggeur fait partie du matériel de l'informaticien.
Sans lui il n'est pas vraiment possible de travailler.
Quand on reprend le travail de quelqu'un et qu'il est bourré de faute, je ne vois pas comment nous pouvons s'en sortir sans ce genre d'outil ...

**olivieram** · 10/06/2011, 19h52

Des langages de programmation ? j'en ai déjà conçus plusieurs.
Même si les débuggueurs sont pratiques, il n'y a qu'en production qu'on ne peut pas les utiliser. Et là, je dirais que le plus grand ART dans l'informatique, ce n'est pas la plus belle documentation, ce n'est pas le plus beau code source, le plus commenté, le plus décortiqué, le mieux indenté, etc.

Ce sont les TRACES.
Une belle trace, c'est celle qui vous explique ce qu'a fichu le programme, comment il a pété une erreur, comment qu'il est parti en peau de boudin et comment qu'il a fini.

et ça c'est clair, que quand le programme part en sucette, eh ben les traces y en a plus...
La meilleure chose à faire dans ces cas-là, c'est de regarder ce que le programme tracent quand il fonctionne bien. Là encore, c'est toute une histoire.

**B.AF** · 12/06/2011, 21h36

Envoyé par olivieram

Des langages de programmation ? j'en ai déjà conçus plusieurs.

Qui sont ?

**olivieram** · 12/06/2011, 21h52

Envoyé par B.AF

Qui sont ?

Qui sont ceux que vous ne connaissez pas parce que vous ne les avez jamais vus

**B.AF** · 12/06/2011, 22h33

C'était juste pour savoir de quoi on parle...Un dsl, un langage complet, un compilo ou une machine virtuelle...Tout ça fait aussi parti de la chose.

**olivieram** · 12/06/2011, 23h59

Envoyé par B.AF

C'était juste pour savoir de quoi on parle...Un dsl, un langage complet, un compilo ou une machine virtuelle...Tout ça fait aussi parti de la chose.

Bonsoir,
merci beaucoup pour votre gentille réponse

J'ai juste dit "des langages de programmation". Pour être concret, une machine virtuelle oui mais ce que je dis par machine virtuelle c'est, par exemple, Java; pas VMWare.

**fredericponcet** · 16/06/2011, 17h19

Oubliez l'hypothèse que ces "esprits supérieurs" aient plus de "stack space"... ils ont, au mieux, une "bibliothèque" d'abstractions très étendue, qui leur permet d'utiliser leur "stack space" de façon plus efficace.
(N.B. on parle de mémoire de travail et de mémoire à long terme, et non de "stack space" et "bibliothèque"...)

Je crois plus vraisemblabe que ce sont des programmeurs très expérimentés et qu'ils font tout simplement ce qu'ils ont pris l'habitude de faire il y a bien longtemps.
J'ai appris à programmer à une époque où les débogueurs n'existaient pas, et un petit "print" de temps en temps aidait à comprendre comment les choses se passaient.
Aujourd'hui, j'utilise volontiers du MsgBox même si je dois reconnaître que le débogueur est plus efficace, puisqu'il permet de voir l'état de toutes les variable et d'identifier plus rapidement le problème... Mais j'ai plus le réflexe MsgBox que débogueur... c'est comme ça.

**olivieram** · 16/06/2011, 22h10

Bonsoir,
S'il y a bien une personne qu'on a oublié, c'est l'analyste-programmeur.
Il n'existe plus ce métier et depuis longtemps.
Pourtant, c'était un très beau métier. Parce que c'était un analyste mais aussi un programmeur (sans nul doute).
Et par analogie, le "statisticien" est à l'analyse des statistiques ce que l'analyste-programmeur est à l'analyse des ...programmes.

L'époque de l'analyste-programmeur est révolue à cause du déboggueur automatique ? cette vérité n'en est pas une.
Un déboggueur qui fait : "votre erreur de logique se trouve là _" (en clignotant), cela n'existe pas.

Et soyez rassuré, des gens qui disent "ah mais l'erreur elle est là, il y a un + à la place d'un -", il y en a encore.

**Marc3001** · 24/06/2011, 17h36

Envoyé par olivieram

Des langages de programmation ? j'en ai déjà conçus plusieurs.
Même si les débuggueurs sont pratiques, il n'y a qu'en production qu'on ne peut pas les utiliser. Et là, je dirais que le plus grand ART dans l'informatique, ce n'est pas la plus belle documentation, ce n'est pas le plus beau code source, le plus commenté, le plus décortiqué, le mieux indenté, etc.

Ce sont les TRACES.
Une belle trace, c'est celle qui vous explique ce qu'a fichu le programme, comment il a pété une erreur, comment qu'il est parti en peau de boudin et comment qu'il a fini.

et ça c'est clair, que quand le programme part en sucette, eh ben les traces y en a plus...
La meilleure chose à faire dans ces cas-là, c'est de regarder ce que le programme tracent quand il fonctionne bien. Là encore, c'est toute une histoire.

Ce que tu veux dire c'est que le debugger ne peux s'utiliser dans tous les cas (notamment en prod) et je suis d'accord mais je ne pense que quelqu'un ait avancé ça.

Utiliser les traces en prod OK mais en dev le debugger c'est quand même hyper pratique. En plus ça évite les traces de debug à la con type printf("test") laissées là par quelqu'un de peu conscientieux et qui polluent les logs.

**I_believe_in_code** · 20/02/2012, 09h27

Envoyé par chaplin

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

Ah ? Plus j'ai de la pratique, et moins j'ai de bugs. Et pourtant, plus j'ai de la pratique, plus j'utilise le debogueur... et je debuge plus vite depuis que j'utilise le debogueur. Ca doit etre parce que je ne suis pas un mastermind.