Its absence in any course is conspicuous.
But at the same time more than half of the professional web developers I know don't really use a debugger. Equally problematic.
These days it would certainly be much easier to teach students how to use a debugger - most students probably aren't doing their work on mainframes anymore where resources might be limited (anyone else remember getting emails asking you to release your semaphores because the server is running low?), but professors still have to decide which topics are the most important to cover in a limited amount of time.
I touched on the PL ML in a type systems course. I can't speak for how common it is though. It's certainly much more likely for someone who takes a course on type systems or PL theory though, presumably given that choice it's pretty common.
--
> Is an ML course now a common part of an undergraduate degree programme, though?
There were several available to me. It's not really a particular interest of mine, but I took an introductory course anyway, since it would have seemed a bit remiss in today's world to have graduated without knowing an NN from an SVM.
Unfortunately for my grades, performance usually reflects interest... I still don't think I actually regret it though.
I rather focused on compiler design and graphical programming options instead, but I remember that all the basis for neuron learning algorithms were already part of the content.
I wonder how much that has to do with tooling? When programming in python I run everything in a debugger basically all the time. When doing JavaScript front-end work it's back to print debugging.
Debuggers are complicated and create dependency. How many developers do you see every day just sitting at their computer tapping "step" ... "step" ... "step" for hours.
I'll break out a debugger if all else fails, but it's not my first choice.
Er...very few? A bad programmer will be a bad programmer with a debugger and that bad programmer will be a bad programmer who prints out state after every line of code.
Breakpoints and watches are strictly superior to print statements for understanding the system you're working with. You drop a breakpoint where, as you yourself put it, "the bug is likely to be," you look around, you kill the process and you make a change. It doesn't "create dependency", it's just better at solving the problem. Anyone can fall back to println debugging if necessary. It's not some difficult thing. But it's wasting your time.
If I'm 90% sure I know what the bug is and it's a system where it's easier to add a print than to enter the debugger (yes, those types of systems exist), I'll do that first.
If you've written something in a language where you don't have a debugger...that's your own damned fault. :-P
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 debugger in this modern architecture of microservices that happens to be hype nowadays.
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.
> 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.
I rarely use the step functionality, though, because it just takes too long. More frequently when I hit a breakpoint, I examine the current state, figure out the next place that I am interested in stopping and then add a breakpoint there before resuming.
In these cases, the Feynman method is sometimes all that you can apply. I have already spent plenty of hours with a stacktrace on one screen and the source code on the other screen, stepping through the source code in my mind (usually backwards from the end of the stacktrace).
The caveat obviously being that debugging code written using some JS frameworks, like Polymer, is a nightmare.
PHP and JavaScripy are great for debugging. Even Node is awesome. Rails and mainstream JavaScript frameworks... not so much. Nothing about the languages.... The people who design the frameworks and build tools just don't seem to value it.
https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_...
What do you mean by this?
I wouldn't consider this to be a very common use case though, it's a niche within niche.
Luckily debugging is not merely the act of using a debugger !
Still not a reason enough to avoid using a debugger.
Showing our work reminds us that solving problems is an iterative work, and when we get the wrong answer, it lets us (with or without the help of the teacher) step through and figure out what we did wrong. For teachers and professors, it probably becomes second nature, and maybe they forget who explained this to them, or when they realized it themselves.
Even once we're out of school, I think we need to remind ourselves that this is the same reason we don't write a 1000 line function, rather we break it up into smaller parts, each designed to solve a specific part of the overall problem.
Now, what I really wish we had had in university was a CS course on using gdb and/or WinDbg - not just to understand how to analyze a core/dump file or step through running code, but also to help drill it into our head what compilers do to our code, and how processors really work. --It's amazing how often I have to remind people that debuggers will often lie to you, and you often have to look into the registers for the real data!