[HN Gopher] Finding and fixing standard misconceptions about pro...
___________________________________________________________________
Finding and fixing standard misconceptions about program behavior
Author : vector_spaces
Score : 41 points
Date : 2024-04-12 16:09 UTC (1 days ago)
(HTM) web link (blog.brownplt.org)
(TXT) w3m dump (blog.brownplt.org)
| justin_oaks wrote:
| This is great. It's good to see someone attempting to identify a
| mistaken mental model and then correcting it.
|
| In both formal and informal education, it is rare to see
| teachers/parents/mentors identifying misunderstandings and
| correcting them. All too often the one teaching reiterates the
| lesson material instead of asking the learner about their
| understanding and correcting misunderstandings.
| 082349872349872 wrote:
| I self-taught basic algebra with a "choose your own adventure"
| book that advanced to the next topic for correct answers and
| went through pages explaining the common misconceptions then
| returned to the question for incorrect.
|
| (to be fair, class sizes were ~30 when was in school, so asking
| the learner about their understanding and correcting
| misunderstandings would not have been likely: assuming 40
| minutes lecture time for a 50 minute class, that's 20 seconds
| per student, and at most ~2 minutes if no lecture time
| whatsoever)
| Turing_Machine wrote:
| Nice, but needs some more attention to variant (but equivalent)
| responses.
|
| For example, for one of the questions in the first module I
| selected "Other", then typed "Error" (in the free-form response
| box). The answer it was looking for was "error" (lower-case e).
|
| Either it should accept both, or if you're really insistent on
| distinguishing the two, it should be made more clear at the
| beginning that system messages (rather than explicit results) are
| going to be case-sensitive. Counting "ABC" wrong when the
| expected answer is "abc" would be fair game. Counting "Error"
| wrong for a pseudo-language that hasn't even been formally
| defined is not, or so I see it.
|
| Looking at some of the languages on which this is claims to be
| based:
|
| In JavaScript, typing abc when it's undefined produces: Uncaught
| ReferenceError: abc is not defined at <anonymous>:1:1 (anonymous)
| @ VM33:1
|
| (note capital E in ReferenceError)
|
| In Python3 you get:
|
| NameError: name 'abc' is not defined. Did you mean: 'abs'?
|
| (again, note capital E in NameError)
|
| In Racket 8.9 you get:
|
| abc: undefined; cannot reference an identifier before its
| definition
|
| (no 'error' of any kind!)
|
| I didn't install OCaml, because I need another "package manager"
| like I need a hole in the head.
|
| Java: does not compile, although to be fair the compiler error
| message does have an 'error with lower-case e' in it.
|
| C#: Yeah, not gonna install that either.
|
| This may seem extremely nit-picky (and it is), but when you're
| teaching people who've never programmed before, and who may have
| never even encountered the concept of case sensitivity before
| ("But Google doesn't care even if I type in all caps!"), nit-
| picky is the way it needs to be.
|
| As I said, I do like this, but it needs more attention paid to
| parsing free-form responses. The problem is not unique to this
| system, of course. The free-form response is where most systems
| of this general type tend to fail.
| echoangle wrote:
| There was an example directly before that question which shows
| an example output when dividing by zero. There you can see what
| format they expect the error to be.
| echoangle wrote:
| I get that the syntax options are just to adapt to different
| language users but it's a little bit confusing that some claims
| are actually wrong in the specific language. In the first test,
| they state that adding two bools gives an error, even though this
| is perfectly valid in Python.
| Animats wrote:
| > We also believe that the terms "call-by-value" and "call-by-
| reference" are so hopelessly muddled at this point (between
| students, instructors, blogs, the Web...) that finding better
| terminology overall would be helpful.
|
| Maybe that shouldn't even be exposed to the programmer. The
| programmer-level questions are, is it copyable, is it mutable,
| and is it alias-free? Whether it's passed as a copy or a pointer
| is really an issue for the compiler. If you're passed a read-only
| copy of something guaranteed to not be aliased, you can't tell
| the difference from a reference. Some Modula compilers made that
| decision automatically, based on object size.
|
| Rust compilers have the info to do this. I'm sometimes asking
| myself whether I should pass, say, an array of 3 32-bit floats in
| graphics code by reference or by value. The compiler knows better
| than the programmer what the hardware can copy fast, and that may
| differ with the platform.
| erik_seaberg wrote:
| Deep value equality can also be expensive to check, so some
| languages default to reference equality even for immutable
| values.
| nox101 wrote:
| > Maybe that shouldn't even be exposed to the programmer. The
| programmer-level questions are, is it copyable, is it mutable,
| and is it alias-free? Whether it's passed as a copy or a
| pointer is really an issue for the compiler.
|
| The problem here is the definition of "call by reference". In
| C++ that means being able to change the value outside of the
| function taking the reference. void
| setByReference(float& v) { v = 123; } float v;
| setByReference(v); cout << v; // prints 123
|
| That feature of being able to pass by reference doesn't exist
| in say, JavaScript. you can only pass by value in JavaScript.
| The types of values in JS are undefined, null, boolean, number,
| string, reference-to-function, reference-to-object. You can
| never pass anything by reference, only by value.
|
| And that's where it gets confusing. If you have a variable
| who's value is a reference-to-object you pass the value. The
| value being "reference-to-object"
|
| To re-iterate const n = 1; fn(n); // call
| by value, type of value = number const s = 'abc' fn(s);
| // call by value, type of value = string const o = {}
| fn(o); // call by value, type of value = reference-to-object
|
| In C++ though, you pass the a reference to the variable itself
| (in the example above). That's called call-by-reference.
___________________________________________________________________
(page generated 2024-04-13 23:01 UTC)