This chapter on frontiers contains discussions leading to questions for research in computer science education that follow from the literature and our ideas and experience with courses and the material in this book.
As mentioned in our Preface.
We accept abstraction and particularization to be two of the many different intellectual tools that computer scientists have at their disposal. Our goals include enabling our students to deploy all every helpful approach and avoid an attitude to refuse to practice something for dogmatic reasons or because of misapprehensions taken to be excuses for laziness (huh? what did I have in mind here? Not solve the problem of using a new topic because an older or easier one is available?). One big challenge is to combine or juxtapose multiple attitudes so they reinforce one another and not lose effectiveness through confusion and contradiction.
We call to mind the following quotation from the preface of Ward and Halstead's Computation Structures textbook:
Outstanding students, in contrast, somehow develop a perspective that illuminates the interfaces between technologies, rather than the technologies themselves as the most important structural elements of their discipline.
They view interfaces with the respect but not reverence; they examine both sides of an abstraction, treating it as an object of study rather than a boundary between the known and the intractably mystical. They have discovered the power their own universality; typically they of have built complete systems, often with meager resources, and made them work. They have the sophistication, and most importantly the self-assurance, to explore new abstractions and to appreciate the role and costs of existing ones.
Here is an example of what we must avoid when providing motivations for abstractions. In the first offering of a new version of our data structures, linked lists were motivated as an appropriate structure for musical songs composed of notes. Our instructor teaching "Programming at the Hardware/Software Interface" where C and assembly language is covered found that several students from that course believed that linked lists could only store notes, and not integers!
On the other hand, a too general exposition of subclasses of collections will leave some students unable to discern relationships between the implementations and requirements pertaining to sequenced storage.
We identify the (perhaps too broad) goal of leaving our students with the ability to imagine what is happening inside a computer in terms of models that are necessary and helpful to solve increasingly complex and subtle problems.
It is often said that abstract thinking is difficult. Is there a taxonomy of abstractions that is useful for addressing their difficulties? "Abstract" is an overused word: It applies to properties such as justice as well as categories such as data type. And the same thing, such as a particular code's loop invariant, is highly concrete to some people and highly abstract to others.
The dynamic structure of computations is different from the static structure of programs. [Challenges identified by Guzdial's "State of CS Education", U. Toronto Nov. 22, 2010] says that texts and lectures teach structure (of programs) and function but not behavior. How can an understanding of behavior be taught? Understanding includes asking the right questions to be answered by imagined simulation or observation of behavior. Guzdial cites Ashok Goel who developed this three way analysis for doing and teaching engineering.
Distinctions and connections between static and dynamic structure are important and difficult in object oriented programming. Both type hierarchy (inheritance) and object relations (expressed by containment and by association) are expressed both statically and dynamically. The fact that static and dynamic structure coexist results in the problems that require their distinction becoming intrinsically difficult! [Do we need elaboration and examples here? More importantly, content addressing the difficulties must be written!]
Guzdial also recognized that students have trouble with the simplest things (how arrays work, how to read code, how to sequence code, difference between while and if), not just more advanced things (objects, design, recursion, data structures.) He called this the "phonics of CS". How can this be addressed? How can we avoid boring students after they have gotten this?
Guzdial (?) recognized the infeasibility of Dijkstra's approach of carefully controlling the sequence in which students are exposed to the discipline. How can an educator effectively develop a useful intellectual structure for the quite complicated discipline?
Here is one example of the challenge: The concept of the class in fact been articulated into a diverse collection of programming language artifacts and different kinds of units useful for design processes. From the pure concept of an abstract data type, the class has been concretely realized as a blueprint for object allocation and container for implementations of data state and operations. But the class also functions as a unit for modular program design. In practical systems, the class appears initially as a container for the application program or, perhaps more purely, the base type for an applet. The features of class (i.e., static) data and method members, and of nested classes (whether they be inner or static) illustrate even better that the class is both a unit of modularization and a data type.
This diversity of motivations, or more accurately, applications of the class concept [of classes as they appear in modern object-oriented programming systems] is manifest in the fairly large and complex collection of the famous "Gang of Four" design patterns. At what point do students become ready to relate their experience with sequenced and conditionalized operations on data, especially with programming of externally specified behavior and its attendant challenges of design-in the-small and debugging, to effective utilization of today's design pattern and other software engineering methodologies?
Finally, it must be recognized that the role of the class within non-trivial software designs is not (as usually expressed conventionally) to model a category of real-world entities, or even categories of information entities residing outside the operating software. The class is in fact a unit for organizing information, more accurately, state, internally within the software; perhaps providing support for persistence or synchronization with external databases or other interfaces. Thus the methods of a class are in fact specifications and implementations for data processing operations, not, in many important applications today, models for real-world behavior. We reflect that this is true for the principles and practice of object-oriented programming today, despite the origins of the class concept in systems developed for simulation applications.
It is our experience in one-on-one discussions with students about data structures problems that the student reply of yes or no to the question of whether they use data structure box-and-pointer diagrams to solve the programming problems correlates almost universally with how fluently the student can solve the problems. However, we also encounter students who are successful in advanced computer science but both have trouble with the memory model in for example, C programming, and who claim to be unable to "think in pictures". We believe that certain stereotyped diagrammatic problem solving methods (yet to be completely codified) are the most effective for certain important problem solving skills. The consequential question is how can such diagrammatic modes of thinking be taught. Of course, the modes that the learner comes in with must be taken into account when new things to imagine are introduced and motivated. The hard part is the details!
There is literature on diagrammatic thinking but none we found (yet) directly addresses data structure programming problems. We accept that the goal is not primarily to use a particular stereotype but rather it is to enable the learner to imagine what is happening inside the computer in terms of a model that is effective for solving the problems at hand.
We also keep in mind (recognize?) the limitation that diagrammatic problem solving methods that are effective for learning and for small problems do not scale up for more complex and realistic problems. In our discipline, system and algorithm understanding also relies upon precisely expressed verbal or formalized invariants, plus a sophisticated combination of interrelated abstractions.
How is it best to make the trade-off for instructional resources between details necessary for productive practice of particular technology and general principles? How is the ability to handle details, including efficient use of documentation, developed alongside the development of abilities of decomposition and abstraction? How can the boundary between "germane" and "extraneous" cognitive load be managed and how does it evolve?
What is the role of fluid intelligence, as discussed by Vali Siadat in "Doceamus: Using Mathematics to Improve Fluid Intelligence" page 432 in the March 2011 issue of the Notices of the AMS?
Is there an innate cognitive ability that is necessary for fluid ability to solve problems that involve indirect information reference (shall we call that "referential identity"?) beyond a small number of dereferencing steps, say 1 or 2?
Quotation from Joel Spolsky The Guerilla Guide to Interviewing (Version 3)
15 years of experience interviewing programmers has convinced me that the best programmers all have an easy aptitude for dealing with multiple levels of abstraction simultaneously. In programming, that means specifically that they have no problem with recursion (which involves holding in your head multiple levels of the call stack at the same time) or complex pointer-based algorithms (where the address of an object is sort of like an abstract representation of the object itself).
I’ve come to realize that understanding pointers in C is not a skill, it’s an aptitude. In first year computer science classes, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their PCs when they were 4 years old. They are having a good ol’ time learning C or Pascal in college, until one day they professor introduces pointers, and suddenly, they don’t get it. They just don’t understand anything any more. 90% of the class goes off and becomes Political Science majors, then they tell their friends that there weren’t enough good looking members of the appropriate sex in their CompSci classes, that’s why they switched. For some reason most people seem to be born without the part of the brain that understands pointers. Pointers require a complex form of doubly-indirected thinking that some people just can’t do, and it’s pretty crucial to good programming. A lot of the “script jocks” who started programming by copying JavaScript snippets into their web pages and went on to learn Perl never learned about pointers, and they can never quite produce code of the quality you need.
Spolsky's language may hold a clue: "the address of an object is sort of like an abstract representation of the object itself". Such phraseology ("sort of like") frustrates a professor's ear! Spolsky is no stranger to the relevant logically rigorous definitions. His informal usage reveals the fact that a rigorous exposition is useless to those who don't already have the intuition, innate or not. (He further writes in the article that watered down curricula don't fairly prepare interviewed candidates for the difficult questions necessary to accurately probe their aptitude. This is clearly consistent with the truism that innate aptitudes are useless without sustained development.)
The address is different in both type and content from the object itself, yet the skillful programmer's mind must on occasion rapidly identify the address with the object. The distinction between the address and object is important when thinking about the state of a variable that would contain the address. The distinction is distracting when thinking about the behavior or the state of the object itself. Yet in linked list and yet more complex recursively structured data structures, the objects are composed of one or more variables holding addresses of the same class of objects. Both the distinction (between the address and the object) and the identification must conceptually available simultaneously!
Is discussion or explanation like mine, with its metaphysical flavor, of any demonstrable use in developing whatever latent aptitudes into skills? Can the reports of Spolsky and others be confirmed and refined, or denied, by rigorous cognitive science research? In what other cognitive aptitudes are correlated with the aptitudes for indirection and recursion discussed by Spolsky? [Re-find and cite research (in the UK?) on programming aptitude related to (1) styles of map drawing and (2) consistent application of unfamiliar assignment operations.] What cognitive tasks besides computer programming employ such aptitudes?
Can testable cognitive capabilities be identified and categorized for their support of disciplinary skills? To clarify what I mean here, I will draw the analogy from the capability of perfect pitch. (1) Some people have perfect pitch and others don't. (2) Perfect pitch is neither a necessary nor sufficient capability for excellence in understanding or performing music. However, accurate recognition and reproduction of intervals (differences between two pitches) is learnable and necessary (references?) Choruses and orchestras are always given a tuning note before performing. The analog is that some people might be able to visualize many inter-referring objects and others might not, but people with weaker capability here can compensate by using memory aids like scratch paper.
A further practical question for universities is what are most socially and institutionally beneficial curricula for large numbers of students who somehow fail to qualify as potentially master programmers yet hold definite motivations for information technology professions?
Joel Spolsky further writes in Where do These People Get Their (Unoriginal) Ideas?
We all know that knowledge workers work best by getting into "flow", also known as being "in the zone", where they are fully concentrated on their work and fully tuned out of their environment. They lose track of time and produce great stuff through absolute concentration. This is when they get all of their productive work done. Writers, programmers, scientists, and even basketball players will tell you about being in the zone.
and scenes from the movie The Social Network report the relationship between "flow" ("being in the zone") and programmer productivity. Is that helpful, or is it almost necessary, for effective learning? Is the conventional advice to start early and work in multiple, fairly short sessions really the best advice for learning these subjects? Or is the more common student practice of working for 8 or more hours straight for a typical programming assignment in fact the best way to achieve its learning objectives? Is it in fact better because it is more natural for the task?
We feel guided by inductive thinking when solving problems. Is the ability to effectively employ such strategies an example of what is learned implicitly (relate or move implicit learning remarks from the preface)? How can such strategic thinking be best encouraged?
The recent book The Information by James Gleick (2011) surveys Luria's studies of how people from non-literate cultures "lack the categories that become second nature even to illiterate people in literate cultures". Such people "could not, or would not, accept logical syllogisms". Gleick continues on to paradoxes due to relationships between words themselves and their meanings that puzzled early philosophers. Could it be that some categories for the data manipulated by computer programs have not yet pervaded common language enough for average students to master the reasoning processes needed for programming without extraordinary training? While literacy automatically instills the concept that written or digitally stored data is about real things (or categories thereof), the concept of data referring to just data may well be one of those concepts few people today find natural, like how syllogistic reasoning was shown by Luria to be strange for members of preliterate cultures.
This problem cannot be addressed merely by more attention being given to vocabulary. Programming is a mathematical kind of subject, although modern mathematical approaches are mostly inappropriate for beginners, and are certainly not practical universal tools in its practice. Mastery of mathematical kinds of subjects requires some kind of non-verbalized conceptual architecture (??) and thinking abilities which somehow emerge after initial and continuing education in terms of unusually precise (rigorous) verbalized communication together with personally engaged intellectual practice. [Eidetic learning/hermeneutic circle stuff?] Just as "there is no royal road to geometry", there isn't any to programming. However, researchers and educators in all mathematical kinds of subject do not and should not give up.
[Report in mid 2010 New York Times about how different languages force their users to think in different ways. Yet not restricting other ways(?). Differences from views of Steven Pinker?]
James Gleick's book The Information cites Bertrand Russell writing about the work of Georg Boole. We quote the entire paragraph from Russell's essay "Mathematics and the Metaphysicians" (written in 1902):
Pure mathematics was discovered by Boole, in a work which he called the Laws of Thought (1854). This work abounds in asseverations that are not mathematical, the fact being that Boole was too modest to suppose his book the first ever written on mathematics. He was also mistaken in supposing that he was dealing with the laws of thought: the question how people actually think was quite irrelevant to him, and if his book had really contained the laws of thought, it was curious that no one should ever have thought in such a way before. His book was in fact concerted with formal logic, and that is the same thing as mathematics[emphasis added].
Pure mathematics consists entirely of assertions to the effect that, if such and such a proposition is true of anything, then such and such a proposition is true of that thing. It is essential not to discuss whether the first proposition is really true, and not to mention what the anything is, of which is is supposed to be true. Both these points belong to applied mathematics. ...
Russell's review of logic, thinking and pure mathematics calls into question how effective is the reduction of the teaching of computer programming, thinking about computation and of computer science to more or less formalized presentations in mathematics, especially at the elementary stages. Precise logical thinking is a skill that must be taught, not an automatic capability (like use and understanding of everyday language) that can be relied upon to clearly communicate unfamiliar facts, relationships and consequences.
[Maybe write about how mathematicians are really Platonists citing "Speaking with the Natives: Reflections on Mathematical Communication" by Gerald B. Folland in Notices of the AMS, October 2010, Volume 57, Number 9, pp. 1121-1125 who imagine a world that is quite concrete to them, and how a similar kind of imagination must be developed for thinking about computation.]
Theoretically well-formulated knowledge is fields like mathematics or physics is very effectively communicated in a logically complete form. See for example Einstein's 1905 paper on relativity in which the meaning of time coordinates is exhaustively layed out prior to being utilized in now-familiar formulas. Such presentations are used both by beginning learners and by experts. But it must also be noted that such details are forgotten, become implicit, and are sometime unnecessary for effective applications. Choosing the correct formulas, calculations and formulations for a problem at hand becomes a skill.
Which are most effective, and how do the more effective aids vary with the kind of goal?
Aid ideas to experiment with:
What is effective to include in courses for students to adapt? A first category is practices that encourage "meta-cognition", meaning that the student consciously reflects on a learing process. An example of a practice in this category is "cards to describe the
essentials about something you do or something you produce when developing software," attributed to Brian Kerr and Ian Spence in the UML chapter of Masterminds of Programming, by Federico Biancuzzi and Shane Warren, O'Reilly Press, 2007.
The 2007 SIGCSE paper "Debugging: The Good, the Bad, and the Quirky –
a Qualitative Analysis of Novices’ Strategies" by Murphy, Lewandowski, McCauley, Simen, Thomas and Zander lists debugging strategies and reports a study of 21 students to observe and categorize their debugging behavior. To quote from the authors' conclusion:
Many unproductive activities appeared to stem from insufficient
meta-cognition. Some students did not recognize when they were
stuck, thus they did not know to try a different approach. Those
who stubbornly traced in their heads often did not realize they
were suffering from cognitive overload and might be more productive
if they tracked on paper or via print statements. Others
were blind to alternative bug sources. Debugging instruction
should incorporate these meta-cognitive factors, perhaps taking
the form of self-questions: “What else could I try?’, “Is this too
much to keep track of in my head?”, and “What are other possible
sources of the bug?”
Explicit teaching of processes for students to reflect on their own learning and disciplinary experiences is suggested, as it is from a lot of other research literature. We add here that we should experiment with exposing students to research literature itself such as the above cited paper.
"Debugging is difficult for novice programmers. Similar to new drivers who must learn to steer, accelerate, brake, etc. all at once, novice debuggers must apply many new skills simultaneously. They must understand the operation of the intended program and the execution of the actual (buggy) program; have general programming expertise and an understanding of the programming language; comprehend the application domain; and have knowledge of bugs and debugging methods [2]. Unfortunately, most novices’ knowledge of these skills is fragile at best [12], causing many to find debugging difficult and frustrating."
Recent Articles that do not mention the huge difficulty difference between pre-indirection and recursion programming and those topics:
Vennila Ramalingam, Deborah LaBelle, and Susan Wiedenbeck. 2004. Self-efficacy and mental models in learning to program. SIGCSE Bull. 36, 3 (June 2004), 171-175. DOI=10.1145/1026487.1008042 http://doi.acm.org/10.1145/1026487.1008042
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.155.3971&rep=rep1&type=pdf An Exploration of Internal Factors Influencing Student Learning of
Programming Angela Carbone, John Hurst, Ian Mitchell, Dick Gunstone
More promising:http://www.crpit.com/confpapers/CRPITV88Sorva.pdf Cites "phenomenography"
this cites: Holland, S., Griffiths, R. & Woodman, M. (1997),
‘Avoiding object misconceptions’, SIGCSE Bulletin
29(1), 131–134.
AND: Ragonis, N. & Ben-Ari, M. (2005), ‘A long-term investigation
of the comprehension of OOP concepts by
novices.’, Computer Science Education 15(3), 203 –
221.
AND : Adcock, B., Bucci, P., Heym, W. D., Hollingsworth, J. E.,
Long, T. & Weide, B. W. (2007), ‘Which pointer errors
do students make?’, SIGCSE Bulletin 39(1), 9–13. which might be getting closer..must look
There has been error in communication with booki server. Not sure right now where is the problem.
You should refresh this page.