Thought for the ages
-
Like you, I grew up with the manual and a compiler: we didn't have access to debuggers in those days, so we had to insert out own logging statements to try and narrow down where a bug might be. When I moved to embedded assembler, it got even worse - so I wrote my own "debugger" which showed registers and could show memory content. You still had to add code to enable it though! I think what is the worst, is that never mind debugging, some of the next generation can't even read an error message and start fixing their own syntax errors. That's fundamental: if it doesn't compile (or interpret) no debugger on the planet can help you! But I agree - debugging is important and should be taught. But I suspect that those who teach this stuff don't know how to debug code (or even write it in many cases) and aren't even aware that a debugger exists, much less how useful it can be!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
The very first "larger" (i.e. 4000 instructions) program I wrote was a TRAC interpreter on the PDP-9 in assembler language (I had some experience with writing assembler programs on the PDP-8). (TRAC, Text Reckoning and Compiling was an interpreted language, essentially a big macro expander, it was popular in the late 60-ies and earliy 70-ties, search for Calvin Moors for details). As it happened, the PDP-9 had an excellent debugger -named SCALP - and since the program contained lots of pointers I really needed this debugger from time to time (the PDP-9 had just one accumulator, no further registers). Ever since that time I told students - I kept working in academia - to pay attention to debugging and I gave some demonstrations. But giving a "course" in debugging, no. It is too dependent on the project being debugged, so the basics are that you can interrupt the processing (breakpoints), inspect registers and execute step by step. Of course on the PDP-9 step by step means executing single instruction, while with e.g. the current gnu debugger (I must admit, I develop under Linux) provides lots more possibilities. As a side note: one of the nice "features" of the PDP-9 was that you could reduce the clock speed, and - when you were experiences - could follow the execution of the program on the lights on the control panel. Came in handy when your program was looping. Conclusion: yes, debugging should be taught, but preferably not in a class room someone explaining all the debugger commands on a blackboard. Guided experience is needed here.
-
The very first "larger" (i.e. 4000 instructions) program I wrote was a TRAC interpreter on the PDP-9 in assembler language (I had some experience with writing assembler programs on the PDP-8). (TRAC, Text Reckoning and Compiling was an interpreted language, essentially a big macro expander, it was popular in the late 60-ies and earliy 70-ties, search for Calvin Moors for details). As it happened, the PDP-9 had an excellent debugger -named SCALP - and since the program contained lots of pointers I really needed this debugger from time to time (the PDP-9 had just one accumulator, no further registers). Ever since that time I told students - I kept working in academia - to pay attention to debugging and I gave some demonstrations. But giving a "course" in debugging, no. It is too dependent on the project being debugged, so the basics are that you can interrupt the processing (breakpoints), inspect registers and execute step by step. Of course on the PDP-9 step by step means executing single instruction, while with e.g. the current gnu debugger (I must admit, I develop under Linux) provides lots more possibilities. As a side note: one of the nice "features" of the PDP-9 was that you could reduce the clock speed, and - when you were experiences - could follow the execution of the program on the lights on the control panel. Came in handy when your program was looping. Conclusion: yes, debugging should be taught, but preferably not in a class room someone explaining all the debugger commands on a blackboard. Guided experience is needed here.
Member 12982558 wrote:
yes, debugging should be taught, but preferably not in a class room someone explaining all the debugger commands on a blackboard. Guided experience is needed here.
:thumbsup::thumbsup::thumbsup: Totally agree. But even a blackboard lesson would be better than no lesson.
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
I'd disagree to an extent. Debugging is a state of mind; a way of thinking about the world. It's the process of looking at an event and working out what happened, how you got from "there" to "here" and what you saw happening en route - looking at the symptoms of a problem and deducing what had to happen to cause them; what that means about the underlying process; what actually happened. I can say with some confidence that I learned a lot more about debugging by buying an unreliable motorcycle that I did on any university course! :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
I agree. See Operational Research. Also I learned much more from my failures than my successes.
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
-
This thought has nothing to do with the thought of the day line of thoughts. It was brought about by a conversation I had with the Mrs., by OG's thank you post this morning, and by a question last week where the OP really needed to just debug. The conversations was about books and how she likes to have the physical book. I feel the same way and it took me a long time to get used to PDF 'books'. But I got to thinking about how I learned to program all those years ago, it was basic of course, the C=64 version. All I could do was RTFM. That was all that was available for Basic and Assembly at the time. Within a few years I was able to move to a Pc and start learning C. I had a copy of Microsoft C and again only the manual. But I learned, bought other books as I could, and learned some more. In all of that I had to fix my own problems and typo's, lots of typo's :laugh:. No one else could help. I find that I still use those methods to solve my current problems. Last step is to search online, and maybe ask some colleagues for a new set of eyes on the code. Makes me wonder if colleges who teach programming classes, teach debugging? Or should it be a course all by it's lonesome? Anyways, just a thought I had. What are yours?
Jack of all trades, master of none, though often times better than master of one.
Ron Nicholson wrote:
Makes me wonder if colleges who teach programming classes, teach debugging?
As far as am concerned, the real question is "do colleges teach?" I have yet to encounter a competent programmer fresh out of college that knows about design patterns, language syntax, some decent design skills, etc, let alone how to turn on the computer and fire up an editor and write a program or website that displays Hello World.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions -
Like you, I grew up with the manual and a compiler: we didn't have access to debuggers in those days, so we had to insert out own logging statements to try and narrow down where a bug might be. When I moved to embedded assembler, it got even worse - so I wrote my own "debugger" which showed registers and could show memory content. You still had to add code to enable it though! I think what is the worst, is that never mind debugging, some of the next generation can't even read an error message and start fixing their own syntax errors. That's fundamental: if it doesn't compile (or interpret) no debugger on the planet can help you! But I agree - debugging is important and should be taught. But I suspect that those who teach this stuff don't know how to debug code (or even write it in many cases) and aren't even aware that a debugger exists, much less how useful it can be!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
It's amazing how much the programming and debugging mind set applies to other aspects of our lives. I'd hazard a guess at almost anything man made.
Jack of all trades, master of none, though often times better than master of one.
-
I'd disagree to an extent. Debugging is a state of mind; a way of thinking about the world. It's the process of looking at an event and working out what happened, how you got from "there" to "here" and what you saw happening en route - looking at the symptoms of a problem and deducing what had to happen to cause them; what that means about the underlying process; what actually happened. I can say with some confidence that I learned a lot more about debugging by buying an unreliable motorcycle that I did on any university course! :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
Problem solving. Programming is like any other challenge in life, you have to learn to use the tools youn can find and reduce the problem to a level where you can solve.
The less you need, the more you have. JaxCoder.com
-
It's amazing how much the programming and debugging mind set applies to other aspects of our lives. I'd hazard a guess at almost anything man made.
Jack of all trades, master of none, though often times better than master of one.
Which begs the question "how do these people manage to do anything at all?" :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
Which begs the question "how do these people manage to do anything at all?" :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
:thumbsup:
Jack of all trades, master of none, though often times better than master of one.
-
Like you, I grew up with the manual and a compiler: we didn't have access to debuggers in those days, so we had to insert out own logging statements to try and narrow down where a bug might be. When I moved to embedded assembler, it got even worse - so I wrote my own "debugger" which showed registers and could show memory content. You still had to add code to enable it though! I think what is the worst, is that never mind debugging, some of the next generation can't even read an error message and start fixing their own syntax errors. That's fundamental: if it doesn't compile (or interpret) no debugger on the planet can help you! But I agree - debugging is important and should be taught. But I suspect that those who teach this stuff don't know how to debug code (or even write it in many cases) and aren't even aware that a debugger exists, much less how useful it can be!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
OriginalGriff wrote:
we didn't have access to debuggers in those days, so we had to insert out own logging statements to try and narrow down where a bug might be.
Ohhhh...A JavaScript dev, right? :rolleyes:
console.log("the bug is here somewhere...");
-
This thought has nothing to do with the thought of the day line of thoughts. It was brought about by a conversation I had with the Mrs., by OG's thank you post this morning, and by a question last week where the OP really needed to just debug. The conversations was about books and how she likes to have the physical book. I feel the same way and it took me a long time to get used to PDF 'books'. But I got to thinking about how I learned to program all those years ago, it was basic of course, the C=64 version. All I could do was RTFM. That was all that was available for Basic and Assembly at the time. Within a few years I was able to move to a Pc and start learning C. I had a copy of Microsoft C and again only the manual. But I learned, bought other books as I could, and learned some more. In all of that I had to fix my own problems and typo's, lots of typo's :laugh:. No one else could help. I find that I still use those methods to solve my current problems. Last step is to search online, and maybe ask some colleagues for a new set of eyes on the code. Makes me wonder if colleges who teach programming classes, teach debugging? Or should it be a course all by it's lonesome? Anyways, just a thought I had. What are yours?
Jack of all trades, master of none, though often times better than master of one.
When I got back into programming in the late '90s' at uni, the only resources I had were the quarterly MSDN CDs, textbooks, and a growing collection of thick paperback reference manuals. In a previous era I taught myself BASIC, then later was a CS student when C, Pascal, and Fortran were the rage. In a decade, everything had changed and I now had compilers at home, not to mention working with objects and events...It was a brave new world and I was recently out of a bad relationship, unemployed, and living by myself...so one more chance at getting a degree...sorry, getting off topic. Regarding debugging, my experience is that it is not taught in the classrooms and textbooks don't cover it well. I can still remember a colleague showing me how to set a breakpoint and F8 to actually watch the code step through the instructions! I was gobsmacked!:confused:...how did I not know about this before? It was a true epiphany! :) I haven't bought a programming book in at least 10 years, even an ebook...though if I had my choice, I would prefer a hard copy over digital. I don't seem to have the time anymore to devote to a full understanding of the 'problem at hand', instead settling for Google searches and answers that are pertinent or can be twisted into a solution. Over time, I get a lots of example code for just about everything that needs to be done...if I can just remember where it is, which then usually leads to a Google search anyway. I'm not really learning the same way I used to. Just a thought! :)
"Go forth into the source" - Neal Morse "Hope is contagious"
-
OriginalGriff wrote:
we didn't have access to debuggers in those days, so we had to insert out own logging statements to try and narrow down where a bug might be.
Ohhhh...A JavaScript dev, right? :rolleyes:
console.log("the bug is here somewhere...");
:laugh: Way before that: COBOL, FORTRAN, and punched cards (or if you were lucky, paper tape).
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
I'd disagree to an extent. Debugging is a state of mind; a way of thinking about the world. It's the process of looking at an event and working out what happened, how you got from "there" to "here" and what you saw happening en route - looking at the symptoms of a problem and deducing what had to happen to cause them; what that means about the underlying process; what actually happened. I can say with some confidence that I learned a lot more about debugging by buying an unreliable motorcycle that I did on any university course! :laugh:
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
OriginalGriff wrote:
buying an unreliable motorcycle
My Dad obviously agreed with this philosophy. I watched him rebuild multiple cars and helped whenever I could, even if it was just holding the light. When my brothers and I were old enough, we all got dirtbikes...all the very same kind...late 70s Yamaha CT 175s. None worked when we got them, but we quickly learned how the 2 stroke/magneto powered things worked. I used to think he was cheap, but later in life recognized it as wisdom. :) Solving complex problems doesn't come naturally but from experience. Solving complex problems of any kind will improve your ability to solve complex problems of all kinds. High school math should begin this process, but it doesn't always translate well to the real world.
"Go forth into the source" - Neal Morse "Hope is contagious"
-
This thought has nothing to do with the thought of the day line of thoughts. It was brought about by a conversation I had with the Mrs., by OG's thank you post this morning, and by a question last week where the OP really needed to just debug. The conversations was about books and how she likes to have the physical book. I feel the same way and it took me a long time to get used to PDF 'books'. But I got to thinking about how I learned to program all those years ago, it was basic of course, the C=64 version. All I could do was RTFM. That was all that was available for Basic and Assembly at the time. Within a few years I was able to move to a Pc and start learning C. I had a copy of Microsoft C and again only the manual. But I learned, bought other books as I could, and learned some more. In all of that I had to fix my own problems and typo's, lots of typo's :laugh:. No one else could help. I find that I still use those methods to solve my current problems. Last step is to search online, and maybe ask some colleagues for a new set of eyes on the code. Makes me wonder if colleges who teach programming classes, teach debugging? Or should it be a course all by it's lonesome? Anyways, just a thought I had. What are yours?
Jack of all trades, master of none, though often times better than master of one.
-
The very first "larger" (i.e. 4000 instructions) program I wrote was a TRAC interpreter on the PDP-9 in assembler language (I had some experience with writing assembler programs on the PDP-8). (TRAC, Text Reckoning and Compiling was an interpreted language, essentially a big macro expander, it was popular in the late 60-ies and earliy 70-ties, search for Calvin Moors for details). As it happened, the PDP-9 had an excellent debugger -named SCALP - and since the program contained lots of pointers I really needed this debugger from time to time (the PDP-9 had just one accumulator, no further registers). Ever since that time I told students - I kept working in academia - to pay attention to debugging and I gave some demonstrations. But giving a "course" in debugging, no. It is too dependent on the project being debugged, so the basics are that you can interrupt the processing (breakpoints), inspect registers and execute step by step. Of course on the PDP-9 step by step means executing single instruction, while with e.g. the current gnu debugger (I must admit, I develop under Linux) provides lots more possibilities. As a side note: one of the nice "features" of the PDP-9 was that you could reduce the clock speed, and - when you were experiences - could follow the execution of the program on the lights on the control panel. Came in handy when your program was looping. Conclusion: yes, debugging should be taught, but preferably not in a class room someone explaining all the debugger commands on a blackboard. Guided experience is needed here.
Member 12982558 wrote:
Guided experience is needed here.
Absolutely true - but there's one precursor ingredient to debugging by whatever means: motivation. Motivation goes beyond the coding - you need to want to do things and make them work. Solving the bugs could (should?) be as satisfying as finally getting it all working. I take my cue (or more, found a kindred spirit) in this quote often attributed to Hannibal: "If I cannot find a way I'll make way!"
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010
-
This thought has nothing to do with the thought of the day line of thoughts. It was brought about by a conversation I had with the Mrs., by OG's thank you post this morning, and by a question last week where the OP really needed to just debug. The conversations was about books and how she likes to have the physical book. I feel the same way and it took me a long time to get used to PDF 'books'. But I got to thinking about how I learned to program all those years ago, it was basic of course, the C=64 version. All I could do was RTFM. That was all that was available for Basic and Assembly at the time. Within a few years I was able to move to a Pc and start learning C. I had a copy of Microsoft C and again only the manual. But I learned, bought other books as I could, and learned some more. In all of that I had to fix my own problems and typo's, lots of typo's :laugh:. No one else could help. I find that I still use those methods to solve my current problems. Last step is to search online, and maybe ask some colleagues for a new set of eyes on the code. Makes me wonder if colleges who teach programming classes, teach debugging? Or should it be a course all by it's lonesome? Anyways, just a thought I had. What are yours?
Jack of all trades, master of none, though often times better than master of one.
Ron Nicholson wrote:
The conversations was about books and how she likes to have the physical book. I feel the same way and it took me a long time to get used to PDF 'books'
For non-fiction I like electronic formats (PDF preferred). I usually don't read these cover-to-cover, so the ability to search is very useful. The only exception to this for me are the O'Reilly "pocket reference" paperbacks, of which I have several. These are fantastic computer books. They are short, to the point, and they provide a nice breadth of information on their topic. Fiction I always read as a paper book. Sequential reading electronically for me is distracting and unpleasant. Part of the problem is that most screens can't contain enough text to handle my reading speed, which is around 1500 words per minute. I spend a few seconds reading a page, hit the page down key, wait for the screen to update, repeat. Reading a physical book requires less time turning pages vs. absorbing text.
Ron Nicholson wrote:
Makes me wonder if colleges who teach programming classes, teach debugging? Or should it be a course all by it's lonesome?
I've never had the impression that practical skills were emphasized in collegiate programming classes. The more vocation-oriented schools like community college tend to lean more that way. In both cases students are expected to pick up those sort of experiences through internships. I always thought it would be interesting to teach a course in practical software engineering as an adjunct instructor. I would organize the course around building and maintaining a software product. The product itself would be fairly minor. The point would be to get the students familiar with and thinking about the process from requirements, implementation, testing, release, maintenance, bugs, and so on. The temptation to be perverse about changing things in midstream would almost be irresistable :cool:.
Software Zen:
delete this; -
OriginalGriff wrote:
buying an unreliable motorcycle
My Dad obviously agreed with this philosophy. I watched him rebuild multiple cars and helped whenever I could, even if it was just holding the light. When my brothers and I were old enough, we all got dirtbikes...all the very same kind...late 70s Yamaha CT 175s. None worked when we got them, but we quickly learned how the 2 stroke/magneto powered things worked. I used to think he was cheap, but later in life recognized it as wisdom. :) Solving complex problems doesn't come naturally but from experience. Solving complex problems of any kind will improve your ability to solve complex problems of all kinds. High school math should begin this process, but it doesn't always translate well to the real world.
"Go forth into the source" - Neal Morse "Hope is contagious"
kmoorevs wrote:
we all got dirtbikes...all the very same kind...late 70s Yamaha CT 175s. None worked when we got them [...] I used to think he was cheap, but later in life recognized it as wisdom
That's actually pretty cool. He knew exactly what he was doing, didn't he? I hope he knows you later understood why he bought them in a non-working state.
-
This thought has nothing to do with the thought of the day line of thoughts. It was brought about by a conversation I had with the Mrs., by OG's thank you post this morning, and by a question last week where the OP really needed to just debug. The conversations was about books and how she likes to have the physical book. I feel the same way and it took me a long time to get used to PDF 'books'. But I got to thinking about how I learned to program all those years ago, it was basic of course, the C=64 version. All I could do was RTFM. That was all that was available for Basic and Assembly at the time. Within a few years I was able to move to a Pc and start learning C. I had a copy of Microsoft C and again only the manual. But I learned, bought other books as I could, and learned some more. In all of that I had to fix my own problems and typo's, lots of typo's :laugh:. No one else could help. I find that I still use those methods to solve my current problems. Last step is to search online, and maybe ask some colleagues for a new set of eyes on the code. Makes me wonder if colleges who teach programming classes, teach debugging? Or should it be a course all by it's lonesome? Anyways, just a thought I had. What are yours?
Jack of all trades, master of none, though often times better than master of one.
On one hand, I've always thought colleges/universities shouldn't waste their time teaching how to work with the tool of the day, given how often they change and are made obsolete. On the other, part of me has often thought why waste time teaching theory when they could show how to solve real-world problems with actual code that's in actual use. But then, I go back to that first thought. If you have a solid foundation and understand the theory and how it's applied (that point is important) then you're set for life. That's why I was never asked to put together a curriculum (well, that's not true, but I declined, as I figured I had a rather strong bias...that's another story for another day). As I look back, I find there's just too much to learn. I'd hate to be back in the starting position today. That's why it's important to pick _some_thing, and learn it through and through. Make the wrong choice, and...well, this is why I'd hate to be back to my college years. To (slightly more) directly answer your question: Teach enough of the debugging basics to let people each come up with their own methodology. There is no one-size-fits-all answer IMO.
-
Ron Nicholson wrote:
Makes me wonder if colleges who teach programming classes, teach debugging?
As far as am concerned, the real question is "do colleges teach?" I have yet to encounter a competent programmer fresh out of college that knows about design patterns, language syntax, some decent design skills, etc, let alone how to turn on the computer and fire up an editor and write a program or website that displays Hello World.
Latest Articles:
Client-Side Type-Based Publisher/Subscriber, Exploring Synchronous, "Event-ed", and Worker Thread Subscriptions:laughs: I routinely taught my tutors and fellow students more than the tutors taught me. I was interested & keen. They were on the other side of 20 years worth of life's disappointments. TD TASM TurboPascal BCPP Oh how I have fond memories of thee. MASM, NASM & VC - not quite so much!
-
OriginalGriff wrote:
we didn't have access to debuggers in those days, so we had to insert out own logging statements to try and narrow down where a bug might be.
Ohhhh...A JavaScript dev, right? :rolleyes:
console.log("the bug is here somewhere...");
As it would be only useful in JavaScript... I have done it in almost every language I have used (and I am not so old as many in this thread).
M.D.V. ;) If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about? Help me to understand what I'm saying, and I'll explain it better to you Rating helpful answers is nice, but saying thanks can be even nicer.
-
Like you, I grew up with the manual and a compiler: we didn't have access to debuggers in those days, so we had to insert out own logging statements to try and narrow down where a bug might be. When I moved to embedded assembler, it got even worse - so I wrote my own "debugger" which showed registers and could show memory content. You still had to add code to enable it though! I think what is the worst, is that never mind debugging, some of the next generation can't even read an error message and start fixing their own syntax errors. That's fundamental: if it doesn't compile (or interpret) no debugger on the planet can help you! But I agree - debugging is important and should be taught. But I suspect that those who teach this stuff don't know how to debug code (or even write it in many cases) and aren't even aware that a debugger exists, much less how useful it can be!
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
I still recall the day I accidentally put the same error into a logging statement as the error I was trying to track down. I was zeroing in on the error (I thought) by adding more and more logging, wondering "how can it fail in this section, it used to work and I didn't change anything" :confused:. In the I had isolated "the error" to an empty code block with my faulty logging statement following. :doh:
