On Wednesday, 19 June 2019 at 17:11:44 UTC, Sebastiaan Koppe wrote:
> On Wednesday, 19 June 2019 at 16:09:35 UTC, Exil wrote:
>> I guess it depends entirely on the setup. You can do remote debugging on the cloud. From the article it looks as though he was using a setup that did not have this or he didn't bother to set it up so that you could.
>
> There are plenty of places where remote debugging access to production vm's is a big no-no. Not to mention ssh access.

It is indeed a HUGE no-no and a big vulnerability for any applications that are even remotely concerned with security. Remote debugging should not ever be turned on in production.

On Wednesday, 19 June 2019 at 02:41:31 UTC, Exil wrote:
> On Wednesday, 19 June 2019 at 01:15:33 UTC, Walter Bright wrote:
>> https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/
>>
>> Debuggers are over-rated
>> I heard a lot of people complaining that code editors that don't come with debugging are terrible, exactly because they don't come with debugging.
>> 
>> But when your code is in production, you can't run your favorite debugger. Heck, you can't even run your favourite IDE. But logging... Logging runs everywhere. You may not have the information you want at the time of the crash (different logging levels, for example) but you can enable logging to figure out something later.
>> 
>> (Not saying debuggers are bad, they just not as helpful as most people would think.)
>
> This I don't agree with. Maybe specifically for his job it might not have been. If you are more of a tech support and you need to remote into a customer's computer and use whatever they have available on their computer, sure. But I doubt that's the case for a large majority of programmers. Also you can debug a crash that happened on a customer's computer for a native production application with a stack trace. You might be missing some variables because it is a production build that were optimized away but you still get a lot of relevant information.

I think you're looking at this paragraoh from the wrong angle. For me it is more about the skill of debugging than about the availability of a debugging tool. I would rewrite it as "learn how to debug code in your head". It makes more sense that way: be sure that you can reason about your code's behavior reliably without tool support. This includes keeping things as simple as possible and knowing how stuff works, including stuff you didn't write.

So, for example the nifty container class you're relying on may make things simpler to code, but maybe you're hitting a usage pattern that the code on the other side of the container interface doesn't like. In C++, this means e.g. knowing exactly when a std::vector might reallocate its backing memory. And that might be the reason that the one reference you kept from before the push_back call might no longer be valid. Figuring out things like that with a debugger is usually hard because of the way most STL implementations are written. Their internals might be suppresses by the debugger, show up as a convoluted chain of method calls, or be optimized so much that you can't make heads or tails of it.

So, bottom line: even if you have a debugger, don't count on it. If you get that right, this make you a better programmer and improves your code.

Enough preaching to the choir.

On Thursday, 27 June 2019 at 09:10:36 UTC, Gregor Mückl wrote:
> On Wednesday, 19 June 2019 at 02:41:31 UTC, Exil wrote:
>> On Wednesday, 19 June 2019 at 01:15:33 UTC, Walter Bright wrote:
>>> https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/
>>>
>>> Debuggers are over-rated
>>> I heard a lot of people complaining that code editors that don't come with debugging are terrible, exactly because they don't come with debugging.
>>> 
>>> But when your code is in production, you can't run your favorite debugger. Heck, you can't even run your favourite IDE. But logging... Logging runs everywhere. You may not have the information you want at the time of the crash (different logging levels, for example) but you can enable logging to figure out something later.
>>> 
>>> (Not saying debuggers are bad, they just not as helpful as most people would think.)
>>
>> This I don't agree with. Maybe specifically for his job it might not have been. If you are more of a tech support and you need to remote into a customer's computer and use whatever they have available on their computer, sure. But I doubt that's the case for a large majority of programmers. Also you can debug a crash that happened on a customer's computer for a native production application with a stack trace. You might be missing some variables because it is a production build that were optimized away but you still get a lot of relevant information.
>
> I think you're looking at this paragraoh from the wrong angle. For me it is more about the skill of debugging than about the availability of a debugging tool. I would rewrite it as "learn how to debug code in your head". It makes more sense that way: be sure that you can reason about your code's behavior reliably without tool support. This includes keeping things as simple as possible and knowing how stuff works, including stuff you didn't write.
>
> So, for example the nifty container class you're relying on may make things simpler to code, but maybe you're hitting a usage pattern that the code on the other side of the container interface doesn't like. In C++, this means e.g. knowing exactly when a std::vector might reallocate its backing memory. And that might be the reason that the one reference you kept from before the push_back call might no longer be valid. Figuring out things like that with a debugger is usually hard because of the way most STL implementations are written. Their internals might be suppresses by the debugger, show up as a convoluted chain of method calls, or be optimized so much that you can't make heads or tails of it.
>
> So, bottom line: even if you have a debugger, don't count on it. If you get that right, this make you a better programmer and improves your code.
>
> Enough preaching to the choir.

I don't think he said it in that manner, he was specifically talking about the debugger. When a crash happens it gives you information about the crash. So it just provides a means of getting extra information to you to help you diagnose the problem.

If you only used logging as a means to diagnose the problem, if you do have that kind of error. At least with the debug information you can see the problem is in push_back. You can see what the data is. Even if it is optimized, you will still at the very least get the line number and the call stack of where the crash happened.

Then there's bad code gen, it doesn't matter how good you are at debugging in your head, if the problem isn't even with your code. I think I've seen bad code gen in C++ once or twice, if even that. With DMD on the other hand, there is routinely bad code gen. Just a little while ago, boolean has code gen that can cause it to be interpreted either way if it isn't initialized. The `bool b=void; if(!b){}` I imagine that code is literally converted into a negation instead of just using JNE instead of JE for the comparison. That's not mentioning all the problems with C++ interpolation I've experienced.

You should use the tools available to you, the debug info from a crash just serves to give you additional knowledge. Pretending it's not there doesn't make you a better programmer, it just gives you less information to work with. Depending on what the problem is, like someone else mentioned with null dereferencing, it can be something you solve in 5 mins with debug info, or almost impossible depending on how big your code base is and how detailed your logging is with the performance requirements.