Innovations in Computer Teaching (2)

Improving the Quality of Teaching and Learning

Ed by John Hart and Martin Smith

Staff and Educational Development Association (SEDA) Paper 91, Sep 1995

A Summary Review

Students struggle with programming. Are we teaching it correctly? What are the barriers to learning?

This collection of papers "...provide[s] a forum for the exchange of ideas, reports and case studies illustrative of good practice in teaching, learning, assessment and related areas [in the area of teaching and learning programming]." While the collection could be considered "historical" (basically pre-Internet), there are some useful insights to be gained from these papers.

Following is a commentary on two of the more interesting articles, followed by a summary of issues raised in the remaining articles.

Object oriented software development education: evolution or revolution?

Finatan Culwin and Alan Hayes, South Bank University (pp 113 ff)

The authors state that they are attempting to "provide and manage a learning environment within which students can rapidly and efficiently obtain the cognitive and practical skills required to produce robust, effective and economical software products."

The debate here is whether programming skills develop best through a Piagetian evolutionary process (from simple experimentation with code through to object oriented programming) or by throwing students in the deep end (a revolutionary process of starting with object oriented programming, or OOP). The authors feel strongly that the former is the better method.

The 'evolutionary paradigm' that they describe has 6 steps (p 114), the first 3 being cases of structured programming while the latter 3 are evolutionary object orinted stages:

• imperative stage (exploring sequence, selection and iteration together with abstract representation of real world states)
• modularised stage (coping with increased complexity by partitioning large programs into sub-programs)
• packaged stage (separate compilation of related subprograms)
• abstract data types (or ADT, export of data structures with suitable operations from a package)
• encapsulated static variables (or ESV, provision of a single state variable hidden within a package)
• object oriented programming (or OOP, combining distinct advantages of ADT and ESV techniques)

The 'revolutionay paradigm' means starting beginner programmers with OOP. The problem with this is that the concept of 'scope' would need to be seen as being simultaneously both limited and global. They feel this would be too difficult except for the most able programmers.

The authors concede that they have not witnessed the 'revolutionay' paradigm first hand and that they are 'potential revolutionaries waiting to be convinced'. (p 117)

Footnote: Where is this debate today? Why is it that many students really struggle with programming? How much research and thought goes into how students learn programming? Why are there still lectures for programming courses? Why is there such resistance to learning programming via something students love to do anyway - gaming?

---

Computer-based teaching of programming: can it be done?

David Jackson, University of Liverpool (pp 103 ff)

This paper examines the difficulties of implementing a computer-based programming teaching package, in particular for distance education purposes. The author rightly criticises CAL software that simply presents information about programming, since this is no better than a textbook.

He considers an automated system which will help beginner programmers by providing valuable feedback about programming errors, in much the same way that a human tutor would do.

Syntax Best not to rely on a compiler since the error reports generated by some syntax error are often vague and confusing. It is better to build (or use) a syntax analyser within the system.

Semantics The author comments on the inadequacy of the typical assessment approach for porgramming - rely on the student to test the program and provide proof it works. If there are anomolies, the tutor normally 'eyeballs' the code to see if he can spot any problems. After examining a few possible automated approaches to checking the output of a program, he concludes that the approach of providing regular feedback as the students builds the code may be the best solution (but it reduces students flexibility).

Style & complexity Good programming style (arguably) requires a consideration of length of identifiers, average number of comment lines, modularity, layout, etc

Conclusion He states that an effective automated system should:

• do syntax checking (by parser or syntax-directed editor)
• test programs thoroughly (with meaningful bug reports)
• provide objective assessment of program comprehensibility, efficiency and maintainability

---

Summary of themes raised in the jounal

• Learning styles to consider when conducting programming classes: activists (I'll try anything once"), reflectors ("Let me think about this"), theorists ("How does this fit with that?"), and pragmatists ("How can I apply this in practice?") (p 37)
• Successful student-centred learning is best achieved when students are given some control over what they learn and can decide whether they are being successful in learning. A well-planned self-assessment system is advantageous here. (p 54)
• Re-use of code (Is using some-one else's code cheating? If it was written well, why not? Should everything be open source?) (p121)
• Group working is an effective technique for learning and practicing software development (p 126)
• Documentation writing is best done in tandem with the code development and to teach this, appoint students as 'documentation specialists' in a case-study scenario (p 130)

Be the first to comment below.