4 ms·

I just think debugging is art and parcel of programming. Debugging should come up in the first practical exercise in a Graphics 101. It should come up the first

I just think debugging is art and parcel of programming. Debugging should come up in the first practical exercise in a Graphics 101. It should come up the first time you do an ML assignment in Programming Languages. 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.

dagw 10y ago
But at the same time more than half of the professional web developers I know don't really use a debugger. Equally problematic. 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.
- majewsky 10y ago
  Exactly. Have fun debugging a microservice in production. All you can do is increase the log level, and even that is sometimes not possible because the program would spew out so many logs that it would bring down either some disk or the network. 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).
- rnabel 10y ago
  In many ways, the tooling around web development is far superior to other languages (e.g. golang with delve). Most browsers ship with excellent debug tools. The caveat obviously being that debugging code written using some JS frameworks, like Polymer, is a nightmare.
  - senorjazz 10y ago
    and in many ways the tooling around web development is absolutely terrible (eg not a brand new language eg go but an established language eg any of them)
  - erikpukinskis 10y ago
    That's it. Declarative asset compilers like Webpack break debugging. Transpiling breaks debugging. Convention-over-configuration frameworks and tools like Ember break debugging. Other declarative APIs like promises and and virtual DOMs break debugging. 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.
- Waterluvian 10y ago
  Which is so odd to me because the JavaScript debug tools are some of the most complete and easiest to use. They're right there!
  - dagw 10y ago
    But I can't get them to integrate well with my dev tools. If, for example, I'm using something like babel/webpack/Typescript there is no easy way that I've found to for example just set breakpoint on a line of code in my editor/IDE and have the web browser debugger break when it gets there.
    - eriknstr 10y ago
      True you probably can't set the breakpoint in your IDE but thanks to source maps you can still view the original source in the debugger. https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_...
    - Tistron 10y ago
      Not as convenient, but you can write the statement `debugger;` and the debugger will stop there.
      - bostonvaulter2 10y ago
        I find it incredibly convenient because I don't need to go through the browser trying to find the same spot in the code.
    - Sacho 10y ago
      VSCode provides this functionality(https://code.visualstudio.com/docs/editor/debugging https://code.visualstudio.com/docs/editor/debugging).
- ams6110 10y ago
  I almost always start with thinking about where the bug is likely to be, then doing some print/log debugging to confirm or reject my suspicions. I find it pretty effective and simple to do. 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.
  - eropple 10y ago
    > How many developers do you see every day just sitting at their computer tapping "step" ... "step" ... "step" for hours. 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.
    - JustSomeNobody 10y ago
      I find a good logging library will help me narrow down the issue before I enter the debugger to watch what the system is doing. 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.
      - eropple 10y ago
        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's your own damned fault. :-P
tallanvor 10y ago
Is an ML course now a common part of an undergraduate degree program, though? --I genuinely don't know, which is why I'm asking. 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.
- OJFord 10y ago
  Edit: skim-read GP, got the wrong ML. 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.
  - erikpukinskis 10y ago
    Yeah, I was referring to MetaLanguage, not Machine Learning.
- pjmlp 10y ago
  It was to me, as a "Artificial Intelligence II" optional lectures, in the mid-90's. 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.

dagw 10y ago

But at the same time more than half of the professional web developers I know don't really use a debugger. Equally problematic. 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.

majewsky 10y ago
Exactly. Have fun debugging a microservice in production. All you can do is increase the log level, and even that is sometimes not possible because the program would spew out so many logs that it would bring down either some disk or the network. 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).
rnabel 10y ago
In many ways, the tooling around web development is far superior to other languages (e.g. golang with delve). Most browsers ship with excellent debug tools. The caveat obviously being that debugging code written using some JS frameworks, like Polymer, is a nightmare.
- senorjazz 10y ago
  and in many ways the tooling around web development is absolutely terrible (eg not a brand new language eg go but an established language eg any of them)
- erikpukinskis 10y ago
  That's it. Declarative asset compilers like Webpack break debugging. Transpiling breaks debugging. Convention-over-configuration frameworks and tools like Ember break debugging. Other declarative APIs like promises and and virtual DOMs break debugging. 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.
Waterluvian 10y ago
Which is so odd to me because the JavaScript debug tools are some of the most complete and easiest to use. They're right there!
- dagw 10y ago
  But I can't get them to integrate well with my dev tools. If, for example, I'm using something like babel/webpack/Typescript there is no easy way that I've found to for example just set breakpoint on a line of code in my editor/IDE and have the web browser debugger break when it gets there.
  - eriknstr 10y ago
    True you probably can't set the breakpoint in your IDE but thanks to source maps you can still view the original source in the debugger. https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_to/Use_a_source_map https://developer.mozilla.org/en-US/docs/Tools/Debugger/How_...
  - Tistron 10y ago
    Not as convenient, but you can write the statement `debugger;` and the debugger will stop there.
    - bostonvaulter2 10y ago
      I find it incredibly convenient because I don't need to go through the browser trying to find the same spot in the code.
  - Sacho 10y ago
    VSCode provides this functionality(https://code.visualstudio.com/docs/editor/debugging https://code.visualstudio.com/docs/editor/debugging).
ams6110 10y ago
I almost always start with thinking about where the bug is likely to be, then doing some print/log debugging to confirm or reject my suspicions. I find it pretty effective and simple to do. 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.
- eropple 10y ago
  > How many developers do you see every day just sitting at their computer tapping "step" ... "step" ... "step" for hours. 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.
  - JustSomeNobody 10y ago
    I find a good logging library will help me narrow down the issue before I enter the debugger to watch what the system is doing. 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.
    - eropple 10y ago
      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's your own damned fault. :-P

tallanvor 10y ago

Is an ML course now a common part of an undergraduate degree program, though? --I genuinely don't know, which is why I'm asking. 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.

OJFord 10y ago
Edit: skim-read GP, got the wrong ML. 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.
- erikpukinskis 10y ago
  Yeah, I was referring to MetaLanguage, not Machine Learning.
pjmlp 10y ago
It was to me, as a "Artificial Intelligence II" optional lectures, in the mid-90's. 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.