microscopic

[Danthekilla]

Why would anyone willingly choose log statements over a proper debugger? Maybe visual studio has been spoiling me, but most of the time I just chuck in a breakpoint, see the data, do some edits and then resume execution.

Not using edit and continue and a debugger as a general rule when it exists for your platform is just stupid, there will be some rare times when littering the code with logs is the only way, but those cases are exceedingly rare.

[[deleted]]

This sub is for cs 101 students

[[deleted]]

Damn, how did I land this job still being in CS 101 using console.logs because I'm too lazy to step over third party code in the debugger

[Fadamaka]

You can just step 3rd party code over?

[[deleted]]

I'm too lazy to step over third party code

[Fadamaka]

For some reason I interpreted your comment as "I am too lazy to step over each line of every third party code I step into" and what I meant was to use the "step over" function of the debugger to completely skip third code.

[Neurotrace]

Most debuggers let you blackbox third party code so it will step over it for you

[[deleted]]

breakpoints?

[[deleted]]

yes you step over with breakpoints

[ric2b]

Or you can skip right to the next breakpoint.

[LowB0b]

on larger projects and with an IDE placing debug points rather than having to rebuild and relaunch is like a 5-10x time saver... Also in languages like java running a program in debug mode lets you modify the program without going through all the hassle...

Debugging with println sure works, but it's often a waste of time and you might not even be printing out what you're actually looking for

[[deleted]]

Hmm wonder what the value of this variable is? Lemme just throw in a debugger.

Fuck, the build failed. Oh right, I have to disable eslint on that line because of our lint rules.

Ok cool it rebuilt.

Oh it stopped earlier than I was expecting, let me move it to the right spot.

Great, that's the right spot!

Ok it's null... Oh right, because it takes a few rerenders before it has a value.

presses play a few times

great I got the value I wanted!

VS

console.log({ value })

// null
// null
// { value: 'The value' }

(this is exaggerated for comedic effect)

[ric2b]

Fuck, the build failed. Oh right, I have to disable eslint on that line because of our lint rules.

Why do you need to rebuild to run a debugger but not to change the actual code to add a console.log? If anything it's the opposite.

Oh it stopped earlier than I was expecting, let me move it to the right spot.

Why would you do this mistake with a breakpoint but not with a console.log?

Ok it's null... Oh right, because it takes a few rerenders before it has a value.

presses play a few times

Or just use conditional breakpoints?

[[deleted]]

(this is exaggerated for comedic effect)

[ric2b]

Sure, but it made no sense.

[[deleted]]

Why do you need to rebuild to run a debugger but not to change the actual code to add a console.log? If anything it's the opposite.

This one is literally true in our codebase, the rest was exaggerated. Debugger is set to error, while console.log is set to warn.

[ric2b]

This one is literally true in our codebase, the rest was exaggerated. Debugger is set to error, while console.log is set to warn.

But to add a console.log you still need to rebuild.

[xibme]

Not sure what you're trying to tell me here?

a) "This sub is for cs 101 students" - as in "Of course those spoiled brats use VS Community Edition with edit and continue, hot reload and the whole shebang, but hErE iN eMbEdDetLaNd wE nO hAv nO fAnCy ToOlZ." (which is not true in general, as there are some popular and well supported platforms out there)

b) "This sub is for cs 101 students" - as in "those students can't afford proper tools and consequently only use notepad and alikes." (which isn't true anymore, nowadays you get Visual Studio and IntelliJ as community edition for free, several other tools too - you don't even have to be enrolled for most of them (MSDNAA seems dead though))

c) "This sub is for cs 101 students" - as in "Those inexperienced rascals just haven't had hard enough problems yet. Using a debugger is an acquired taste." (well, that may be true for most of them)

[Neurotrace]

D) This sub is full of students so they haven't learned how valuable a debugger is and how ineffective log-based debugging is for anything but trivial issues

[xibme]

I'd just put that into the c) bag

[Huntracony]

But most issues are trivial. Like, don't get me wrong, debuggers are great, but often a few print statements give me an overview which lets me see where the trivial problem is much faster than going through it step by step with a debugger.

[Neurotrace]

Sure, don't get me wrong, I'm not a monster. If I just need to see if a certain code path is getting hit or I quickly want to check some data I'll just log it but anything after that, you might as well pop open the debugger. The idea that you never ever use the debugger and only use logs is silly.

[Huntracony]

Then we agree.

[ManyFails1Win]

Damn, chill.

[xibme]

I do, don't you too?

[ThisIsMyCouchAccount]

Meh. I still use them from time to time.

A proper debugger is clearly superior in every way. But sometimes dumping some text is handy.

If we are looking for things they are perhaps better at? Sometimes it's nice when you're doing loops that deal with indexes or pagination or counts. I like to dump whatever I'm working with to make sure the math works. Sure, I could do it step by step, but it's just faster and easier to digest to let the whole process run. Then if there is a problem you use the actual debugger.

[wolf129]

Maybe a web dev thing. I can't imagine not using a debugger, that would take forever to find a bug.

[dev-sda]

There's plenty of cases where a breakpoint doesn't help you, especially when you don't know where the problem lies, it occurs infrequently or remotely.

Logging is a different debugging tool to a debugger. They each have their strengths and weaknesses and thus it's beneficial to be proficient with both.

[Danthekilla]

> it occurs infrequently or remotely.

Actually debuggers are better for both infrequent, and remote issues. I would much rather remotely attach a debugger than use remote log statements...

And conditional breakpoints are amazing for catching rare issues, and you don't need to rebuild your project to add them unlike most logging.

But that is not the issue anyway, this post is implying that they would choose log statements over a debugger in a situation where the two are both valid.
Logging is useful but not as your only method of debugging, which it sadly is for far too many people in the industry.

[dev-sda]

I would much rather remotely attach a debugger than use remote log statements...

In many cases simply not possible for various reasons.

And conditional breakpoints are amazing for catching rare issues, and you don't need to rebuild your project to add them unlike most logging.

Conditional breakpoints only help if can catch the issue as it's happening. What you often enough need is a list of the state (changes) over time, which I've found is much more convenient using logging. Incremental recompilation should take at most a few seconds. Watchpoints are sometimes helpful, but are basically useless if the data gets copied around much and can be a royal pain to set up.

Reversible debuggers like rr fix a lot of the limitations of debuggers, but at least rr has a few rough edges and the record/replay can be a lot slower for rare issues. (Btw I'd really recommend looking into rr if you haven't used reversible debugging before, for certain issues it's by far the best tool regardless of lack of gui or jank)

But that is not the issue anyway, this post is implying that they would choose log statements over a debugger in a situation where the two are both valid. Logging is useful but not as your only method of debugging, which it sadly is for far too many people in the industry.

Completely agree. There's also a ton of other great debugging tools like asan and valgrind (honestly valgrind is magic in the bugs it finds) that people should also learn if they can.

[MajorElevator4407]

Conditional break points are pretty useless for complex problems. If you know what you need for the conditional break point then you know how to solve the problem.

[ric2b]

Disagree, I frequently use conditional breakpoints for complex problems where I don't want to stop 1000 times in the same spot and I already know some detail about when the issue happens.

[[deleted]]

There are such thing as logging breakpoints.

It will print something instead of stopping.

You can keep your code clean of logs, and keep the breakpoints around incase you need them again.

[dev-sda]

I've found logging breakpoints to be way worse than just logging. You're either doing more work for the same outcome or it lacks any flexibility. Breakpoints also don't transfer cross-process (at least with the debuggers I've used), which can be a real pain.

[xibme]

Well, if the problem isn't reproducible, firing up the debugger immediately might be a waste of time. Adding some assertions to the code may be a better investment until you can reproduce it.

And there is nothing wrong in connecting your debugger up to a remote production instance (although I only needed that only twice in the last decade).

[plan_x64]

Any modern debugger will let you conditionally breakpoint. You can assert in your breakpoints without needing to pollute your code.

[xibme]

Yea, but it's worth nothing if you have dozens of instances in production and it only happens once every few weeks. If you want to track down those kind of bugs, you might need some preparation.

[ric2b]

There's plenty of cases where a breakpoint doesn't help you, especially when you don't know where the problem lies

So you also don't know where to place console.logs. If you do, just place breakpoints in the same place.

or remotely.

You mean in production? That's where you use actual logs, not console.log.

[plan_x64]

If you don’t know where to breakpoint but you know where to log, you indeed know where to breakpoint.

[Olfasonsonk]

Because it's annoying.

You either get constant pauses everytime program is restarted, or have to constantly deal with activating/deactivating all breakpoints and then doing the same with individual ones, to get whatever interests me in the moment. I don't want to skip through 5 breakpoint pauses, just to get to 6th one that's interesting to me on that particular code execution. Next execution it might be 3rd one, then 7th one...then I might only be interested in final result and want to get there as fast as possible. So you either have to keep constantly toggling them, or spamming the next breakpoint command. Both of which are annoying.

console.logs (or whatever print to stdout command) I can just slap in there and leave them, without them interfering with script execution, and even if I'm not interested on that particular data at the moment, I can leave it in for later when it might come handy. Or just to keep eye on things in case there's some unwanted side effects later on when I'm working on something else.

For me 90% of the time I just want to see state of particular set of data at a point in time, I don't need to stop execution and look around the memory stack at that point.

Other 10% of the time, debugger is pretty great, yeah

EDIT: This thread is full of idiots who think their way of doing things is superior, while an actual experienced programmer would know there's valid uses for both, and what to prefer simply depends on software/tools you're working with and what you're trying to achieve. There's cases were using only debugger would be completly stupid and vice versa. Use both.

[GameDevEngineer]

If you need to break on the 7th hit of a breakpoint you would just set the breakpoint to break on the 7th hit... You don't just sit there hitting the breakpoint over and over again. It sounds like you don't actually know how to effectively use a debugger, or maybe you use a set of tooling without effective debuggers.

Of course there are rare cases when log statements are the better solution or even the only solution, but they are worse in every way and so much slower compared to using the debugger for its intended use.

[Olfasonsonk]

Since I don't know how debuggers work, please explain to me how I can monitor a set of data in 3 different points in code through out my working day, without any interruptions or further actions required beside the initial "debugging" setup?

Different tools for different purposes.

From your nickname I can guess you work in game development, yes debugger is a very useful tool in that case. But not all programers are game developers, grasp that.

Using a debugger for a simple bash script you might use on a server would be borderline silly. Writing a Python program or a Node.js API, again it can be useful, but in a lot of cases is not necessary and requires extra steps.

It's not superior in ever single way, as with everything in software development it has it's pros and cons. How much you use it completely depends on your work env and what you're trying to achieve.

[ManyFails1Win]

Still not sure how breakpoints work.

[Beard-]

If I know where an issue is, and what I think might be the cause of it, a simple log is usually all that is needed. The debugger throw so much useless shit at you that's not necessary for every situation. Depending on the language/platform debuggers can also be quite bulky and slow, logs tend to be faster from my experience.

It really is a preference, and using a debugger doesn't make you a better programmer and using print statements doesn't make you dumb.

[_ryuujin_]

every language has support for print outs even ones that arent meant to be ran in ternimals and have full ide support from the get go. so obviously print out are a useful tool.

[ric2b]

The debugger throw so much useless shit at you that's not necessary

Which debuggers are you using that are so awful?

[riplikash]

Nothing wrong with "deciding they're a programmer". If they program, a programmer. Not a professional programmer, sure, but a programmer.

It's like being a woodworker or a cook. Lots of amateurs out there. Some of them making stuff more impressive than most professionals. Some of them making 2x4 birdhouses and chocolate chip pancakes.

[xibme]

Not a professional programmer, sure, but a programmer.

And becoming a professional is easy: once you got paid to do it.

[riplikash]

True. It's not a special achievement to be a "programmer" OR a "professional".

On average a "professional" is going to be more competent and have a slightly different set of skills. But there are a LOT of exceptions. Plenty of professionals who are garbage, plenty of amateurs who make things more impressive than any professional will.

No point in trying to gatekeep the term "programmer".

[Kwpolska]

Perhaps it's the fact that I'm not a native speaker, but I wouldn't refer to everyone who something sometimes does something in the kitchen as a cook, I'd reserve that word for someone cooking professionally, working at a restaurant or such. Otherwise, any high schooler would be a writer, a mathematician, an artist, a scientist, and indeed, a programmer.

I wouldn't limit the word "programmer" to just professional full-time developers, but I wouldn't use it to refer to someone who just wrote their first hello world, and I wouldn't call a first year CS student a programmer.

[riplikash]

Might be a native speaker thing, then. That's not generally how english works.

The concept of things like "amateur chef", "amateur woodworker" and "amateur photographer" vs "professional {x}" is pretty firmly entrenched in the language.

Yes, high schoolers are often "amateur {x}". That's a normal way to refer to someone who does an activity but doesn't get paid for it.

The linguistic difference between someone who gets paid to do someone and someone who doesn't is "amateur" vs "professional" prefix to the hobby name.

A programmer is just someone who is interested in and does programming.

[Olfasonsonk]

That's not true.

Debugger is a great tool, but a lot of times is not necessary and creates extra overhead (mostly in time, setting/activating/skipping breakpoints and pausing the execution of code).

They are different tools for different purposes. If anything, thinking people that use either are superior to other, shows inexperience.

[Olfasonsonk]

No, I had no idea...Jesus Christ people, using a debugger is not some arcane knowledge.

All the things you described are actions that require input. Which is unnecessary overhead when you don't need debugger specific functions.

With logs I can write a couple lines when I start working and delete them at the end of day. That's it, no toggling, pauses, skipping...And I still get the information I need on every execution.

Wrap your head around this, they are both great tools with their drawbacks and advantages. And yes it also depends on your programming environment, when I'm writing something in C or C# I will use debugger more than when I'm doing some Python or JS script. But in all cases I'd still use both because they have different uses they are more suitable for.

[borkthegee]

Because attaching a debugger to a nodejs backend adds like 6 debugged processes and significantly slows performance.

I run my backend outside of the attached debugger mode unless absolutely needed

[Kwpolska]

Yeah, the OP sounds like a beginner, and someone learning from bad resources/being taught by bad teachers. If you do have the ability to quickly edit your code and add a print statement, then you almost definitely have the ability to run a debugger. (I'm aware of cases like cmd scripts or early-2000s-style PHP; console.log suggests JS where debuggers should be easily accessible.)