Communications of the ACM

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.

References

1. Buffalo Ontology Site. State University of New York at Buffalo http://ontology.buffalo.edu/

2. Kent, W. Data and Reality, North-Holland Publishing Company, Chapter 5.0, Attributes.

3. McKay, D. Information, Mechanism and Meaning, MIT Press, 1969

4. Noy, N. F., and McGuinness, D. L. Ontology Development 101: A Guide to Creating Your First Ontology https://stanford.io/2HTnfLl

5. Gupta, A. Definitions, The Stanford Encyclopedia of
Philosophy, Edward N. Zalta, editor.
https://stanford.io/2D5Qhls
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- 923-3-21

Mark Guzdial
Direct Instruction Is
Better Than Discovery,
But What Should We Be
Directly Instructing?
http://bit.ly/2ARuUTA
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 for programming.

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.