Logo and Learning (2015)
el.media.mit.edu
el.media.mit.edu
It was quite baffling then, till, say start of my undergrad (age 18), on what was the point of learning to control a turtle using simple commands. It hit me finally, as I was trying to learn actual programming.
A lot of people (in my circles) say that learning to program is intuitive, easy. I have never believed that. To teach something like HTML/CSS/How to use MS Word etc would be far, far worse experience (I'm looking at you, second tier Indian schools) than learning to move a turtle using simple commands. If nothing else, it brings home the idea of moving commands to actuate things on the computer.
PS: I suppose you can make the argument that this is also accomplished by video games but I hold that syntactically coherent commands (LT 90; FD 10) give a better insight into command-action nature of interaction than (Up arrow; Up arrow; move mouse to enemy; left click).
I've helped teach CS to high schoolers for a few years. In some years, we've used visual systems like this. In my experience, they help kids get started with programming really easily. They can slowly learn more and more programming concepts with immediate visual feedback. But, in all classes, they get stuck in learning to abstract or plan solutions ahead of time for more complex problems. That's a hard jump with every method of teaching CS, though. In a sense, the immediacy of visual programming can make it hard for them to slowly develop long-range planning and reasoning skills. I'm not sure if a purely symbolic approach is better, still. I do think a bit more practice-oriented learning may help - think multiplication table worksheets.
Cool video: https://youtu.be/D-guBA1_T_Y
I saw a video of young kids in England "playing LOGO" before their schools had acquired computers. They were taking turns playing the part of the turtle while other kids spoke programs like "forward 4; right 90 degrees." Papert was big into "embodied learning" where concepts are translated into physical actions and artifacts, so it's no shock he would recommend something like this.
Somewhat related... my mother was an educational researcher at the time, so I'm one of the few people who can say "my mother taught me Lisp when I was 7 years old." Also... I learned unix sysadmin in the 80s maintaining my mom's Sun 3/60. Pretty sure the idea of using a Sun as a daily driver was an idea she picked up from her interactions with Papert's lab.
I just finished reading Brian Dear's "Friendly Orange Glow" where some interviewees said they felt Papert was a bit arrogant. But... having benefited from both PLATO and LOGO, the only thing I can say is "more arrogance like Papert's, please."
IF :SIZE > 100 [MAKE "SIZE :SIZE - 100]
TO MODVAR :VARIABLE :AMOUNT
IF THING :VARIABLE > :AMOUNT [MAKE :VARIABLE THING :VARIABLE - :AMOUNT]
END
MODVAR "SIZE 100
TO WHILE :COND :BLOCK
IF :COND [EVAL :BLOCK WHILE :COND :BLOCK]
END
I was looking at Berkeley Logo to remind myself of the commands, and found that CASE (similar to switch) is implemented as a macro: https://github.com/jrincayc/ucblogo-code/blob/26ae6f01105832... – though it seems like it could be implemented just fine as a regular function. Though :caseignoredp is confusing me a bit... it's technically a dynamically-scoped variable that affects many comparison operations, but that wouldn't work with a macro. I wonder if that's a bug from when it was converted from a normal function to a macro.
TO WHILE :COND :BLOCK
IF RUNRESULT :COND [RUN :BLOCK WHILE :COND :BLOCK]
END
Also looking closer at UCBLogo macros and they are evaluated at runtime in a way I didn't expect. That is, they are expanded at call time, and can self-reference causing repeated expansions (but the expansions are immediately evaluated so the program size isn't effected). But I think they really could have accomplished the same thing more easily with the Tcl uplevel command.