• Walter Bright (4/4) Jun 18 2019 https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/
• user1234 (3/9) Jun 18 2019 Mister Jourdain...
• Exil (10/25) Jun 18 2019 This I don't agree with. Maybe specifically for his job it might
• Jonathan M Davis (36/62) Jun 18 2019 If anything, it's becoming more and more the case that the programs bein...
• Exil (31/106) Jun 19 2019 I guess it depends entirely on the setup. You can do remote
• Sebastiaan Koppe (3/7) Jun 19 2019 There are plenty of places where remote debugging access to
• Exil (4/11) Jun 19 2019 The production server would only generate the dump file, you
• Meta (5/12) Jun 19 2019 It is indeed a HUGE no-no and a big vulnerability for any
• Gregor =?UTF-8?B?TcO8Y2ts?= (25/51) Jun 27 2019 I think you're looking at this paragraoh from the wrong angle.
• Exil (29/83) Jun 28 2019 I don't think he said it in that manner, he was specifically
• Patrick Schluter (4/5) Jun 19 2019 The proxy server is refusing connections
• matheus (8/14) Jun 19 2019 Just a tip that I gave to a friend, in cases like this you can
• matheus (4/5) Jun 19 2019 I forgot to mention a third option, which you can convert to PDF

Walter Bright <newshound2 digitalmars.com> writes:

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.

user1234 <user1234 12.de> writes:

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

Exil <Exil gmall.com> writes:

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.

Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:

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

Exil <Exil gmall.com> writes:

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.

Sebastiaan Koppe <mail skoppe.eu> writes:

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.

Exil <Exil gmall.com> writes:

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.

Meta <jared771 gmail.com> writes:

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.

Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:

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.

Exil <Exil gmall.com> writes:

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.

Patrick Schluter <Patrick.Schluter bbox.fr> writes:

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

matheus <matheus gmail.com> writes:

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.

matheus <matheus gmail.com> writes:

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.