Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
about learning a concept that has a problematic name
about learning a concept that has a problematic name
1) it's important to learn some concept and a name for it
2) the name is problematic in some fashion
1) learn the concept appropriately
2) be able to use a name for it appropriately
problematic names: examples and discussion
example scenario 1:
the terms "real number" and "imaginary number" in mathematics may have been
a cause of confusion for some. someone confused by these terms might
eventually realize that names can be arbitrary labels sometimes. it's
possible that the original intent of the name wasn't to be arbitrary, but
over time definitions may change while labels may stay the same. i think this
may have been the case for these two terms. i would guess that to at least
some working mathematicians, these terms are just seen as technical labels.
some might believe that "real numbers" are somehow more "real" than "imaginary
numbers", but my guess is that this would not be the case to many
mathematicians. rather, they might view both concepts as equally real or
imaginary in the more conventional use of the terms.
example scenario 2:
situations involving propaganda might involve using common or specific terms
in deceptive ways to achieve certain ends. these sorts of things might be
good examples of exploiting a human being's tendency to "read into" labels.
example scenario 3:
"car" and "cdr" (lisp terms) are sometimes used as examples of poor naming.
perhaps one aspect of the names being considered less than ideal is that the
names seem arbitrary. a popular account of the origin of these names is
that they had something to do with a particular computer. supposedly, the
names made some sort of sense at one point.
it appears that some people are unaware of the origins of the names
"car" and "cdr" and hence to them, the names might seem random. compared to
some of the names from example scenarios 1 and 2 though, these names don't
appear to suffer the issue of being misleading.
another example might be the term "window" in emacs. before this term
became widespread, emacs had been using it to mean something different.
in emacs lingo, "frame" corresponds more closely to what many might
think "window" means.
thus for a newcomer to emacs who is familiar with the term "window" in
a different sense, "window" in the world of emacs can be misleading as it
refers to something else.
misleading names are problematic for at least the following reasons:
1) if one doesn't use them for a while (and thus becomes vague about them
or forget what they mean) and revisits them in the future, they may
cause confusion again
2) even if one doesn't forget the actual names, it may be difficult to avoid
inappropriate associations surfacing, so one can repeatedly receive
unwanted mental feedback. (propaganda may be deliberately making use of
this aspect.)
3) communication with others can be less smooth because of the likely higher
incidence of misunderstandings. even trying to prevent such things
may lead to extra communication, making things less efficient.
one term i've found misleading from physics is "electromotive force". as
far i remember, this is not actually a force. each time i think of the
term "electromotive force" i potentially mislead myself. luckily i can think
of "emf" instead.
another misleading name might be clojure's "contains?". the clojuredocs
page for it has some evidence that some expected it to do something it does
how might we cope with learning when names are "poor"?
for someone interested in learning concepts, it might be preferrable to
not be exposed to certain labels initially. it's possible to discuss
certain concepts without naming them first.
if there is a knowledgable person who feels inclined toward teaching a
target concept, may be it's possible to get them to introduce the ideas
without reference to the poor name(s). (perhaps there is some connection
with "explain like i'm 5")
if there isn't a knowledgable person around, possibly material might be
edited to replace a poor name with some arbitrary one. alternatively,
seeking more appropriate material might be an option. if one knows a
"foreign" language where the problematic term is not used, trying to
learn in another language might be another approach.
this last idea suggests another course of action that might be helpful once
there is some level of familiarity with a new concept -- the deliberate
search for additional names. memory might be aided, but another benefit might
be that internally one can choose to use a label that seems more appropriate.
some observations
once a certain degree of comfort with the concept is achieved, perhaps the
original name can be "resurfaced".
the important point here is to shield people from the name as much as
possible initially. early exposure may have the following undesirable
1) any extra element introduced may increase additional cognitive burden
simply because there is more to cope with. if the concept can be
discussed using only existing knowledge, there is less newness compared
to an additional label. (perhaps there is some relationship to the
magical number seven plus or minus two)
2) a poor name may evoke inappropriate / misleading associations. it may
be difficult for the one trying to learn to discern what is important to
pay attention to and what should be ignored.
the second point above about evoking associations is very much something i
think maro would appreciate, especially because of his understanding of
leveraging people's existing "know-how" (see his article on piggybacking).
he chooses specific names with the idea to utilize knowledge that is likely
to already be in his audience.
note that he gets to choose names carefully. for our discussion above, we do
not get to choose the names as we are trying to learn about something that
already has a name.
examples that try to address the issue
* this book: seems to apply a similar approach in parts
possibly related
Code-first approaches for introducing students to CS exclude those without
preparatory privilege in programming and those intimidated by coding.
Delaying coding or not using coding in an introductory CS course provides
an equitable learning opportunity and includes a broader group of students
in computational education. We present a study that compares a traditional
Python code-first approach with an approach to delay or remove coding by
first using simple, well-known stories to explain computation without the
need for a computer or coding. We find that many students, especially female
students and those without prior programming, are initially not interested
in coding but in using stories to explain computing. We conclude that a
traditional Python code-first approach excludes these students and an option
using stories is a viable alternative.
Abstract of "To Code or Not to Code? Programming in Introductory CS Courses"
by Jennifer Parham-Mocello, Martin Erwig, Emily Dominguez
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment