6 ms·
Children's mental models of recursive LOGO programs (1985)
- hcs 2y agoThis paper also appears in the 1989 book Studying the Novice Programmer (edited by Soloway and Spohrer). When I was looking into programming education research in the '00s this was still being suggested as a source for important experimental results, does anyone have a recommendation for a modern survey or textbook?
- YuxiLiuWired 2y agoParticularly interesting to me: Embedded recursion is much harder than tail recursion. This reminds me of the difficulty of central embedding vs tail embedding in linguistics. Level 3: tail recursion program (:SIDE = 80) TO SHAPEB :SIDE IF :SIDE = 20 STOP REPEAT 4 [FORWARD :SIDE RIGHT 90] RIGHT 90 FORWARD :SIDE LEFT 90 SHAPEB :SIDE/2 END Level 4: embedded recursion program (:SIDE = 80) TO SHAPEC :SIDE IF :SIDE = 10 STOP SHAPEC :SIDE/2 REPEAT 4 [FORWARD :SIDE RIGHT 90] RIGHT 90 FORWARD :SIDE LEFT 90 END > Mental model of embedded recursion as looping - The children were fundamentally misled by thinking of recursion as looping. While this mental model is adequate for active tail recursion, it will not do for embedded recursion. > programming constructs often do not allow mapping between meanings of natural language terms and programming language uses of those terms. Neither STOP or END stop or end, but pass control back. The reason that this is important for the Logo novice is that when their mental model of recursion as looping fails, they have no way of inferring from the syntax of recursion in Logo how flow of control does work. So they keep their inadequate looping theory, based on their successful experience with it for tail recursion, or blame discrepancies between their predictions and the program's outcomes on mysterious entities such as numbers, or the "demon" inside the language itself. > Beyond mistaken mental models about recursion, we have found these to involve atomistic thinking about how programs work, assigning intentionality and negotiability of meaning as in the case of human conversations to lines of programming code, and application of natural language semantics to programming commands.
- pierrebai 2y ago... or simply that the LOGO language syntax and choice of commands is confusing? Without formal explanation, how surprising is it really that a child would assume that STOP mean stop? I'd bet that if LOGO had used RETURN, like many other languages, then the children's reasoning would be likely be more accurate. Or go the other way and make them tell you what this or that brainfuck[1] program does. So, to me, this research says more about LOGO choices than anything. [1] https://esolangs.org/wiki/Brainfuck https://esolangs.org/wiki/Brainfuck
- dmurray 2y agoBut STOP does mean stop. Stop executing this subroutine. If the program were instead (as a set of commands for a person, not a turtle) START WALKING; STOP; START CLAPPING; STOP; ... any child would understand what was intended. It would be more confusing if the first STOP here meant "stop all program execution, never proceed to the next step". So the problem isn't STOP, it's the fact that there's more program to execute, hidden in the call stack.
- antonvs 2y agoIt’s not clear whether these results would generalize much beyond Logo. Reading the part which starts with “To understand how recursive procedures work in Logo one must know:” makes Logo recursive procedures sound pretty terrible - typical ad-hoc language design.
- hnlmorg 2y agoLogo is ostensibly a LISP, so the syntax might seem a bit alien to modern developers used to C-style braces or ALGOL-style declarations.
- antonvs 2y agoThe issue here seems to be specifically that it's a Lisp with dynamic scoping, which allows the statement I quoted in another comment to hold: > "[calling a procedure] acts to insert all lines of the named procedure into the executing program at the point where the call occurred" But that notoriously has its own issues - the various variants of the funarg problem, which were essentially solved by switching to lexical scope.