+ Répondre à la discussion Actualité déjà publiée
Page 3 sur 16 PremièrePremière 123456713 ... DernièreDernière
Affichage des résultats 41 à 60 sur 310
  1. #41
    yan
    yan est déconnecté
    Rédacteur
    Avatar de yan
    Homme Profil pro
    Ingénieur expert
    Inscrit en
    mars 2004
    Messages
    9 973
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Ille et Vilaine (Bretagne)

    Informations professionnelles :
    Activité : Ingénieur expert
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2004
    Messages : 9 973
    Points : 13 635
    Points
    13 635

    Par défaut

    Citation Envoyé par gorgonite Voir le message
    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
    Développeur Windows 8, Windows phone 8 et Nokia Asha, inscrivez vous sur DVLUP

  2. #42
    Membre Expert Avatar de Guardian
    Inscrit en
    mars 2009
    Messages
    820
    Détails du profil
    Informations forums :
    Inscription : mars 2009
    Messages : 820
    Points : 1 704
    Points
    1 704

    Par défaut

    Citation Envoyé par gorgonite Voir le message
    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

  3. #43

    Inscrit en
    mai 2010
    Messages
    8
    Détails du profil
    Informations forums :
    Inscription : mai 2010
    Messages : 8
    Points : -3
    Points
    -3

    Par défaut

    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.

  4. #44
    Membre Expert
    Profil pro
    Inscrit en
    mars 2007
    Messages
    1 270
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : mars 2007
    Messages : 1 270
    Points : 2 471
    Points
    2 471

    Par défaut

    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.

  5. #45
    Membre confirmé
    Avatar de Chatanga
    Inscrit en
    décembre 2005
    Messages
    185
    Détails du profil
    Informations forums :
    Inscription : décembre 2005
    Messages : 185
    Points : 285
    Points
    285

    Par défaut

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

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

  6. #46
    Candidat au titre de Membre du Club
    Inscrit en
    décembre 2005
    Messages
    14
    Détails du profil
    Informations forums :
    Inscription : décembre 2005
    Messages : 14
    Points : 13
    Points
    13

    Par défaut

    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.

  7. #47
    Membre habitué
    Inscrit en
    mars 2002
    Messages
    116
    Détails du profil
    Informations forums :
    Inscription : mars 2002
    Messages : 116
    Points : 127
    Points
    127

    Par défaut

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

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

  8. #48
    Membre Expert
    Avatar de SurferIX
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2008
    Messages
    473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2008
    Messages : 473
    Points : 1 012
    Points
    1 012

    Par défaut

    ... 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).
    "Ceci dit" est un non sens. Cf Wikipedia. C'est soit "cela dit", soit rien.
    Il ne faut pas oublier que la politesse et le respect sont mutuels.

    Dernières prestations de HQF Development:

  9. #49
    Modérateur
    Avatar de Vil'Coyote
    Profil pro
    Développeur Web
    Inscrit en
    février 2008
    Messages
    4 000
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : février 2008
    Messages : 4 000
    Points : 5 872
    Points
    5 872

    Par défaut

    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.

  10. #50
    Membre habitué
    Homme Profil pro
    Architecte de système d'information
    Inscrit en
    juin 2006
    Messages
    87
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 50
    Localisation : Monaco

    Informations professionnelles :
    Activité : Architecte de système d'information
    Secteur : Conseil

    Informations forums :
    Inscription : juin 2006
    Messages : 87
    Points : 135
    Points
    135

    Par défaut

    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 !

  11. #51
    Invité régulier
    Inscrit en
    juin 2007
    Messages
    7
    Détails du profil
    Informations forums :
    Inscription : juin 2007
    Messages : 7
    Points : 8
    Points
    8

    Par défaut

    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?

  12. #52
    Membre confirmé

    Inscrit en
    octobre 2006
    Messages
    43
    Détails du profil
    Informations forums :
    Inscription : octobre 2006
    Messages : 43
    Points : 257
    Points
    257

    Par défaut

    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!

  13. #53
    Membre du Club
    Inscrit en
    septembre 2010
    Messages
    69
    Détails du profil
    Informations forums :
    Inscription : septembre 2010
    Messages : 69
    Points : 55
    Points
    55

    Par défaut

    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 !

  14. #54
    Invité de passage
    Inscrit en
    septembre 2006
    Messages
    7
    Détails du profil
    Informations forums :
    Inscription : septembre 2006
    Messages : 7
    Points : 4
    Points
    4

    Par défaut selon le cas

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

  15. #55
    Membre Expert
    Avatar de SurferIX
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    mars 2008
    Messages
    473
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : mars 2008
    Messages : 473
    Points : 1 012
    Points
    1 012

    Par défaut

    Citation Envoyé par MiniCesc Voir le message
    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 .
    "Ceci dit" est un non sens. Cf Wikipedia. C'est soit "cela dit", soit rien.
    Il ne faut pas oublier que la politesse et le respect sont mutuels.

    Dernières prestations de HQF Development:

  16. #56
    Membre actif

    Profil pro
    Développeur informatique
    Inscrit en
    juillet 2004
    Messages
    46
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : juillet 2004
    Messages : 46
    Points : 168
    Points
    168

    Par défaut

    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 ?

  17. #57
    Expert Confirmé Sénior

    Inscrit en
    janvier 2007
    Messages
    10 200
    Détails du profil
    Informations personnelles :
    Âge : 57

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 200
    Points : 14 396
    Points
    14 396

    Par défaut

    Citation Envoyé par Xitog Voir le message
    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..

    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  18. #58
    Expert Confirmé Sénior

    Avatar de sjrd
    Homme Profil pro
    Chercheur en informatique
    Inscrit en
    juin 2004
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 25
    Localisation : Suisse

    Informations professionnelles :
    Activité : Chercheur en informatique
    Secteur : Enseignement

    Informations forums :
    Inscription : juin 2004
    Messages : 4 506
    Points : 9 652
    Points
    9 652

    Par défaut

    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
    sjrd, ancien rédacteur/modérateur Delphi, désormais membre de l'équipe Scala à l'EPFL en tant que doctorant.
    Auteur de Scala.js, le compilateur de Scala vers JavaScript.
    Découvrez Mes tutoriels, ou mon logiciel phare FunLabyrinthe v5.3 : un jeu de labyrinthe gratuit et personnalisable à l'infini avec des scripts Delphi-like.

  19. #59
    Rédacteur/Modérateur



    Homme Profil pro
    Développeur .NET
    Inscrit en
    février 2004
    Messages
    19 328
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur .NET
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : février 2004
    Messages : 19 328
    Points : 39 175
    Points
    39 175

    Par défaut

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

    Citation Envoyé par SurferIX Voir le message
    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.

    Citation Envoyé par SurferIX Voir le message
    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...)

    Citation Envoyé par SurferIX Voir le message
    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...)

    Citation Envoyé par SurferIX Voir le message
    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...

    Citation Envoyé par SurferIX Voir le message
    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...

    Citation Envoyé par SurferIX Voir le message
    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 + ^

    Citation Envoyé par SurferIX Voir le message
    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 + ^

    Citation Envoyé par SurferIX Voir le message
    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 ?

    Citation Envoyé par SurferIX Voir le message
    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.

  20. #60
    Membre du Club
    Inscrit en
    avril 2007
    Messages
    27
    Détails du profil
    Informations forums :
    Inscription : avril 2007
    Messages : 27
    Points : 42
    Points
    42

    Par défaut Et les tests unitaires ?

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

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •