Why don't schools teach debugging? (2014) • Hacker News Board

Re: Why don't schools teach debugging? (2014)

#171

Post by jungletek » Thu, Apr 27, 2017, 6:22 AM UTC

nissimk wrote: post #64

camperman wrote: post #15

Earlier quoted context omitted.

I KNOW I'm better at debugging than at programming. My own working code is terribly simple and straightforward but I've fixed kernel sound drivers, buggy firmwares and complex interrupt-driven music players. Perhaps I find it easier to construct a mental model when presented with a finished system rather than when starting from scratch.

Neal Stephenson writes about this in my favorite "the diamond age," he calls it honer and forger. The type of engineer that is better at improving an existing thing vs. creating something new. There's a need for all types.

This book is probably my favorite of his, and definitely in my personal top-10 for fiction. Enjoyed it immensely on the first read, and get even more out of it on subsequent ones.

Re: Why don't schools teach debugging? (2014)

#172

Post by majewsky » Thu, Apr 27, 2017, 12:07 PM UTC

noxToken wrote: post #101

the-dude wrote: post #47

Earlier quoted context omitted.

Circle has no volume

Although I laughed, I'm sure GP meant sphere. That is the correct formula for volume of a sphere, and a sphere is a circle in 3-space.

Aw snap. Yeah, of course I meant a sphere.

(And technically, it's the other way around. A circle is the 2-dimensional special case of a (hyper)sphere.)

Re: Why don't schools teach debugging? (2014)

#173

Post by eropple » Thu, Apr 27, 2017, 3:27 PM UTC

dozzie wrote: post #167

eropple wrote: post #139

Earlier quoted context omitted.

Systems where debuggers are difficult to access totally exist, of course! But, IME, they're pretty rare by comparison (unless you've footgunned elsewhere). Whether it's something like `pry` in Ruby where you can open a REPL on command or a JVM where you connect with an external debugger, most systems are flexible enough to work with you. If you've written something in a language where you don't have a debugger...that…

> Systems where debuggers are difficult to access totally exist, of course! But, IME, they're pretty rare by comparison It's often hard to run a stepping debugger when you have an embedded hardware at hand. It's equally hard to run such a debugger when you have multi-threaded code. And the same stands for virtually any system that works with network directly, where timeouts are plentiful. Also, good luck with a debug…

> It's often hard to run a stepping debugger when you have an embedded hardware at hand.

Totally true. But that's a pretty rare situation.

> It's equally hard to run such a debugger when you have multi-threaded code.

Maybe your experience is different, but Every piece of multi-threaded code I've ever written has fallen into one of two buckets: task-pooled parallelism or interlocking features that shouldn't block one another. The former is trivial; reduce the task pool size to a single thread. The latter is definitely harder, but modern tooling (I'm partial to VS2017's Threads window) makes this a much more achievable thing; you can break across all of them and step between them effectively.

> And the same stands for virtually any system that works with network directly, where timeouts are plentiful.

I find myself debugging in environments where I can control timeouts, but if you can't, yeah, this is totally a problem. Leaving a service paused for ~3-5 minutes while I poke at it doesn't drop connections with my dev configs, though.

> Also, good luck with a debugger in this modern architecture of microservices that happens to be hype nowadays.

"Doctor, it hurts when I do this..."

If you can't effectively stub out an environment around your microservice so that you can run it in a debugger-friendly environment, you don't have a microservice--you have a monolith that communicates over pipes rather than function calls, and that's strictly worse in the first place.

Re: Why don't schools teach debugging? (2014)

#174

Post by dozzie » Thu, Apr 27, 2017, 8:14 PM UTC

eropple wrote: post #173

dozzie wrote: post #167

Earlier quoted context omitted.

> Systems where debuggers are difficult to access totally exist, of course! But, IME, they're pretty rare by comparison It's often hard to run a stepping debugger when you have an embedded hardware at hand. It's equally hard to run such a debugger when you have multi-threaded code. And the same stands for virtually any system that works with network directly, where timeouts are plentiful. Also, good luck with a debug…

> It's often hard to run a stepping debugger when you have an embedded hardware at hand. Totally true. But that's a pretty rare situation. > It's equally hard to run such a debugger when you have multi-threaded code. Maybe your experience is different, but Every piece of multi-threaded code I've ever written has fallen into one of two buckets: task-pooled parallelism or interlocking features that shouldn't block one…

>> It's often hard to run a stepping debugger when you have an embedded hardware at hand.

> Totally true. But that's a pretty rare situation.

I know it's rare to work with embedded systems if you don't work with embedded systems. Though when you do work with them, this "rare situation" suddenly becomes prevalent.

>> It's equally hard to run such a debugger when you have multi-threaded code.

> Maybe your experience is different, but Every piece of multi-threaded code I've ever written has fallen into one of two buckets: task-pooled parallelism or interlocking features that shouldn't block one another.

It all works well until it doesn't. That is, until you need two threads to communicate with each other (otherwise, why are they even running in the same process?).

>> And the same stands for virtually any system that works with network directly, where timeouts are plentiful.

> I find myself debugging in environments where I can control timeouts, [...]

All of them? My simplest cases have dozen timeouts one behind the other, at different levels of the stack. Even though I potentially can set them all, it's all very tedious. Not to mention that the timeouts can interact in non-trivial ways, so it's often hard to track all of them.

>> Also, good luck with a debugger in this modern architecture of microservices that happens to be hype nowadays.

> If you can't effectively stub out an environment around your microservice so that you can run it in a debugger-friendly environment, you don't have a microservice

https://en.wikipedia.org/wiki/No_true_Scotsman

Also, I haven't said that "you can't effectively stub out an environment". There are other difficulties around debugging microservices, like mentioned before controlling timeouts everywhere.