https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/

I looked at this expecting to dismiss it as the usual trivia/crap advice everyone gives. But it's better than that, and is a surprisingly good read. I agree with nearly all of it.

On Wednesday, 19 June 2019 at 01:15:33 UTC, Walter Bright wrote:
> https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/
>
> I looked at this expecting to dismiss it as the usual trivia/crap advice everyone gives. But it's better than that, and is a surprisingly good read. I agree with nearly all of it.

That's huge. Little quote of something I like and is funny

> First, solve your problem; find a good solution; then you can check the patterns to know how you name that solution.

Mister Jourdain...

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.

On Tuesday, June 18, 2019 8:41:31 PM MDT Exil via Digitalmars-d 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.

If anything, it's becoming more and more the case that the programs being run are services where you can't simply rerun them to reproduce problems, and in such situations, logging can be critical. Depending on the problem and how the machine is set up, core dumps can certainly help, and a debugger is helpful with those, but the whole idea that most programs can be simply debugged in an IDE is arguably becoming less and less the case as more and more stuff is a service running in the cloud.

Now, there's no question that many programs will continue to be run on a local machine or on a customer's machine in a manner that they can be debugged in-place, and plenty of bugs are quite reproducible, but a _lot_ of code that is written and run these days is not in such a situation. I have no idea whether more programmers operate in an environment where they can easily run what they're working on in their IDE, or whether more programmers are dealing with cloud services which can't easily be run in a debugger, but many, many programmers are dealing with cloud services, and for better or worse, the trend in computing seems to be heading more and more in that direction for many domains.

So, really, how important or useful logging is vs a debugger is very dependent on the kind of programs that you work on. For instance, on multiple occassions, Walter has expressed the viewpoint that if there's a problem, you simply rerun the program in the debugger, because he's used to working with batch programs like compilers where you give them some input, and they always do the same thing with the same input. As such, things like hitting a segfault for a null pointer don't tend to be a big deal to him. They're usually easy to reproduce, debug, and fix. On the other hand, in those same discussions, other people have had a very different point of view on things like how bad null pointers are, because they're used to working with programs where you can't simply rerun them to reproduce the problem.

Personally, I've actually worked on several programs where even though everything is local and could easily be run in a debugger, a log is far more useful than the debugger, because the nature of the program is such that once you stop it, you can't continue and have the program function properly (e.g. because the program has a watchdog that kills stuff if it doesn't respond quickly enough).

- Jonathan M Davis

On Wednesday, 19 June 2019 at 01:15:33 UTC, Walter Bright wrote:
> https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/
>

The proxy server is refusing connections

the black list of our corporate proxy doesn't make any sense, this IT blog is not reachable, but 4chan is no problem. :-(

On Wednesday, 19 June 2019 at 07:52:58 UTC, Patrick Schluter 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/
>>
>
> The proxy server is refusing connections
>
> the black list of our corporate proxy doesn't make any sense, this IT blog is not reachable, but 4chan is no problem. :-(

Just a tip that I gave to a friend, in cases like this you can try:

https://web.archive.org/web/20190619000045/https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/

or

https://webcache.googleusercontent.com/search?q=cache:3dSQSCoVdywJ:https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/+&cd=1&hl=en&ct=clnk&gl=br

Matheus.

On Wednesday, 19 June 2019 at 13:34:01 UTC, matheus wrote:
> ...

I forgot to mention a third option, which you can convert to PDF
using some services like: https://pdfcrowd.com/

Matheus.

On Wednesday, 19 June 2019 at 06:44:57 UTC, Jonathan M Davis wrote:
> On Tuesday, June 18, 2019 8:41:31 PM MDT Exil via Digitalmars-d 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.
>
> If anything, it's becoming more and more the case that the programs being run are services where you can't simply rerun them to reproduce problems, and in such situations, logging can be critical. Depending on the problem and how the machine is set up, core dumps can certainly help, and a debugger is helpful with those, but the whole idea that most programs can be simply debugged in an IDE is arguably becoming less and less the case as more and more stuff is a service running in the cloud.
>
> Now, there's no question that many programs will continue to be run on a local machine or on a customer's machine in a manner that they can be debugged in-place, and plenty of bugs are quite reproducible, but a _lot_ of code that is written and run these days is not in such a situation. I have no idea whether more programmers operate in an environment where they can easily run what they're working on in their IDE, or whether more programmers are dealing with cloud services which can't easily be run in a debugger, but many, many programmers are dealing with cloud services, and for better or worse, the trend in computing seems to be heading more and more in that direction for many domains.

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's actually a pretty cool plugin for VS Code, you can run it locally and you can use it on a remote service/server/dock image but run it locally and it acts as if it is being run on the server. All you need is a SSH connection to access it. I wouldn't be surprised if other IDEs start adapting this feature. I think there are some that already do have it as well. Saying "Debugging isn't useful" because you don't have access to it, isn't a very good reason to say it isn't useful. It isn't that it is not useful, you just don't have access to it. Which is something that should change, and from the looks of it is changing with the shift.

> So, really, how important or useful logging is vs a debugger is very dependent on the kind of programs that you work on. For instance, on multiple occassions, Walter has expressed the viewpoint that if there's a problem, you simply rerun the program in the debugger, because he's used to working with batch programs like compilers where you give them some input, and they always do the same thing with the same input. As such, things like hitting a segfault for a null pointer don't tend to be a big deal to him. They're usually easy to reproduce, debug, and fix. On the other hand, in those same discussions, other people have had a very different point of view on things like how bad null pointers are, because they're used to working with programs where you can't simply rerun them to reproduce the problem.

Even with logs, you will probably have a difficult time to find out where the null pointer de-reference is. With debugging, you will be able to see the exact line that the de-reference occurs. Can't speak for linux but this is exactly why it is useful to generate debug information for release builds.

> Personally, I've actually worked on several programs where even though everything is local and could easily be run in a debugger, a log is far more useful than the debugger, because the nature of the program is such that once you stop it, you can't continue and have the program function properly (e.g. because the program has a watchdog that kills stuff if it doesn't respond quickly enough).
>
> - Jonathan M Davis

If you have a crash, odds are you can't continue anyways. So that doesn't really make a difference. There's information that you can get with a debugger that you can't get with logging. With a debugger you can see the entire stack trace and see exactly what functions were called to get to the point of the failure. It makes it easier to understand what is happening. This isn't something you can get with logging unless you literally log every function call, at which point you will probably have performance issues.

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.

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.

The production server would only generate the dump file, you don't have to debug it on the production server.