month is to say the value (but not the
variable) can be derived elsewhere. Because variables “go away” when values
are substituted, a common view of a
variable is as a “placeholder.” What is
it holding a place for? For a predicate?
For a proposition? For an entity? In
other words, what is the shape or category of a variable? Is it an attribute of
something, a whole statement about
something, or the something itself?
Again, in a program (or in its formalization in denotational semantics),
this is clear; the difference between
variable and value is embedded firmly
in the process.
˲ What about the multiple instan-tiations, the fact that all occurrences
of a variable are bound to the same
value? To say “that variable has a misleading name” is to condemn several
substrings of code. How would we
include that aspect (also straightforward in a formal semantics) in a comprehensive definition?
˲ Is a variable something we know or
something we don’t know? An algebraic
definition of a variable is as an “
unknown.” Yet we know a lot about a variable x that appears in an equation such
as f(x) = ax2 + bx + c. We know that it
is an object suitable for such a setting,
that is, a number, and that it belongs
right there, and that its value is constrained by the given relations to other
values. What’s unknown is which number. We always “know” the variable in
the rather weak sense that we grasp
its need and purpose. In a program, a
variable’s value is something that we
don’t know in the source code, the human product. In the execution, as soon
as it’s bound, the value is “known” in
some sense, but to what or whom?
The art of definition has a philosophy of its own.
5 Experts in that realm
would not be surprised to encounter
difficulties, but computer scientists
might be surprised at the subtle and
complex issues that come from a mundane and familiar idea.
1. Buffalo Ontology Site. State University of New York at
2. Kent, W. Data and Reality, North-Holland Publishing
Company, Chapter 5.0, Attributes.
3. McKay, D. Information, Mechanism and Meaning, MIT
4. Noy, N. F., and McGuinness, D. L. Ontology Development
101: A Guide to Creating Your First Ontology
5. Gupta, A. Definitions, The Stanford Encyclopedia of
Philosophy, Edward N. Zalta, editor.
6. Smith, B. Beyond concepts: ontology as reality
representation. In Proceedings of the Third International
Conference on Formal Ontology in Information Systems
(FOIS 2004), IOS Press, pp. 73-84.
7. Smith, B. Ontology (science). Formal Ontology in
Information Systems, Eschenbach, C. and Grüninger,
M., eds. In Proceedings of the Fifth International
Conference on Formal Ontology in Information
Systems (FOIS 2008). IOS Press, pp. 21-35.
http://bit.ly/2TBynOB, DOI: 10.3233/978-1-58603-
Direct Instruction Is
Better Than Discovery,
But What Should We Be
November 7, 2018
I recently discovered Felienne Hermans’ blog. In her latest post, she
talks about the research around direct instruction and how it relates to
programming. The research evidence
is growing that students learn better
through direct instruction rather than
through a discovery-based method,
where we expect students to figure
things out for themselves.
Direct instruction is hot! Whereas in
the 1990s we heard a lot about discovering learning, we are now slowly seeing a
renewed interest in the ‘direct instruction model’ in the Netherlands. Both in
language and in mathematics there is
a new interest in rote practice of knowledge (“stampen,” http://bit.ly/2D5pRAa).
As that is not a surprise, since research
keeps showing that direct instruction—explanation followed by a lot of
focused practice—works well (https://
nyti.ms/2HQbd5n). It not only works
well, it also equalizes: it does not matter
what knowledge children already have
(received at home), everyone has equal
chances to acquire the basic knowledge.
That is why research also shows that direct instruction works especially well for
weaker pupils ( http://bit.ly/1BASeOh).
Her point resonates strongly with
me. I argued here in Blog@CACM last
year ( http://bit.ly/2RzDDQR) that we
should reduce the amount that we
tell students to just “figure out” in CS
classes. We should teach students directly (Hermans’ point), and reduce (at
least in the first classes) the amount
of design and problem-solving we ask
students to do.
But what should we be teaching
directly? The obvious answer is “the
programming language.” But there’s
a good bit of evidence that students
do not learn the syntax and semantics
of programming directly. Kelly Rivers
had a paper at ICER 2016 (http://bit.
ly/2BhtuDa) that I found fascinating.
She studied how students learned pro-
gramming structures, and found that
they didn’t. They actually made more
errors with FOR loops over the course
of the semester. Of course, the students
were learning, but you can’t measure
their learning in terms of syntax and
semantics of programming. They’re
learning something else.
Elliot Soloway and Jim Spohrer argued back in the 1980s that students
don’t learn programming in terms
of syntax and semantics (see the CHI
1986 paper at http://bit.ly/1BASeOh).
Rather, students were learning plans,
useful chunks of code. Within those
chunks were programming statements, but students were learning
that set of statements, not the individual statements. Maybe we should be
teaching those plans?
John Sweller argues we should be
teaching programming with lots of
worked examples. He argues that too
much emphasis on problem-solving
leads to increased cognitive load,
which interferes with learning. Worked
examples are completely worked out
programs that students study, typically
including questions that students answer about the program. The worked-example effect ( http://bit.ly/2MPGjZJ)
describes how worked examples lead
to better learning than more problem-solving. For Sweller, worked examples
are part of effective direct instruction
I am a follower of the research Hermans is citing in her blog post, and
agree that direct instruction is better
than discovery learning for introductory
courses. We are still figuring out what
direct instruction means in learning to
program. I do not think it is about programming languages. I expect that it is
more about plans, and that the methods should involve worked examples.
Robin K. Hill is a lecturer in the Department of Computer
Science and an affiliate of both the Department of
Philosophy and Religious Studies and the Wyoming
Institute for Humanities Research at the University of
Wyoming. Mark Guzdial is a professor in the Computer
Science & Engineering Division of the Engineering
Education Research program at the University of Michigan.
© 2019 ACM 0001-0782/19/4 $15.00