This meme makes it look like it's hard decision. I always immediately slam the button on the right.
console.log(d++);Repeat.
One aspect I feel is never talked about is that setting up the debugging more often than not takes you out of the mental space of the problem you are trying to solve. A console log is basically there already in many cases.
Hmm. I, on the other hand, tend to write a lot more code than I probably should before I do debugging, so there's plenty to go back through again.
Although this looks like it's for a browser, and for all I know debuggers work completely differently in there.
Oh so it's not just me
As soon as I make more than a script, I'm using a debugger.
I really can't wrap my head around how so many of my colleagues in the professional work field just
printwherever until they find their problem.printstatements feel like touching around in pitch darkness until I found what I sought, compared to a debugger which feels like just seeing my room and daylight while finding what I sought.I crave the challenge
^ This is the person I want to develop with. My goodness, can I produce some tasty, broken first-pass code you can go wild on.
Honestly, before I'm done setting up a debugger and creating breakpoints, etc. I have added 10
consle.log()at assumed failure points and run the code again two times.For local development, it should be super quick. However, I'm currently building a small project where a device (or rather the library using it) can't really be used with a debugger. So 500 print()s it is.
but it's so much easier to put in
echo "if you can see this it worked"100 times in your source. lolI'm so glad it isn't just me lol
then i feel sorry for you too. lol
I've noticed that debugging tends to be more important in imperative languages than functional ones. With imperative style, you have a lot of implicit state that you need to know to figure out what actually happened. So, you end up having to go through the steps of building that state up before you can start figuring out what went wrong. On the other hand, the state is passed around explicitly with the functional paradigm, and you can typically figure out the problem by looking at the exact spot where the error occurred.
My typical debugging workflow with Clojure is to just read the stack trace, go to the last function in it, and then see what it's doing wrong. Very rarely do I find the need to start digging deeper. I think another aspect of it is having an interactive development workflow. When you're running code as you're developing it, you see problems pop up as you go and you can fix them before you move to the next step. This way you don't end up in situations where you wrote a whole bunch of code that you haven't run, and now you're not sure if it all works the way you expected.
With imperative style, you have a lot of implicit state that you need to know to figure out what actually happened. So, you end up having to go through the steps of building that state up before you can start figuring out what went wrong.
i think i struggle with this part the most since i'm entirely self taught and relied on very old methods for writing my source since the educational material i used was the most common and freely available at the time i starting doing development work. i've learned that it was acceptably sufficient for the IT-based problems that i was trying to solve at the time i learned it and that legacy style has been keeping me at a disadvantage.
if seen some of the newer style of debugging like the one you're shared from the young fresh graduate developers who are lucky enough to be spared the slog of a over decade within "customer service" oriented side of the tech industry umbrella and it's painfully evident to me how vastly superior it is compared to the old methods that i taught myself and it's encouraged me to seek a degree to help me master them and my new job will make that degree free for me; which matters A LOT as an american considering the price tag it entails.
Why not both
I had tried to use debugger with React so many times and each time I'd drop it soon after. Not useful at all.
Does much better job on the backend though
I did both of these at once last week.
Added a breakpoint. Debugger didn’t break.
Added an
echo "here";. Debugger didn’t print.Added a
throw new Exception('fuck');. Debugger didn’t throw.Stepped through. Debugger wouldn’t let me step in.
It took me almost an hour to realize it wasn’t the debugger’s fault and that a variable I thought was guaranteed to be truthy at that point was actually falsey due to upstream changes in a spreadsheet parser. I felt kind of stupid for not trusting the debugger at that point.
"Fine! I'll set up debugging! Stupid piece of..." - Me at some point, a little to late, into most projects
Surely we all write unit tests and debug from there, right?
... Right?
On projects where I had to write tests, I wrote them to pass the current code.
Printing debug messages didn't do much for me for this one time where a class was overflowing a buffer right in the constructor, and everything was fine creating an instance of it, passing it around, etc., until I actually go to use one of its methods later on in the program and it crashes. It was C++ on an ESP32 and I had to decode the stack trace and everything to find it, took me hours because I had to learn what even to do with a stack trace. The Espressif forums kinda suck balls, they are a ghost town.
Kind of unrelated, why does c sometimes fail to print if it hits a breakpoint right after a print while debugging? Or if it segfaults right after too iirc
does anything flush the buffers after the print, but before the break? otherwise, if the stream you're printing to is buffered, you're not necessarily gonna see any output
I don't know, I just use printf
Without knowing the details of C, I've seen this in other languages and it's usually something with missing a flush or a buffered output mode or something like that.
Im pretty sure its because of char 13 (carriage return). This char sets cursor to the start of the line overwriting whatever was printed there (in most terminals). I belive that some error messages use this char and when you print something the char at the begining or end of the error message overwrites your message. A workaround is simply printing a newline after or before your message.
I miss having a functioning debugger after moving to helix/neovim
I've had no issue with the debuggers available in meovim. A bit hard to set up dap and dap ui but once it's there it's golden
I couldn't get it working in neovim a while back and now have moved to helix which kinda has it but not really
Debug single threaded code, log multi threaded code.
“Oh, they print in that order? That’s weird.”
Get to my level of guts feeling debugging
