7
$\begingroup$

When programming we need to name things. I have been using turtle graphics in python, and was wondering if the names, chosen, for the commands, were making it more difficult for my pupils.

Some of the turtle commands are:

turtle.left
turtle.right
turtle.forward
turtle.backward

Pupils often get confused, because they think that turtle.left will make the turtle move to the left. Would learning be improved, if the language/libraries chose better names? e.g.

turtle.turn_left
turtle.turn_right
turtle.move_forward
turtle.move_backward

This is not about students choosing good name, but about names used by the libraries, and examples.

Improve this question
$\endgroup$
13
  • 4
    $\begingroup$ Possible duplicate of How can we teach good naming practice for students learning Java? $\endgroup$
    – Buffy
    Commented May 14, 2018 at 12:06
  • 1
    $\begingroup$ @Buffy so instead we continue to subject all pupils to a practice that we think may be worse. That is logic (should the members of the ethics board do a CS course?). $\endgroup$
    – ctrl-alt-delor
    Commented May 14, 2018 at 17:49
  • 4
    $\begingroup$ I do not see this as a duplicate of the question about teaching naming practices. As the OP has stated this is about the names already assigned in existing libraries, and language bases, and how those names affect the students' learning. $\endgroup$
    – Gypsy Spellweaver
    Commented May 14, 2018 at 23:15
  • 1
    $\begingroup$ You need to teach them that names mean nothing. That includes disabusing them of the notion that names mean something. Names label things. $\endgroup$
    – philipxy
    Commented Jun 21, 2018 at 21:20
  • 1
    $\begingroup$ Names are labels. In general we can infer nothing from the names of things. (This has nothing to do with implementation, which has nothing to do with the meanings of programs.) In everyday life we are used to names frequently also being descriptive of their referents. But this cannot be relied on. Nor can it be in a technical context. All we can rely on is definitions, axioms, theorems & sound reasoning. Understanding this is fundamental to competent technical work. People must be actively disabused of their naive expectations. French toast is not toast. = is not equality if not (NaN=NaN). $\endgroup$
    – philipxy
    Commented Jun 22, 2018 at 19:13

3 Answers 3

Reset to default
7
$\begingroup$

You don't have control over the libraries, though you can provide a filter class that, itself, provides better names. Yes, names matter and shouldn't be confusing.

But when you create examples and libraries pay a lot of attention to the names. When you present them to the students and learn that there are confusions, change them. Even better, ask the students to suggest better names. One of the purposes of the Navigator in a Pair Programming scenario is to suggest alternate names to the Driver.

In my somewhat extreme view, every name should be intention revealing. The only exceptions are very common acronyms and abbreviations. But in general, I don't create either acronyms or abbreviations and try to make the names as clear as possible. I fail at this of course, but it is the goal.

However, in the current example, the students should also have a metaphor about the overall structure of the simulated world. Turtles only move in the direction they are facing. They can turn, either left or right. There should also be some per-instruction documentation that makes it clear. If they can learn to think in terms of the metaphor, rather than the detail, they will have an advantage as long as the metaphor itself is sound.

Also, in the current example, I'll note that too many people name things emphasizing short names over self-explanatory names. I sometimes think that they believe that the hard part of programming is the typing. There was a point in time in which program preparation (punch cards) was extremely frustrating but those times are gone. Good IDEs today do typing completion, so names seldom need to be typed in full. But even in the card punch days, real programmers employed data entry clerks who did the card punching from hand written coding sheets. A good clerk could correct quite a few minor errors along the way.

Improve this answer
$\endgroup$
2
$\begingroup$

The names of symbols in the language, or library, that is being used in the classroom should not have any effect upon student learning.

The learning of the students is based more upon the knowledge passed on from the teacher to the students. The language, and its libraries and examples, are mere tools. How they are used, and presented, by the instructor can remove any associated ambiguity that might result from the chosen names if they were encountered "in the wild."

On the other hand, helping the students to handle situations where a symbol's name does not match what they "expect" that it should indicate is a worthwhile goal. There will be many occasions in their future career, if they pursue such, where they will encounter many "names" that don't match what they think they should. The, likely minor, disconnect between expectations and reality of names in languages and libraries should be a good learning tool for when they encounter much larger disconnects in code written by others that they either have to maintain, or interact with in future projects.

As mentioned by another user, Buffy in their answer, having a metaphor to deal with the environment of the language, or library, often helps. In widely used languages and libraries the metaphor, if chosen well, will usually be sufficient to make the students comfortable in that environment. With programs found "in the wild" there will often be no useful metaphor available, or likely even possible. Taking advantage of any disconnects that exist in the the language base used in the classroom can help the students learn to adjust to such situations later. It can also be used as an example of why good naming conventions are important.

Improve this answer
$\endgroup$
9
  • 3
    $\begingroup$ The problem is, when you read turtle.left(30), you have 2 possible understandings : move it 30 units to the left, or change its direction (anti-clockwise). You have to remember which on is the correct interpretation, which causes an extra cognitive load (we already have to remember the left from the right :-)). So it has a negative impact. Could be avoided with better names. $\endgroup$
    – Michel Billaud
    Commented May 15, 2018 at 7:58
  • $\begingroup$ @MichelBillaud As I understand it, the turtle cannot move left, any more than a car can. That means "left" can only mean "turn" not "move". The *mental model", or metaphor, is incompletely developed if the choice of move or turn arises from the command "left". $\endgroup$
    – Gypsy Spellweaver
    Commented May 15, 2018 at 9:12
  • $\begingroup$ @GypsySpellweaver the students have no idea that a sprite on the screen can only go forward. What is constrainning it? Yes there is an incomplete metaphor. But we have to start at the beginning. I can see that a way around the problem, is to take them to the playground, and have them pretend to be a turtle. Have some instructions printed, that they can hold. As for words not mattering I have one thing to say to that: Correct horse battery staple. $\endgroup$
    – ctrl-alt-delor
    Commented May 15, 2018 at 10:45
  • $\begingroup$ @GyspySpellweaver moving to the left of the screen, if you are not lucky enough to have a real robotic turtle on the floor. It is a simulation only. $\endgroup$
    – Michel Billaud
    Commented May 15, 2018 at 13:21
  • $\begingroup$ @GypsySpellweaver should we likewise, in literacy class, give examples of poor punctuation, spelling and grammar, because they will see it in the real world. $\endgroup$
    – ctrl-alt-delor
    Commented Jun 25, 2018 at 17:13
2
$\begingroup$

Separate the actual solution, from the code

As you've probably identified, the underlying issue is not that the names are incomprehensible or that the students lack memory in remembering what 4 simple commands do.

Instead, it's that trying to remember your step-by-step solution; and translate it into those 4 commands - becomes too much to handle all at once.

Importantly, by trying to do it all at once, the students give themselves the opportunity to get confused between what actions they can do (turn left, move forward) and the names of the variables (does "left" actually mean we can move left?).

As with any programming task - I'd suggest breaking it back into the two separate phases:

  • Creating a language agnostic solution
  • Translating the solution into code

Firstly, make the problem clear - in non-python terms. You have a turtle that can move forwards, turn-clockwise or anti-clockwise; and you need give it a set of instructions to get to a destination.

This is agnostic of the library used to implement it, or even the fact they will be programming the turtle. As you suggested in the comments - you can have them solve this in person, in the playground, if it's helpful; as it is entirely decoupled from the act of typing code.

This solution should be written, using any natural language they prefer (including diagrams where they feel it's useful). Importantly, it should be complete enough they could pass it to another student - and have them verify it's correct - without ever typing a line of python code.

The benefit of having it written down, is you reduce the amount of things they need to remember at any one stage. As they become more experienced, they will naturally find their need to do this drops - but early on, it is a very good habit to develop.

Once the students have a written solution, in their own choice of natural language (but importantly, written, and not just sitting in thier heads). You can move onto translating their solution into python.

Note that in the translation stage, they should feel that the problem is already solved. This stage should be made clear, that it is a mechanical translation from one language (theirs) to another (python).

Here, although the names may be slightly confusing - it now shouldn't matter. By having them translate their written solution - they are simply looking for the python commands which represent their chosen action. It doesn't matter that "left" sounds like "move left"; as their solution will not contain any references to strafing left (based on the original plain-english problem statement).

Once they have translated their solution, and tested it. It's important again, to emphasise not fixing the bugs directly. At all stages, their written solution should be corrected first, and the actual coding should never be more than translating written language into python code.

With this, hopefully it's clear how the students will develop two separate mental models. One for how to solve problems - given a limited set of instructions - and one for the actual code that represents their solution (which may or may not have intuitive names).

Improve this answer
$\endgroup$
1
  • $\begingroup$ While not directly answering the question, this answer does have a log of value. I suspect that the gap that it discusses, is widened by the use of poor names. The more unlike their native language, the wider the gap will be. Well written python, with good name, can look like english (may be any other language), but with strange punctuation. $\endgroup$
    – ctrl-alt-delor
    Commented Jun 25, 2018 at 17:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.