Teaching Programming to Beginners choosing ... - ACM Digital Library

Teaching Programming to Beginners choosing the language is just the first step Roger Duke, Eric Salzman, Jay Burmeister, Josiah Poon and Leesa Murray School of Computer Science and Electrical Engineering University of Queensland Brisbane, Queensland Australia {rduke, eric, jay, josiah, leesam}@csee.uq.edu.au Abstract

Such considerations are (unfortunately) of increasing importance with the current emphasis on competition between universities for students and income. In this paper we will argue that, regardless of the considerations underlying the reasons, moving to Java has been very successful, but only because at the same time we decided to re-evaluate our entire approach to teaching programming to beginners. Choosing the Java language was just the first step.

Over the years there has been an ongoing debate about which computer language to adopt for a first programming subject. Although some may not agree, the current consensus is that the object.oriented languages are winning the argument, and Java has increasingly become the language of choice for teaching beginners. But choosing the language is only the first step in designing a first programming subject. The adoption of an object-oriented language such as Java offers an opportunity to completely rethink our approach to teaching first-year programming, an opportunity that should not be missed. In this paper we identify what we see as the non language-specific core issues, and discuss how we approached these issues when designing and teaching a programming subject for beginners.

2

1 Introduction In the middle of 1998 the decision was taken to move to Java as the language for our one-semester first-year programming subject. The decision was based, as is often the case, not just on academic grounds but on pragmatic considerations. A couple of years earlier we had accepted the arguments for adopting an object-oriented approach and had designed our first-year prograr.nming around the Smalltalk language [5]. Despite the fact that the Smalltalk subject had been generally well received by students, Java was seen as a more modern language with direct commercial appeal. It was feltthat teaching Java would enable the Department to attract and keep more students.

Peram m mike digial or h n t copks of tll or im~rtof this work fi~" ] m m l or c l m m o m mm is tp'mmmd~vJtho~ ~m ~ovidcd th~ ~opies m not nmde or distn~umd for ps~fit or cormnmrcial advanUtge, and that copies bern"this notice 8rid the full citation on tl~ flsst page. To copy otherwise, to republish, m post on ms~nrs or to mdism~um to lira. reqa~zs Wior specific pera,ssiou and/or ~ Sin. ACE 2000 12/00 Me~ocmm, Au~ml/a 0 2000 ACM I-$811~271-9/00/0012 ... S$.00

The Overall Approach

Leaving aside specific technical issues, we believe the overall aim of a firstprogramming subject is to explore the art, science and pleasure of programming by taking an experiential approach [4]. It was important to us at the beginning to reiterate our belief that programming can be an exciting and rewarding experience, and programming in Java in particular can be a lot of fun. W e wanted to design a subject that would introduce the fundamentals of Java programming but do it in an enjoyable and exciting way. In particular, we wanted to encourage the student to: Explore Be curious and look for new things to discover. If something is puzzling, explore it and try to understand it. Experiment Try new things and see what happens. Form hypotheses about why code works; make changes to code and observe what happens; based on observation, either confirm or change hypotheses and continue to experiment. Use the computer as an experimental instrument.

Experience Run code as part of the process of understanding and using it. Try modifying the code in various ways to discover the effect. Realise that programming is a skill based on practical experience.

79

Extend Emulate existing code when creating new applications. Discover that code reuse and extension is an invaluable programming skill. In formulating a strategy to achieve these broad goals, we identified three distinct but interwoven core ideas: problem based learning, [2, 8, 13], flexiblelearning and the inverse curriculum [5, 12]. None of these ideas are at all new, but the object-oriented nature of the Java language together with its comprehensive libraries of existing classes enables these ideas to be merged into a cohesive teaching strategy. 2.1

Problem Based Learning

It is obvious that it is only through practice that a computer language, like any language, can be mastered. With this in mind we began a thorough review of the available Java books looking for one that adopted at least a problem-oriented approach. Given the large number of Java books it came as a suprise that, although many of them are excellent in their own way, we were unable to find a text whose approach to Java was in sympathy with the way we felt it should be presented to beginners. Most books come with problems, of course, but rather than an integral part of the text they are appended to the end of chapters like some optional extra. Consequently, we decided that we could not rely on existing texts but would need to create our own problem-oriented material. Producing good problem-oriented text material is hard work. (Perhaps this explains why there were no good problem-oriented text books available.) It was clear from the beginning that the task was too much for one person. With the full support of the Head of Department we were able to assemble a small team that worked successfully together throughout the development and initial presentation of the subject and was one of the most pleasing, satisfying and successful aspects of the subject development. During the preparation of material, tasks were shared among us. We met regularly, formally once or twice a week and informally several times each day. All the draft material was circulated, dissected and discussed. To avoid 'development by committee' each task had a leader who assumed overall responsibility. As a result the teaching material was enriched beyond the capabilities of any one of us. The production of material started in August 1998 and proceeded continuously and intensely until May 1999. The material was initially delivered in first semester 1999 (i.e. February to June; as is often the case with new subjects, teaching began before material preparation

80

had been completed). The outcome was teaching material built around over lfi0 carefully crafted programming problems. In the light of the experience gained from the firstpresentation, in the second semester 1999 the problem-oriented text material was extensively revised. In February 2000 it was published as a text book [6]. The problems are designed not only to illustrate concepts but to suggest ideas for investigation. Concepts are deliberately introduced first in problems and only later discussed and developed. The aim is to encourage the student to question, explore and experiment, to break away from the dull and dreary approach whereby concepts are introduced and discussed and then exercises are set. W e wanted the student to discover and be excited by ideas and concepts before reaching the formal treatment in the text. The problems vary from the quite easy to the moderately dimcult. However, in all cases the problems are well within the grasp of any serious student. This is not to say a student won't have to carefully mull over ideas and think through issues. W e have assumed the student actually wants to learn Java and fully accepts that this requires dedicated effort. It is our aim to ensure that the student feels fully rewarded in terms of the knowledge acquired and the pleasure and satisfaction obtained from the creation of interesting programs. In our view, a problem is incomplete without a solution. (Again, this was a failing of virtually all existing text books.) Nothing is more unsatisfactory than to receive no feedback after the effortof attempting a problem. It is not just a matter of supplying a solution; the ideas and strategy leading to that solution are just as important. Frequently students want not the whole solution but just a pointer so they can persist in an attempt to solve the problem. With this in mind, the problems come with graded hints leading to fullsolutions. These hints are designed not only to help the student who is having di.fl]culties,but to offer alternative suggestions and discuss issues that arise. Altogether there are several hundred pages of hints in H T M L (hypertext) format. These hints are availableboth on the subject's web page and on a C D - R O M accompanying the material. 2.2

Flexible Learning

One of the advantages of taking a problem oriented approach is that wen prepared material is ideally suited for independent and stir-paced study. The students are empowered to take control of their studies, setting their own agendas and study routines. The role of the teaching staff can then become supportive rather than descriptive. This has a considerable influence on how lectures and lab sessions are conducted (see Sections 3

and 4 for a more detailed discussion of these issues).

pre-existing class Delay can be sent the message milliseconds(hUm) with the result that the running program delays for num milliseconds where num is an integer passed as argument; there is no need to know anything about the underlying code which makes use of threads. A pre-existing class T r a n s c r i p t can be sent the messages p r i n t ( . . ) and p r i n t l n ( . . ) and responds by opening a window to display as output whatever is passed as argument.

In our view it is important not to confuse flexible leaning with distance education. The material we have prepared would, we believe, be very well suited as the basis for an off-campus first programming subject. But to us that was a secondary consideration and not the main reason for preparing flexible learning materials. Our experience strongly suggests that well prepared flexible learning materials greatly enhance the traditional campusbased learning environment (see Sections 3 and 4). 2.3

3

Effective Large-Group Lecturing

Another educational goal we had was to redesign the large-group lecture so as to conform to the subject's problem-oriented aims. The subject is taught each semester and currently enrolls more than 500 students in first semester and more than 600 in second. Lectures are repeated, but typically they are given to about 300 students at a time. It has been suggested, and with some justification, that large-group lecturing is ineffectual and inappropriate. Is there a role for such a form of teaching, particularly given the subjects problem-based approach?

Inverse Curr;culum

Integral to the decision to base the subject around problem-oriented learning was our desire to take an inverse curriculum approach as originally proposed by Meyer [12]. We had successfully adopted such an approach with the previous Smalltalk subject [5]. The idea is that from the beginning students make use of existing classes to create relatively sophisticated applications. By making full use of class reuse, this can be done without the need to know the details of the classes being used. Instead, it is necessary to know only the messages that can be sent to a class or object, and the way that class or object will respond.

By supplying each student with comprehensive problem-oriented text materials, lectures are no longer required simply to define the subject content. Rather, each lecture can focus on ideas and applications. A typical lecture involves actively creating and running Java software. Using the data-projection facilities the students and lecturer participate to write and run software and solve problems live. In the process important ideas and issues are discussed as they arise. The lectures become supportive and exemplary rather than purely descriptive. Particular issues can he focused upon, perhaps because these issues are conceptually more diflL cult, or simply because they are key concepts. The lectures present an opportunity to share the enthusiasm felt for the subject. There is no need for the lectures to work through each concept one after the other, regardless of importance or difficulty, simply for completeness. The assumption behind the lectures is that the students can discover the detail for themselves using the supplied materials. To surnmarise this point: do on paper what is best done on paper, do in a lecture what is best done in a lecture.

For example, one of the very first problems involves sending the message c r e a t e ( ) to the specially created pre-existingclass CircleFiguxe. Th~ class responds by opening a window with a red circle at its centre. By then sending messages such as moveLe:ft(50) or s e t C o l o u r ( C o l o r . b l u e ) , etc. to the class C i r c l e F i g u r e , the circle moves left 50 pixels or changes colour to blue, etc. Through such problems the student be~,in~ to grasp the fundamental idea of message passing. As the subject progresses the depth of understanding of Java develops to the point where the student can begin to open up these pre-existing classes and understand and emulate their underlying code. Adopting the inverse curriculum means that impressive graphical applications can be coded from the very beginning. There is an immense satisfaction and sense of achievement in coding applications that display and animate simple graphical figures, even if the effects are achieved mostly by sending messages to pre-existing classes whose code is decently hidden.

So that students can prepare for each lecture they are advised which sections of the text material should be studied beforehand. In practice, however, because prior preparation cannot be enforced it is important that problems discussed in a lecture involve as few orthogonal background concepts as possible. Similarly, because abilities vary widely in such a large group the problems need to be balanced so that although the emphasis is on basic core concepts, advanced issues are also introduced. (It is never possible to get this balance to everyone's

The inverse curriculum also enables some of the more difficult aspects of Java to be postponed until late in the subject. For example, the specially created pre-existing class Dialog can be sent messages such as r e q u e e t I n t ( . . ), r e q u e s t D o u b l e ( . . ), etc. and responds by opening a dialog box, enabling simple information to be input without the need to know anything about exception handling. Similarly, the

81

taste: there are always a few students who complain the lectures are too hard and a few who complain they are too easy.) A side effect of our approach to lecturing is worth mentioning. It is essential to carefully rehearse in advance the problem to be solved live during the lecture. It is not easy to generate correctly working software in a lecturing environment, especially as the problem and its solution needs to be presented spontaneously and enthusiastically,as if it was being solved for the firsttime. It is also important that lectures have a direction of their own, taking diversions as suggested by the students. This can be a bit scary for the lecturer; there is always the fear that the lecture might get hopelessly lost. Experience convinces us that sound preparation can prevents this. In any case, students really appreciate seeing and helping someone work in uncharted waters. Our experience has been that freeing the lectures from the need to define the subject content is liberating both for the student and the lecturer! There is no need for the student to take copious notes during the lectures (all the code that is developed during a lecture is later that day placed on the web page). Lectures can become what they always should have been: an opportunity to explore, discuss, experiment and teach! As an aside we should also mention that lecture presentation was significantly enhanced through team interactions. The team would meet well before each lecture to discuss the issues, ideas and examples to be covered by the lecture and decide which of us would present it. W e all attended the first presentation of each lecture and joined in a postmortem afterwards, where we reevaluated the content, the teaching style, whether we had succeeded or not in conveying the main ideas, and so on. This was invaluable as each lecture was repeated in the late afternoon and we were able to suggest improvements before the repeat. But most importantly, as two of the team were new to lecturing they could feel the support of the whole team when it was their turn to lecture. In our view, this mentoring is of such enormous benefit that all new lecturers should be placed within a supportive team-teaching situation when they firstjoin the lecturing staff. (By team-teaching in this context we emphasise that we mean the involvement of the whole team in all aspects of the teaching of the subject, and not subject-sharing whereby different lectures simply take it in turns to teach different parts of the subject.) 4

Lab Sessions

computer-lab sessions. We have a dedicated computer lab containing 40 terminals open from 8am to 8pm Monday to Friday. For almost all of these hours there are two tutors in the lab ready to help any student with any problem. The emphasis, therefore, is on individual tutorial assistance with specific problems. A suggested study guide is given to the students at the beginning to help them plan their work, but as the students can work at their own pace, in any lab session there may be students working on early material while others may be far ahead. (There are assessment deadlines, however, that must be met and these restrict student flexibility; see Section 5. The study guide details these de~l;nes and also indicates the assumed background for each lecture.) In addition to the computer-lah sessions, we run weekly what are known as PASS tutorials. These are remedial tutorials intended for those students who feel they are not coping and are in serious danger of failing. About 5% of students attend these tutorials. In each semester we need at least 40 part-time tutors to staff the computer labs. About half of these tutors come from the usual pool, i.e. they are advanced undergraduates or PhD students. The other half are selected from the very beet of the students from the previous year. Although these students are only one year ahead of the students they are tutoring, employing them as tutors has several distinct advantages. First, they are very close to the experiences of the first year students; they can mentor as well as teach. Next, by rewarding our best students in this way we can cement their relationship with the Department and consequently encourage them in their computer science studies. Also, these students get to know each other well, something not otherwise all that easy given the large student numbers. These students quickly form strong bonds that greatly help them not only in their tutorial work but also in their studies. Finally, these students begin their tutorial duties in the laboratory where they teach on a one-to-one basis. This is excellent initial training for those students who in later years will conduct class tutorials. In other words, we are able to start training these gifted students in the art of teaching. This is not only a benefit to the students themselves, but creates a pool of tutors that the Department can call upon later for tutoring advanced subjects. Clearly, of course, these tutors need to be carefully trained in the important role they are to play. Before the beginnlug of semester, tutors attend a day-long workshop. Throughout the semester there are regular tutor meetings to discuss general and specific teaching strategies. 5

Because of the problem-based nature of the subject, traditional tutorials have been replaced by tutored

82

Assessment

We wanted to ensure that the assessment closely matched the main task of the subject, namely, expe-

riencing how to create software by discovery and experiment. Both the continuous assessment and final exam are designed with this in mind.

5.1 ContinuousAssessment Associated with the problem-oriented text material are i0 lab-assessment programming problems. These problems are all relativelystraightforward and are designed to test core concepts. W h e n a student has completed a problem, he/she needs to demonstrate their code (i.e. show that the code compiles and runs succe~fuUy) to a tutor during any computer-lab session. This gives the tutor an opportunity to directly interact with the student and give immediate feed-back. If the tutor is satisfied with the code, the student earns 3 % (giving a total of 30% for this aspect of the assessment). The deadlines for completing the lab assessment are bunched so as to allow students flexibilityin how they study. For example, the deadline for the firstthree lab-assessment problems is the end of week four. In addition to the weekly lal>-assessment problems, there are three programming assignments each worth 10%. These assignments are significant programming problems designed to test a range of concepts and to incorporate wider issues (see Section 6 for an example).

5.2 Final Exam On completion of the subject there is an open-book practical exam worth 40%. Students must pass this exam in order to pass the subject. Moving to a practical exam was a major innovation and the decision was taken only after a lot of discussion. In the end we felt we had no real choice as it would not be possible to test within the confines of a traditional written paper the students' skills in using the programming environment to explore and create software. A computer program is not complete until it has been succeesfully compiled and tested, and these practical tasks can only be undertaken using a computer. Furthermore, throughout the subject students mm never required to undertake written work, so it seems most inappropriate to require it in a final exam. The logistical and other problems associated with holding a practical exam for such a large class are horrendous. Because not all students can fit into the computer lab (by using other labs in parallel we can examine about 80 students at a time) we are forced to run many sessions. As well as the obvious time-tabling problems, we need to produce several exam papers and ensure they are of similar standard. We persevere because the academic considerations are so compelling. There is, however, an unexpected outcome from holding

a practical exam: we have not been able to adequately differentiatebetween the most able students. For each of the 3 times that the subject has been offered, about 20% of the class has achieved full marks for the practical exam. The result is that we have been awarding a larger percentage of top grades than is usually the case for a first-yearsubject. Even when for the firstsemester 2000 we deliberately made the exam more difficult,the percentage with fullmarks did not alter--instead those students who got less than half marks simply increased from 12% to 16%. The reality is that each semester there is a group of good students who master Java programming at this level. Given that the compiler detects syntactic programming errors and code can be tested by execution, these students will be able to solve any reasonable problem. Short of setting a difficult'race against the clock' exam (and such an exam would be unfair to the weaker students) it is unclear just what, if anything, we can do to differentiatemore adequately between the most able students.

6

Teaching 0bject-Oriented Programming

Teaching issues that arise when adopting an objectoriented language such as Java have been widely discussed [1, 3, 10, 11]. Ignoring the specific Java language debate, several general object-oriented issues were central to our approach to teaching a first object-oriented programming subject. 6.1

Objects First?

We agree with Clark et. al. [3] that it is inappropriate to take an object-oriented language and use it to teach the traditional procedural programming paradigm. However, it is understandable why the procedural approach is often adopted. Most of us have been teaching procedural programming for some years and it is surely sound teaching practice to build upon the successes of our previous subjects when constructing a new subject. (Indeed, many of the text books we reviewed were clearly created by rewriting an earlier successful text book that took a procedural approach. The authors simply adjusted the text to accommodate Java rather than Pascal, say.) The problem with the procedural approach is that it ignores the reality behind modern object-oriented programming: class reuse. The pre-existing class libraries are needed to do even simple tasks, and the object-oriented paradigm underlies class reuse.

This, however, does not mean that object construction needs to be tackled in the first week. A more fundarnental aspect of the object-oriented paradigm is message passing. By adopting the inverse curriculum, message passing is introduced painlessly at the very besdnning.

83

is the firstplayer to occupy four adjacent positions in a vertical,horizontal or diagonal row.

Consequently, specificobject construction can be postponed, even though objects are discussed and used early (see [6] for details). It is certainly true that specificobject construction together with inheritance are difficult concepts for beginners, but the inverse curriculum can prepare the students and convince them in advance of the need. 6.2

From the point of view of a student assignment, there are three distinct(but closely related) aspects to coding this application. First, the GUI components need to be constructed. Next, the architectural relationships between the underlying objects needs to be designed. In this case the students were guided to use the mediator pattern [6, 7]. Finally, the logical relationships that capture the moves and the current status of the game need to be coded.

Applications or Applets First?

Initially, Java owed its popularity to the fact that it enabled applets to be executed within web pages. But Java is now a main-stream programming language and we can see no good reason for taking an approach that starts with applets, particularly as it is not difficult to convert applications into applets. That is, our approach is to see applets as just one particular, although nevertheless important, application. The applet issue is compounded by the fact that Java is evolving ahead of the web servers, with the result that the Java Plug-in is required by most web browsers in order to run applets that make use of the latest Java features. In any case, security issues mean that applets are restricted in their I / O capabilities, and I/O is certainly something that needs to he covered in any programming subject. Furthermore, Dynamic HTML, Java Script and animated GIFs can do much of what was handled by applets a few years ago (see [9] for a detailed discussion of these

Which aspect of this ass}~Lnment, do you think, would give the students the most difficulty?

~ues). 6.3

Object Architecture and Internal Logic

The issue arises as to how much object-oriented analysis and design should he attempted in a first programruing subject. Understanding the architecture of objectoriented systems is a crucialskill,but how much should it be emphssised at the beginning? Our view, based on carefully monitoring the progress of students, is that a first subject needs to emphasise the logicalrelationships between lower-level concepts and how to capture these relationships within code. That is not to say that architectural issues should be ignored. O n the contrary, they need to be discussed at every opportunity. But basic programming skills need to be attained before the student is really free to focus on the more advanced architectural design issues.

It was not the construction of the GUI components, nor the design of the mediator pattern (although of course many students did find these things tricky). Examples of both these important design aspects could be found in the text material [6]. The major difficulty was writing code to test after each move whether or not the game was over, i.e. whether or not the player had occupied four adjacent positions in a vertical, horizontal or diagonal row. This example typifies what we see as the most significant difficulty facing beginners: using basic programruing constructs such as while-loops and boolean expressions to capture a system's internal logic. How well students learn to handle such tasks has a pronounced infiuence on how well they cope with more advanced studies in software development. We find that in later years, students who have not adequately mastered these basic programming skills may be able to create higherlevel designs but struggle to convert those designs into actual code.

To illustrate our point, the third assignment set for the students in first semester 2000 was to code the game four-in-a-row. For those not familiar with this game, it involves two players and a board 7 wide and 6 high (see the figure in the next column). Initially the 42 positions are unoccupied and the players take it in turns to claim and occupy one of the remaining unoccupied positions. However, an unoccupied position can be claimed only if it is at the bottom of the board or if every position in the same column below it is already occupied. The winner

84

7

Student Surveys

The feedback summsrised in this section comes from a survey of students. Q u e s t i o n : on a scale of 1 to 7 how would you rate this subject overall?

0% 1% 2%

6% 20% 52%

19%

This averages out at a score of 5.8 which is well above the Department average and quite exceptional for a first-year subject. (In second-semester 1992 when the Department circulated to academics anonymous scores for all undergraduate subjects, no subject rated this high and the average taken over all subjects was 4.8. Unfortunately, the Department no longer circulates these statistics). The next question relates to the self-paced problemoriented approach adopted by the subject. Question: overall,what do you think of this approach in helping you learn Java?

useless

sometime effective

1%

25%

not enjoyable 4% learnt little 2%

a little enjoyable 53% learnt a few things 24%

very effective 74% very enjoyable 43% learnt a lot 74%

The next two questions relate to the usefulness of the teaching strategy. Q u e s t i o n : overall, how useful were the lectures?

41%

56%

The final question relates to the effectiveness of the teaching of the material, as distinct from the quality of the material itself. (Clearly, however, the quality of the material effects the way it is taught.) Question: all things considered, on a scale of 1 to 5 how would you rate the stMPs overall effectiveness as university teachers?

0% 8

0%

In this paper we argue strongly that the approach should be problem based, that it should allow the students to work flexibly and independently at their own pace, and that it should enthusiasticallyembrace the object-oriented paradigm from the very beginning through the inverse curriculum. From this comes a new approach to lecturing: lectures can become supportive rather than purely descriptive. Tutorials can be labbased and become more interactive, concentrating on assistingstudents individually. However, we should be under no illusionmpreparing such a subject is a m a m m o t h task. Flexible and problem-based learning is not, as some might wish, an opportunity to do more with lees. Evidence overwhelmingly suggests that the total teaching effort is greater than for traditional teaching methodologies. Lectures, tutorials,continuous assessment and practicalexarninstious all take more effort. The benefits,however, are in the outcomes.

References [1] Allen, R., Bluff, K. and Oppeaheim, A. Jumping into Java: object-oriented software development for the masses. In Proceedings of the Third Australasian Conference on Computer Science Education (ACSE'98), ACM (1998), 165-172. [2] Boud, D. and Feletti, G. The Challenge of Problem Based Learning, Kogan Page, 1991.

Question: overall, how useful were the lab sessions?

3%

the first step. Moving to an object-oriented language such as Java gives us a great opportunity to re-evaluate the whole strategy and philosophy behind a first programming subject.

[3] Clark, D., MacNish, C. and Royle, G. Java as a teaching language opportunities, pitfMh and solutions. In Proceedings of the Third Australasian Conference on Computer Science Education (A CSE'98), ACM (1998), 173-179. [4] Duke, R. The design of an experiential component for a formal methods computer science subject. In Proceedings of the First Australasian Conference on Computer Science Education (ACSE'96), ACM

(1996), 111-118. [5] Duke, R. In seach of the inverse curriculum. In Proceedings of the Second Australasian Conference on Computer Science Education (ACSE'97), ACM

(1997), 65-70.

2% 26% 72%

[6] Duke, R. and Salzman, E. Java Genesis, Pearson

Conclusions

Education Australia, 2000.

W h e n thinking about creating a new subject to teach programming to beginners, much effortgoes into choosing the associated computer language. But this is just

85

[7] G a m m a , E., Helm, R., Johnson, R. and Vlissides, J. Design Patterns: Elements of Reusable ObjectOriented Software, Addison Wesley, 1995.

[8] Greening, T., Kay, J. and Kingston, J. Problembased learning of first year computer science. In Proceedings of the First Australasian Conference on Computer Science Education (ACSE'g6), ACM (1996), 13-18.

[9] Horstmann, C. and Cornell, G. Core Java, Sun Microsystems Press, Prentice Hall, 2000. [10] King, K. The case for Java as a first language. Presented at the 35th Annual ACM Southeast Conference, hetp : / / m ~ . gsu. edu/'ma'cWnlr/java/reg97, 1997. [11] Kolling, M. and ltosenberg, 3. Blu= s language for teaching object oriented programming. In Proceedings of the ~7th SIGCSE Technical Symposium on Computer Science Education (1996), 190-194. [12] Meyer, B. Towards an object-oriented curriculum. Journal of Object-Oriented Programming, 7681, May 1993. [13] Woods, D. Problem-Based Learning: How to Gain the Most from PBL, McMaster University Bookshop. Hamilton, Ontario, 1994.

86