_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI The Debugging Book
medwards666 wrote 2 hours 36 min ago:
The website needs debugging for sure.
In dark mode, the text towards the bottom of the page renders as white
on white ...
matu3ba wrote 3 hours 20 min ago:
Looks like a very reasonable guide for Python software debugging.
Reversal computing/time reversal computing is missing, but probably
Python programs are not that complex or long-running to use that.
Does Python without GIL have validator/sanitizers, scheduling and
recording for non-determinism capabilities? If yes, then either Python
is lacking or these methods are also missing.
foofoo12 wrote 4 hours 52 min ago:
Watched the video, sounds very promising!
Pro tip when you start a new project or get handed one: start by
"wasting" time setting up a good debugging environment. So you can set
a break point, click one button and BOOM, you're there.
Whatever time you "waste" on that will pay you dividends on a daily
basis for every single day you work on that project. Both in the form
of productivity and happiness (it's a form of self-care too!)
goku12 wrote 1 hour 33 min ago:
> Whatever time you "waste" on that will pay you dividends on a daily
basis for every single day you work on that project.
There is a simple concept that shows you how important, vast and
different from programming, debugging is. Troubleshooting something
(especially the investigation part) is an entirely different skill
set from creating something. They work in opposite directions.
During design, you're assembling various components to get a desired
outcome. During troubleshooting, you start from an observed anomaly
and work your way back to the component that's faulty. While this
difference may sound insignificant, the reasoning (mental algorithms)
we employ in each direction are entirely different[1].
The ability to reason in both directions is a force multiplier at any
stage of the project. This is true in any field of engineering. We
need to put significantly more effort into learning debugging skills.
Debuggers like GDB also reflect this complexity.
[1] If you're familiar with systems reliability engineering, you can
see this in action in FTA (Fault Tree Analysis) and FMEA (Failure
Mode Effects Analysis).
signa11 wrote 4 hours 0 min ago:
time spent sharpening your axe and all that jazz... totally agreed.
that is one of the reasons why maybe Emacs has that kind of appeal.
you can mold it to your way of functioning. which is ofcourse quite a
fun activity in and of itself.
hsbauauvhabzb wrote 5 hours 27 min ago:
As someone who is self taught at debugging, knows my way around an
interactive debugger very well but could undoubtedly be better (with a
good roi on investment) this is of significant value!
I would suggest spelling out the purpose of the book - is it about
/using/ debuggers or /writing/ one? The first paragraph implies the
first, but the 100 lines of python or 10k lines of C implies the
latter.
Also, on ios16, the top menu is unclosable - once itâs open the only
apparent way to collapse it is to pick an option or refresh the page.
Edit: the sections under news such as the title and paragraph for
âthe debugging bookâ jan 14 2025 are white text on a white bg also.
Iâm looking forward to reading this book though!
DIR <- back to front page