5 ms·

> good debugger worth weight in shiney rocks, in fact also more: when faced with bug grug would often trade all shiney rock and perhaps few children for good de

> good debugger worth weight in shiney rocks, in fact also more: when faced with bug grug would often trade all shiney rock and perhaps few children for good debugger and anyway debugger no weigh anything far as grug can tell grug know debugger good but grug often realize grug no need debugger on smaller cases and only run it when grug need it, grug try simple code like print and log first, if grug sad and no understand grug go for debugger

dmix 4y ago
On the frontend I have a sweet debugger setup with neovim and chrome but there’s definitely a time investment setting it up. The overhead exists almost entirely because of how the code goes through a Typescript, Vue/Vite transpiler and needs to sync with the source map… so breakpoints aren’t a 1-to-1 connection. So yeah console.logs are still quite common even if you have a great debugger because it’s the most accessible and laziest option. But there’s something very rewarding about getting really good with a debugger and figuring things out quickly.
mattmanser 4y ago
Relying on log and print statements is like giving up. I would claim that's not simplicity, that's inexperience, but I have no idea what language you're referring to. Sometimes I do it with JavaScript when I didn't setup the project, it's using a framework I don't know and I'm not willing to spend the time figuring out how to get real debugging working so there are caveats. But you definitely should not be doing that if you have a good debugger as It's faster to click the line to add a break point and press play. You can SEE the state. And you can view other variables at the same time if something's looking whiffy, usually by just hovering your mouse. Plus see the entire call stack. The thing that's boggling my mind about this is that if you know the line to add a log statement on, you know the line to add a breakpoint on. It's so much easier to just add a breakpoint. In some languages if I saw someone adding a log statement while debugging I would immediately classify them as a junior programmer and start teaching them how to debug properly. Either you are using a shitty language with a crap debugger or you need to learn how to use your IDE.
- IsopropylMalbec 4y ago
  You are not able to, or at least should not be able to debug your code in production. More than likely all you will have is your logs.
- nwatson 4y ago
  You can't run a system handling real money or real medical records in a debugger. Or if you are, you're violating a bunch compliance standards and will get sued into oblivion.
- going_ham 4y ago
  It totally depends on the case at hand! I use debugger all the time when I run into pointer related issue, or some checking some tensors in deep neural nets etc. In some cases, I throw debugger just to see what is going on. However, I have had few cases where debugger slowed me down. If you are doing something in graphics that requires you debugging issues that spans multiple frames, sometimes it's easier to notice the value over a period of time and see why things are behaving that way. From there you can reason what might be causing the issue. It can be done frame per frame inserting multiple breakpoints, recording them and viewing them accordingly! However, I prefer simple logs in such cases. I have used both approaches as time demanded.
- iamthepieman 4y ago
  If I set a breakpoint somewhere and it ended up being a location that was useful, that's usually a good place for a log statement. As for your point about logging being a fail condition, I was working on a distributed system where I had no control over which instance my code was running on. I would attach a debugger and make the same request a dozen times before the instance I had attached the debugger to processed the request. This wasn't a system I could setup a local instance of. I also couldn't reduce the instances to a single one because there were other devs, testers, data engineers working on it and the system did raster processing that regulary took 1-5 minutes. I resorted to log debugging.
  - galaxyLogic 4y ago
    Yes logging is good in many cases. It means you can observe the whole execution of your program by simply reading the whole log. Whereas when you debug you can only debug a selected set of branches. I do both.
nerdponx 4y ago
Printf bad, log good. Grug already have logging in app. Grug use logging, Grug no reinvent logging with printf.
- Tao3300 4y ago
  Except when the complexity demon creeps into the logger. That was a thing quite recently.
collyw 4y ago
Really depends on what you are coding. I have my debugger set up, it's easier then trying top spot the new print statement in amongst all the other log statements being spat out.

dmix 4y ago

On the frontend I have a sweet debugger setup with neovim and chrome but there’s definitely a time investment setting it up. The overhead exists almost entirely because of how the code goes through a Typescript, Vue/Vite transpiler and needs to sync with the source map… so breakpoints aren’t a 1-to-1 connection. So yeah console.logs are still quite common even if you have a great debugger because it’s the most accessible and laziest option. But there’s something very rewarding about getting really good with a debugger and figuring things out quickly.

mattmanser 4y ago

Relying on log and print statements is like giving up. I would claim that's not simplicity, that's inexperience, but I have no idea what language you're referring to. Sometimes I do it with JavaScript when I didn't setup the project, it's using a framework I don't know and I'm not willing to spend the time figuring out how to get real debugging working so there are caveats. But you definitely should not be doing that if you have a good debugger as It's faster to click the line to add a break point and press play. You can SEE the state. And you can view other variables at the same time if something's looking whiffy, usually by just hovering your mouse. Plus see the entire call stack. The thing that's boggling my mind about this is that if you know the line to add a log statement on, you know the line to add a breakpoint on. It's so much easier to just add a breakpoint. In some languages if I saw someone adding a log statement while debugging I would immediately classify them as a junior programmer and start teaching them how to debug properly. Either you are using a shitty language with a crap debugger or you need to learn how to use your IDE.

IsopropylMalbec 4y ago
You are not able to, or at least should not be able to debug your code in production. More than likely all you will have is your logs.
nwatson 4y ago
You can't run a system handling real money or real medical records in a debugger. Or if you are, you're violating a bunch compliance standards and will get sued into oblivion.
going_ham 4y ago
It totally depends on the case at hand! I use debugger all the time when I run into pointer related issue, or some checking some tensors in deep neural nets etc. In some cases, I throw debugger just to see what is going on. However, I have had few cases where debugger slowed me down. If you are doing something in graphics that requires you debugging issues that spans multiple frames, sometimes it's easier to notice the value over a period of time and see why things are behaving that way. From there you can reason what might be causing the issue. It can be done frame per frame inserting multiple breakpoints, recording them and viewing them accordingly! However, I prefer simple logs in such cases. I have used both approaches as time demanded.
iamthepieman 4y ago
If I set a breakpoint somewhere and it ended up being a location that was useful, that's usually a good place for a log statement. As for your point about logging being a fail condition, I was working on a distributed system where I had no control over which instance my code was running on. I would attach a debugger and make the same request a dozen times before the instance I had attached the debugger to processed the request. This wasn't a system I could setup a local instance of. I also couldn't reduce the instances to a single one because there were other devs, testers, data engineers working on it and the system did raster processing that regulary took 1-5 minutes. I resorted to log debugging.
- galaxyLogic 4y ago
  Yes logging is good in many cases. It means you can observe the whole execution of your program by simply reading the whole log. Whereas when you debug you can only debug a selected set of branches. I do both.

nerdponx 4y ago

Printf bad, log good. Grug already have logging in app. Grug use logging, Grug no reinvent logging with printf.

Tao3300 4y ago
Except when the complexity demon creeps into the logger. That was a thing quite recently.

collyw 4y ago

Really depends on what you are coding. I have my debugger set up, it's easier then trying top spot the new print statement in amongst all the other log statements being spat out.