Functional abstraction

Functional abstraction is a very subtle concept which is considered a vital part of any design task by many researchers (e.g. Sooriamurthi, 2001). In short, it is about the ability to distinguish between functioning and functionality levels. Papert (1985) in Mindstorms describes it as the difference between the ability to drive a car and knowing how the engine works. The concept of functional abstraction is central to both understanding and applying the recursive procedures and functions. It is also vital in any design process (Sooriamurthi, 2001; Muramatsu and Pratt, 2001; Ginat and Shifroni, 1999, Kurland and Pea, 1985).

Sooriamurthi (2001) has studied the difficulties of undergraduate students in understanding recursion. He attributes this to an“… inadequate appreciation of the concept of functional abstraction” (p. 25).The key idea is that programming is a new way of thinking, and it is more about design and problem-solving than the syntactical perspectives of programming languages. Moreover, in programming, the management of complexities is vital. Sooriamurthi (2001) argues that when you cannot master the complexity, you need to handle it by using a divide and conquer strategy or abstraction. Abstraction is simply focusing on what needs to be done and, for the short-term, suspending how it is

going to be done. Most students have difficulty in distinguishing the “what” part and the “how” part. Sooriamurthi (2001) argues that:

“The issue is simply separation of concerns: the separation of what needs to be done from how it will be done. We observed that students normally have a hard time comprehending recursion because they don‟t clearly differentiate between these two forms of knowledge (the what vs. the how) and worse, tend to focus on the latter – the how. The key to comprehending any form of abstraction including recursion is to focus on the what and down play the how.” (p. 25)

From this perspective, we can make a link between functional abstraction and declarative – imperative programming paradigms that have already been mentioned in this chapter.

The aforementioned declarative programming paradigm is about „what something is like‟ rather than how it is going to be created. Anderson, Pirolli

and Farrell (1988) have also pointed to this important issue in tracking the flow between the recursive calls. They suggest that “[…] it is often useful to

determine what has to be done to the result produced by a recursive call in order to get a result for the current function call” (p. 163). The difference between these two levels (the „what‟ vs. the „how‟) is vital and important. I

think focusing on this concept from the point of view of the learning and design of computer-based tools needs to be further pondered. What I am trying

to say is that to drive a car, a learner does not necessarily need to know anything about the engine and its function. However, knowing about the functioning of the engine might help the learner to develop his driving skill regarding the engine‟s response in different driving situations. Therefore, to

acquire a certain skill in general, it is not necessary to know about the how. Instead, one needs to know about the what.

When it comes to learning a particular mathematical concept, we are not generally able to understand the concept by focusing only on the what. This is the case with some mathematical concepts like dividing fractions (“turn upside down and multiply”), or mathematical induction (“check that p(n) is true for

some natural n, now if for any natural n, p(n) implies p(n+1) then p(n) is always true”). From a problem-solving perspective, one should bear in mind

whether our purpose is the final answer or whether the process of reaching it is the key issue. Nevertheless, if finding the final answer to the question is the purpose of a problem-solving strategy, there would be no place for the functioning dimension of functional abstraction. For instance, acquiring the skill of dividing two fractions can be grasped instrumentally (Skemp, 1976) in a very quick and exact way i.e. turning it upside down and multiplying it. It is very difficult and hard to say that the learner will have a clear understanding about (½) ÷ (¼), which equals two. It may also be that finding the final answer is not as easy as the above example.

Solving the questions by using recursion as a problem-solving strategy is one of those situations in which reaching a final answer without having a proficient

knowledge of the functioning level is not an easy task. Thus, the major point regarding the concept of functional abstraction is to what extent one should focus on the functioning level and to what extent the focus should be on functionality in the learning and teaching of mathematical concepts. Concentrating on this query is beyond the scope of this research. However, with regard to the concept of recursion, due to its complex character, like its complicated control passing process, one needs to ponder on the functioning level, as well as its functionality.

Another essential issue in this realm is distinguishing between the design of the computer-based tools and the learning and understanding of the concept of recursion (Table 1).

Table 1- Separation of tool design and recursion from functional abstraction view

One might consider it as an obvious and trivial issue, but there are vital differences between them. From a computer-based design stance there is usually no need for the students to know anything about the functioning aspects of the tool design, or, how the tool works, but inevitably it is important that the

functioning functionality

Computer-based tool design

How it is designed What is it going to do

Concept of recursion

student learns its functionality; what the tool does. Sooriamurthi (2001) stated that:

Functional abstraction is a corner stone strategy in good software design. To master recursion is to master and acquire a fundamental understanding of functional abstraction. (p. 25)

At this stage I would like to consider the literature from a wider perspective. This helps me to analyze the students‟ thinking about the concept of recursion.

Also, it enables me to investigate the role and impact of computer-based tools in teaching, learning recursion. In doing so, it is necessary that I review the literature on students‟ mental models of recursion, situated cognition and

conceptual changes. These are the issues that are explained in the next part of this chapter.

PART THREE

This part of the review of the literature is divided into two sections. The first section concentrates on a brief review of the history and research that has been taken on mental models in general. The second section focuses on the research that undertaken on the mental models of recursion in particular.