33 ms·

Seems as good a hook as any to hang this rant... > a good debugger supports different kinds of breakpoints, offers rich data visualization capabilities, has a

Seems as good a hook as any to hang this rant... > a good debugger supports different kinds of breakpoints, offers rich data visualization capabilities, has a REPL for executing expressions, can show the dependencies between threads and control their execution, pick up changes in the source code and apply them without restarting the program, can step through the code backward and rewind the program state to any point in history, and even record the entire program execution and visualize control flow and data flow history. TL;DR: That's fantastic! But if you need any of it you're already "doing it wrong". Context: I've recently been using a compiler for a C-like language that targets a simple 64-bit VM, the point being there's no debugger for the stack (the VM is written in Rust; I could put a debugger on that and just deal with the extra level of abstraction using e.g. features like those described above.) So how do you cope? Design simple and robust systems that can be understood in action easily via printf/log. Use tried-and-true off-the-shelf components (including algorithms and datastructures.) Write in small increments, compile often, never proceed without complete confidence in your understanding of the system. When the inevitable bugs appear, and they can't be discovered through just thought or a rereading of the code, then you bisect: often literally (LoC) but also conceptually. Solve the puzzle and eliminate the places where puzzles can hide in the first place. I quite literally see how a having a debugger would lead to worse code. (Even if you don't use it.) This isn't news btw: > Everyone knows that debugging is twice as hard as writing a program in the first place. So if you’re as clever as you can be when you write it, how will you ever debug it? -- Brian Kernighan, 1974 (The feeling is different: like instead of a wild adventure, programming this way feels like gardening in an orderly and well-kept garden.)

cgh 4y ago
In the real world, programmers are brought into projects with literally millions of lines of code that have been developed over years or decades by tens or hundreds of programmers. They are under intense time pressure to fix bugs that they likely didn’t create. This is normal and debuggers are invaluable. No offence, but what you’re describing is a lovely ideal that only exists if you work mostly alone or on small things.
- carapace 4y ago
  I hear you: people have been "doing it wrong" voluminously and for a long time. Ergo, fancy debuggers come in handy. > This is normal... That's the part that I have a problem with. We have leavened our entire complex civilization with software, it's important to get it right.
AndriyKunitsyn 4y ago
That's all good, but if the problem itself operates with more data than a human can reasonably operate with, this no longer applies. I do 3D meshes programming. The amount of vertices, planes and other geometrical entities that I need to operate with in my algorithms is too big for me to do printf debugging. I can't just look on a long list of 3D vertex coordinates and visualize the mesh they make in my head. Moreover, I had to come with my own 3D visualization tool, once I got fed up with pen and paper for converting 3D coordinates to actual meshes, or using Blender for that. For me, a debugger (and debugging tools in general) is irreplaceable. I'm not saying my field is the most complex one, because it clearly isn't - but in that field, I can't think of any other way I could do what I do.
- akkartik 4y ago
  But it sounds like you had to come up with your own tools because a debugger wasn't enough? That's my biggest criticism of debuggers having used both approaches: you forget that sometimes you need new tools. Whereas with prints you're constantly building new instrumentation for yourself. https://merveilles.town/@akkartik/106138280776488247 https://merveilles.town/@akkartik/106138280776488247
  - CyberDildonics 4y ago
    Whereas with prints you're constantly building new instrumentation for yourself. What does this mean? Formatting text differently is still text, which the parent post was just explaining doesn't cut it.
    - akkartik 4y ago
      I'm constantly finding new places in my program to add prints to. This isn't just copy changes. (Though that has also had a huge impact occasionally in understanding something. Imagine emitting 2 variables and then focusing on 1 of them. A pattern can pop out of a screenful of iterations of a loop when things line up just right.)
      - 4y ago
nuancebydefault 4y ago
'Design simple and robust systems...' and 'never proceed without confidence in your understanding...'. When I was a freshman, I would have said that. Then I entered the professional world. Complex problems are solved using complex solutions. Complete understanding is non-existing. Robustness is a relative term.
- carapace 4y ago
  > never proceed without [total] confidence in your understanding The fellow I learned that from was apenwarr, FWIW.

cgh 4y ago

In the real world, programmers are brought into projects with literally millions of lines of code that have been developed over years or decades by tens or hundreds of programmers. They are under intense time pressure to fix bugs that they likely didn’t create. This is normal and debuggers are invaluable. No offence, but what you’re describing is a lovely ideal that only exists if you work mostly alone or on small things.

carapace 4y ago
I hear you: people have been "doing it wrong" voluminously and for a long time. Ergo, fancy debuggers come in handy. > This is normal... That's the part that I have a problem with. We have leavened our entire complex civilization with software, it's important to get it right.

AndriyKunitsyn 4y ago

That's all good, but if the problem itself operates with more data than a human can reasonably operate with, this no longer applies. I do 3D meshes programming. The amount of vertices, planes and other geometrical entities that I need to operate with in my algorithms is too big for me to do printf debugging. I can't just look on a long list of 3D vertex coordinates and visualize the mesh they make in my head. Moreover, I had to come with my own 3D visualization tool, once I got fed up with pen and paper for converting 3D coordinates to actual meshes, or using Blender for that. For me, a debugger (and debugging tools in general) is irreplaceable. I'm not saying my field is the most complex one, because it clearly isn't - but in that field, I can't think of any other way I could do what I do.

akkartik 4y ago
But it sounds like you had to come up with your own tools because a debugger wasn't enough? That's my biggest criticism of debuggers having used both approaches: you forget that sometimes you need new tools. Whereas with prints you're constantly building new instrumentation for yourself. https://merveilles.town/@akkartik/106138280776488247 https://merveilles.town/@akkartik/106138280776488247
- CyberDildonics 4y ago
  Whereas with prints you're constantly building new instrumentation for yourself. What does this mean? Formatting text differently is still text, which the parent post was just explaining doesn't cut it.
  - akkartik 4y ago
    I'm constantly finding new places in my program to add prints to. This isn't just copy changes. (Though that has also had a huge impact occasionally in understanding something. Imagine emitting 2 variables and then focusing on 1 of them. A pattern can pop out of a screenful of iterations of a loop when things line up just right.)
    - 4y ago

nuancebydefault 4y ago

'Design simple and robust systems...' and 'never proceed without confidence in your understanding...'. When I was a freshman, I would have said that. Then I entered the professional world. Complex problems are solved using complex solutions. Complete understanding is non-existing. Robustness is a relative term.

carapace 4y ago
> never proceed without [total] confidence in your understanding The fellow I learned that from was apenwarr, FWIW.