PieFed chez MarudMadness or brilliance
https://feddit.org/pictrs/image/0eae80a7-6359-46c6-9f3f-96dbd0504bd9.png
19 Comments
Comments from other communities
2deckTo me logging combined with a quick compilation has a good flow to it. Causes you to consider what you want to see and doesn’t change the workflow if multiple stacks are involved.
Extremely helpful debugging race conditions
Except when adding the log fixes the race condition.
Naich
PenguinOfWar
Avicennaprintf("here") printf("here1")
printf("here2")
This is the way
Although I also like:
File 1:
print(0.1)
print(0.2)
File 2:
print(1.1)
print(1.2)
..
Minimal c+p+e effort
Too hard to find in a busy log.
console.log(‘===== here1’)
Can somebody reupload the image at a non-feddit.org host? Feddit is incredibly annoying in that it geoblocks most of Asia.
As someone who knows how to use a debugger, I can say for sure that log debugging is fine and often my first approach. If you have a good mental model of the code and the issue, it’s usually just 1-2 logs to solve the problem.
Meh alert(“here”); is better
Not sure why you would say that. An alert() does not show you where in the code the alert was called from. A console log would show you.
There was a time when there was no console.log in javascript. Oh and browsers didn’t even have developer tools.
Supervisor194Old school. Also the flip side:
sudo tail -f /<path to server>/error.log
Using -F with tail is even better than -f because it handles files getting truncated or getting created.
goatinspace
It drives me crazy that half my coworkers do this, including a senior dev. I’ll be on a call trying to help debug something and it makes it so difficult not being able to set a breakpoint
andyburkeI console.dir and debugger; and breakpoint all day. You are allowed to mix your strategies.
console for quick and dirty understanding but inspector for more complex fixes.
I used to do debuggers until I started doing embedded and dipped my feet in multithreading (2 different projects). After many hours lost because the debugger straight lied to me about which line of code has been executed, a colleague suggested that I just do a printf like a filthy beginner. And 🤩it worked🤩 and I never went back to the unreliable world of debuggers. Even though now I’m mostly working with single-threaded python scripts.
Can you set a breakpoint in production two days ago to debug an incident, though?
God, I wish. I’d throw money at whoever could implement such a thing. I guess its actually theoretically possible if you just sort of wrote the whole stack to an HDD but the amount of space that would take up lol.
But yeah, good logging (and not excessive logging!) is also extremely important
There are literally university courses which confidently state “Console logging is far more used and better so we won’t talk about a debugger here”!
Like sure, it’s very likely to be used far more, but that doesn’t mean you shouldn’t at least offer some courses or modules about proper use of a debugger…
DrDystopiaIt’s like the real life kraken, I’ve never seen it but the name causes dread.
This is what peak performance looks like:
console.log("before dothething");
let r = dothething();
console.log("after dothething");
console.log(r);
Honestly I use debugger when I have to go deep into some library’s bullshit code. My stuff should be stable clean and understandable enough to quickly see what’s happening with console log.
If I were to find myself needing debugger all the time with breakpoints and all this shit, it means shits has gone sideways and we need to back up and re-evaluate the code.
I am guilty of this but for a different reason: setting up debugging for clis in rust is hard
I love the debugger. I use it all the time I can. But when debugging cli it’s a pain as you need to go back in the launch.json file, remake the argument list, then come back to run debug, find out why tf it doesn’t find cargo when it’s the PATH… again, then actually debug.
I don’t feel at all guilty of doing this. Whatever works. Usually nothing is so complicated that I need to debug properly, instead of just inspecting some value along the way.
In fact, if it gets the bug resolved, it is—effectively—debugging.
Madness. When I started using gdb in C it was lifesaver to find any runtime errors in my code. Coming from what is the shit of C compilation and runtime errors it saved what would effectively be hours of inserting printf statements to find the error.
It depends how well a language specifies where the runtime error is occuring. I just get “segmentation fault (core dumped)” as my runtime error which could mean any for loop or iterattive sequence in my program.
Nothing wrong with console.log.
This is the way.
Deleted by author
console.log("poop")console.log("here")
console.log("here 2")
console.log("here 3")
Please stop leaking my code.
I sometimes write the (temporary) line number to get back to a suspect section quicker
Oh my console.log messages are so much better than that now… (that I started telling copilot to add them for me).
Sometimes there’s literally no other way (that I know of). When you’re debugging concurrency issues, stopping all time with a debugger just isn’t an option.
Yep, I’ve had times where the debugger was hiding the race condition that was the actual cause of my problem.
I guess, there’s technically nothing which dictates that a debugger has to work by stepping through a program. It could also present you some diagram of variable values changing over time. But yeah, gonna be hard to find a more useful representation than those values being interleaved with your logs, at least for most applications. I have heard of more advanced debuggers being used in gamedev, which makes sense, since logs aren’t nearly as useful there.
But yeah, given that most people think of the stepping debuggers, them being the default advice does feel emblematic of our industry still shying away from concurrency.
I can also see the variables change by logging them.
Debuggers are great if you want to see in detail what’s going on in a specific loop or something, but across a big application with a framework that handles lots of things in unreadable code, multiple components modifying your state, async code, etc.; debuggers are a terrible way to track what’s going on.
And often when I’ve found where it goes wrong, I want to check what was happening in a previous bit of code, a previous iteration or call. Debuggers don’t go back; you have to restart and run through the whole thing, again finding exactly where it went wrong, but now just a bit before that, which is often impossible.
With logging, you just log everything, print a big warning where the thing has gone wrong, and scroll back a bit.
Debuggers are a fantastic bit of technology, but in practice, simple logging has helped me far more often. That said, there are issues where debuggers do beat logging, but they’re a small minority in my experience. Still useful to know both tools.
I mean, you should do general logging either way, since you won’t have a debugger attached when running in production. And then you can typically scroll back in the logs, too, when the debugger has paused execution.
What this meme is talking about, is adding ad-hoc logs to narrow down where an error occurs while developing. So, bullshit logs like
console.log("1"), followed by a line of potentially bad code and thenconsole.log("2”). Log lines which you’ll remove again when you’re done debugging…console.log("functionOne", "A", varA, "B", varB, "C", varC);console.log('func', {A, B, C})While that works, of course, I avoid doing object construction or other logic beside some string concatenation in JS logs. And those string literals serve a purpose as semantic markers, not just as separators.
I wonder if rr would work for this scenario?
Yeah. Obviously that’s what console.debug() is for.
If you’re making a programming platform and the only debugging tool you provide to developers is console logging, you’re a monster.
yaml pipelines/actions I’m looking in your direction.
console.warn() to differentiate what you’re looking for from the regular logs.
Deleted by author