Re:Computer Science Circles
by danso on Thursday December 03, 2015 @11:22AM
(#10670425)
> We also will talk about logic errors at the end, which means that your program runs without crashing, but still produces the wrong result. An example would be
Please close the back door so that the bugs don't come in.
> This would be a logic error if the front door is also open: even though the command makes sense and you can close the back door, this doesn't actually accomplish the goal of keeping the bugs out since they'll still come in the front door.
---------------
As someone who also struggles to teach beginners how to program...I've learned that teaching the concept of "error" is extremely difficult. Non-programmers have a much fuzzier concept of what a programming "error" is, and this is a major obstacle.
Right now I'm teaching SQL, which is relatively straightforward as languages go. When a student tells me they ran into an error (and more often than not, doesn't think to include the error message), it can mean any of these things:
1. There's a syntax error.
2. The GUI crashed, or was otherwise acting up.
3. No results were returned.
4. Nonsensical results were returned (such as when doing an inner join without supplying a constraint).
#3 and #4 are incredibly annoying to deal with...because they aren't errors, at least on behalf of the interpreter. If your WHERE condition is `NAME = 'Dan' AND NAME = 'Daniel'" -- and you get exactly 0 results -- that is what is supposed to happen. Some might even argue that it's not really a logical error; it's just a tautology. The problem is with the user's expectation -- they think they've written something more profound than a tautology, and there's nothing the SQL interpreter can really do to tell them otherwise (short of installing a Clippy-like plugin that pops up and asks, "Did you really mean to ask that?"...which, as we all know, has its own tradeoffs...)
But this isn't even the most frustrating part -- what's frustrating is when beginners don't even know what to expect...so for problems of type #4...when they've done a WHERE conditional like this: `WHERE Name != 'Dan' OR Name != 'Daniel'`...and get all of the results...they think their program "worked"...especially if they hadn't noticed that the number of returned results is, coincidentally, the exact number of results in the entire unfiltered table.
So to go back to the OP's explanation of an error above...it's just wrong...because it's not a logical error. And it's not even a real-life "common sense" error -- closing the back door (in a normal scenario) does prevent bugs coming in...at least _from the back door_. The only way you could interpret this as an "error" is to have the expectation that a single sentence/command/statement should be the one-all solution to the problem...and that is an assumption that is profoundly limited in how it implies that there is only one solution, or that solutions don't have tradeoffs (both in real life and in the computational setting)
After all, if the student amends the statement to add "AND the front door"...it's still an error because what about the side doors or windows? And even then, another student could reasonably argue that the "correct" answer is to "take off and nuke the entire site from orbit. It’s the only way to be sure."
So, yeah, explaining computational concepts to people who are used to the fuzzy and beautiful way that humans communicate and miscommunicate is really, really difficult...and I believe that explaining the concept of errors is probably at the top of the difficulty pyramid.
---------------
As someone who also struggles to teach beginners how to program...I've learned that teaching the concept of "error" is extremely difficult. Non-programmers have a much fuzzier concept of what a programming "error" is, and this is a major obstacle.
Right now I'm teaching SQL, which is relatively straightforward as languages go. When a student tells me they ran into an error (and more often than not, doesn't think to include the error message), it can mean any of these things:
1. There's a syntax error.
2. The GUI crashed, or was otherwise acting up.
3. No results were returned.
4. Nonsensical results were returned (such as when doing an inner join without supplying a constraint).
#3 and #4 are incredibly annoying to deal with...because they aren't errors, at least on behalf of the interpreter. If your WHERE condition is `NAME = 'Dan' AND NAME = 'Daniel'" -- and you get exactly 0 results -- that is what is supposed to happen. Some might even argue that it's not really a logical error; it's just a tautology. The problem is with the user's expectation -- they think they've written something more profound than a tautology, and there's nothing the SQL interpreter can really do to tell them otherwise (short of installing a Clippy-like plugin that pops up and asks, "Did you really mean to ask that?"...which, as we all know, has its own tradeoffs...)
But this isn't even the most frustrating part -- what's frustrating is when beginners don't even know what to expect...so for problems of type #4...when they've done a WHERE conditional like this: `WHERE Name != 'Dan' OR Name != 'Daniel'`...and get all of the results...they think their program "worked"...especially if they hadn't noticed that the number of returned results is, coincidentally, the exact number of results in the entire unfiltered table.
So to go back to the OP's explanation of an error above...it's just wrong...because it's not a logical error. And it's not even a real-life "common sense" error -- closing the back door (in a normal scenario) does prevent bugs coming in...at least _from the back door_. The only way you could interpret this as an "error" is to have the expectation that a single sentence/command/statement should be the one-all solution to the problem...and that is an assumption that is profoundly limited in how it implies that there is only one solution, or that solutions don't have tradeoffs (both in real life and in the computational setting)
After all, if the student amends the statement to add "AND the front door"...it's still an error because what about the side doors or windows? And even then, another student could reasonably argue that the "correct" answer is to "take off and nuke the entire site from orbit. It’s the only way to be sure."
So, yeah, explaining computational concepts to people who are used to the fuzzy and beautiful way that humans communicate and miscommunicate is really, really difficult...and I believe that explaining the concept of errors is probably at the top of the difficulty pyramid.