Why Complicate Things?Introducing Programming in High School Using Python

Linda Grandell, Mia Peltomäki, Ralph-Johan Back and Tapio Salakoski

Turku Centre for Computer Science,Lemminkäisenkatu 14 A, FIN-20520 Turku, Finland

Email: linda.grandell@abo.fi, mia.peltomaki@utu.fi, backrj@abo.fi, tapio.salakoski@utu.fi

Abstract

Deciding what to teach novices about programmingand what programming language to use is a com-mon topic for debate. Should an industry relevantprogramming language be taught, or should a lan-guage designed for teaching novices be used? Typ-ically, these questions are raised at university level,but in this paper we address them from a high schoolperspective.

We present a case study with a twofold goal: (1)examining how programming can be introduced athigh school level, and (2) evaluating how suitable theprogramming language Python is to support bothteachers and learners in this process. During theschool year 2004/2005, an introductory programmingcourse was given to four student groups in two di�er-ent high schools. The students enjoyed programmingand learnt to think in terms of re-use and interfaces.In addition, we found that many features of Pythonfacilitated both teaching and learning (for instance, asimple and �exible syntax, immediate feedback, easy-to-use modules and strict requirements on proper in-dentation).

Our �ndings support results from previous stud-ies in that students have di�culties in dealing withabstract concepts - even though the syntax for im-plementing these is simple. In addition, compared touniversity students, high school students are youngand have necessarily not yet developed the writingskills required for producing proper documentation.The course was designed to be well suited for highschool students in general, but still all participantswere boys. Since high schools should provide all-round learning to all students, we, as do all computerscience teachers, face the challenge of making pro-gramming more appealing to girls.

1 Introduction

Computer Science in High SchoolsSubjects that have previously been considered univer-sity level topics are increasingly introduced at lowerlevels of education; computer science (CS) is an ex-ample of such a topic (Ben-Ari 2004a). The aim ofelementary and secondary education is to provide stu-dents with knowledge needed in every-day life, andconsidering the increasing role of computer technol-ogy and applications in today's society, CS can beseen as an essential part of this all-round learning.Copyright c©2006, Australian Computer Society, Inc. Thispaper appeared at Eighth Australasian Computing EducationConference (ACE2006), Hobart, Tasmania, Australia, January2006. Conferences in Research and Practice in InformationTechnology, Vol. 52. Denise Tolhurst and Samuel Mann, Ed.Reproduction for academic, not-for pro�t purposes permittedprovided this text is included.

Consequently, e�orts have been made in order to in-troduce CS at high school (HS)1 level: for instance, inthe USA (Merritt et al. 1993) and in Israel (Gal-Ezeret al. 1995), CS curricula for HSs were developed inthe 1990s, and according to the information networkon education in Europe, Eurydice,2 most Europeancountries speci�ed CS and programming as part ofHS education in 2004. As CS education has becomemore common at HS level, the interest in studyingthis topic has increased; for example in 2004, an en-tire issue of the journal Computer Science Education3

was devoted to this topic.

Di�culties in Learning ProgrammingAlthough there seems to be a general agreement thatCS should be taught at HS level, there are many dif-fering ideas about what exactly should be taught.The main point of disagreement is usually whetherprogramming should be included in CS curricula atHS level or not. Many studies have pointed outdi�culties experienced by university students whenlearning programming. Spohrer and Soloway (1986)showed that a few bug types constitute the major-ity of the mistakes made by novice programmers:construct-based problems, which make it di�cult to�learn the correct semantics of language constructs�,and plan composition problems, which make it di�-cult to �put plans together correctly�. Recent studiessupport these �ndings (for example (McCracken et al.2001, Ben-Ari 1998)). Moreover, the results from amulti-national study conducted in 2004 (Lister et al.2004) showed that students lack the skills needed totrace the execution of short pieces of code after takentheir �rst course on programming. Other reportedsources of di�culty or confusion have been related to,for instance, parameter passing (Fleury 1991), analo-gies (Halasz & Moran 1982) and mathematical nota-tion (for example (Haberman & Kolikant 2001, Bay-man & Mayer 1983)). For a further review of thistopic see, for example, Robins et al. (2003).

Programming Languages in EducationThe di�culties mentioned above seem to be relatedto the programming activity - not the programminglanguage. Nevertheless, deciding what, and how, toteach novice programmers is not the only topic for de-bate. Equally common a topic is which programminglanguage to teach. According to Palumbo (1990), thelearning results in programming classes depend on the

1In the Finnish educational system, high schools are referred toas upper secondary schools, providing education to students aged16-19. The principal objective of these schools is to o�er generaleducation preparing the students for the matriculation examina-tion, which is a pre-requisite for enrolling for university studies.http://www.edu.�/english/page.asp?path=500,4699,4840,4845

2http://www.eurydice.org/Documents/KDICT/en/FrameSet.htm3http://www.tandf.co.uk/journals/titles/08993408.asp

time devoted to actual programming and languageaccess. In order to maximize the time spent on pro-gramming, one should avoid having to �waste� timeon discussing irrelevant language constructs and syn-tax errors.

According to Milbrandt (1993), a programminglanguage to be used in education should be easy tolearn, structured in design, universal in use and pow-erful in computing capability. The language shouldalso have a simple syntax, provide easy I/O han-dling as well as output formatting, use meaningfulkeywords, give immediate feedback, etc.

Pascal and Logo were both designed with edu-cation in mind, and many studies have indicatedthe suitability of these in education (for example(Schollmeyer 1996, Sha�er 1986)). Unfortunately,both languages su�er from drawbacks that have led todecreasing signi�cance over the years. For instance,Logo is seen as a language for children, and Pascal hasnot followed the same pace of development as morerecent languages (deRaadt et al. 2002).

Today, C, Java and C++ top the list of the mostpopular languages based on the availability of engi-neers, courses and third party vendors around theworld.4 Researchers have found that Java, Visual Ba-sic, C++ and C are the languages most widely taught(or planned to be taught) at universities (deRaadt etal. 2002, Stephenson & West 1998). These results arefurther con�rmed when looking at web pages of CSdepartments at universities worldwide. Despite theirpopularity, there has been much debate about thesuitability of these languages in education, especiallywhen introducing programming to novices (for exam-ple (Mody 1991, Hadjerrouit 1998, Biddle & Tempero1998, Clark et al. 1998, Close et al. 2000)). The lan-guages are, for example, considered too verbose, en-forcing notational overhead that has little to do withlearning to think algorithmically and to write struc-tured programs. All the time spent on sorting outthese issues is time away from actual programming.

Given the di�culties related to learning program-ming at university level, the skepticism against intro-ducing the topic at HS level is understandable; afterall, if something is considered problematic by univer-sity students, it is reasonable to assume that it isequally troublesome for younger students - especiallywhen indications of the di�culties can be found alsoin studies conducted among HS students (for exam-ple (Aiken 1972, Ginat 2003, Haataja et al. 2001))).Most of the problems that have been discussed in theliterature have, however, been based on the tradi-tional instructional languages mentioned above; thosewho take a critical stand against programming beingtaught at lower levels might be doing so based ontheir experiences in teaching these languages. In thatcase, the criticism can be seen as aimed towards thelanguages and not at programming per se.

Should HS Students Learn Programming?Prior programming experience has been shown tohave a positive impact on university CS studies(Hagan & Markham 2000). However, programmingskills are not only important to students pursuing ca-reers as computer scientists. Researchers (for exam-ple (Mayer 1986, Treese 2003, Soloway 1993)) havestudied the impact of programming on the develop-ment of thinking skills, and although the results vary,indications of the connection between programmingand problem solving, algorithmic thinking and log-ical reasoning have been found. Students who willnot become programmers will still bene�t from thesemeta skills learnt in the process. Knowing how to

4http://www.tiobe.com/tpci.htm

program also implies understanding how software andcomputers work, which may reduce computer anxietyand frustration. Moreover, having some knowledgeof programming makes it easier to communicate withCS professionals. In addition, we feel that the afore-mentioned di�culties in learning programming makeit even more motivated to start teaching program-ming at HS level; doing so, we can deal with some ofthe problematic issues related to learning to programat an early stage and thus improve the prior knowl-edge and skills of future university students. In ouropinion, programming should therefore be included inCS curricula at HS level. Even though some studentswould not take the courses, they should be given thechance to do so.

In this paper, we present an approach to intro-ducing programming and algorithmic thinking in HSusing the programming language Python. Our aim istwofold: (1) examining how programming can be in-troduced at HS level, and (2) evaluating how Pythonis suited for supporting this teaching process. Webegin by motivating our research, particularly by re-viewing previous work relevant for our two goals.Thereafter we present the course, its goals, materialand syllabus. Starting in fall 2004, the course hasbeen given to four groups of HS students, and wepresent and discuss the results from these courses. Webrie�y discuss our own experiences before concludingthe paper with some �nal remarks and suggestions forfuture work.

2 Motivation and Related Literature

Although Pascal and Logo have lost much of theirsigni�cance, the same things that one earlier hoped toachieve using these are still desirable in programmingeducation. In many respects, the aims of Python canbe compared to those of Pascal and Logo, with thedi�erence of Python being a popular language.5

Python is a high-level scripting language, origi-nally designed by Guido van Rossum to facilitatelearning; van Rossum has even suggested that every-body could master programming using Python (vanRossum 1999). The language has many of the featurescharacteristic for a language suitable for teaching pro-gramming, for instance the following ones:

Small and clean syntax Compared to languagessuch as Java or C++, Python has a more in-tuitive syntax (code listing 1).

Dynamic typing Python is dynamically typed,which further reduces the notation.

Expressive semantics Python's basic types arepowerful: for example, lists can be introducedat the same time as other built-in types.

Immediate feedback The interpreter enables fastand interactive demonstration of programmingconcepts, and gives immediate and understand-able feedback on potential errors.

Enforced structural design Python enforces anindented and structured way of writing pro-grams, and the code resembles pseudo code.

Relevant open-source software Python is freeand widely used.6 It comes with a text editor(IDLE ), and a large amount of tutorials, books,course material, exercises, assignments and ex-tensive documentation is available on the web.

5http://www.tiobe.com/tpci.htm6http://www.pythonology.org/succes

Code listing 1 Comparison of a simple output programin Python and Java.Python Javaprint "Hi!" class Hi {

public static void main (String args[]) {System.out.println("Hi!");

}}

% javac Hi.java% java Hi

For a more detailed review of Python's featuressee the o�cial website7 or the articles cited below.As any language, Python naturally also has featuresthat might be drawbacks:

Performance That Python is a scripting languagemakes it time saving to write and execute shortprograms, whereas large programs might su�erfrom a loss in performance. This should not berelevant in introductory programming courses, inwhich the programs written are relatively small.

No information hiding In Python, attributes arevisible by default, thus making discussion on in-formation hiding and encapsulation more di�-cult. This is not an issue while not dealing withobject-oriented programming.

Dynamic typing Dynamic typing was mentionedas an advantage, but it might also turn out tobe a drawback. In imperative programming,the possibility of assigning di�erent types to thesame variable can be seen as a weakness thatmight make programs more prone to errors.

These potential drawbacks must naturally bepointed out to the students. Although Python mightbe a good starting language, our goal was to introduceprogramming and not Python per se; it was there-fore important to make students aware of at least thebiggest di�erences so that they would know what toexpect/not to expect from other languages they mightuse.

Many indications of Python's suitability as the�rst programming language can be found on the web.8During recent years, Python has also become increas-ingly popular in HS settings; for instance, the PythonBibliotheca,9 a site acting as both a repository forlearning materials and a virtual meeting place forteachers, includes a list of HSs in the USA that usePython.

Although seemingly on the rise in education,studies on teaching introductory programming us-ing Python are still quite few. When adding theHS perspective to this research, the number of con-ducted studies decreases further. Some research pa-pers on the use of Python in education (at bothuniversity and HS level) can be found (for example(Elkner 2001, Elkner 2002, Ceder & Yergler 2003,Oldham 2005, Stajano 2000, Agarwal & Agarwal2005, Shannon 2003)), but these have mainly dis-cussed experiences and provided suggestions, withoutpresenting any results. Guzdial (2003) has developeda new type of introductory programming course inwhich a Java related version of Python (Jython) isused. Nevertheless, although research on Python or

7http://www.python.org8http://www.cs.ubc.ca/wccce/Program03/papers/Toby.html,

http://zen.sandiego.edu:8080/luby/papers/python.pdf,http://www.python.org/sigs/edu-sig/miller-dissertation.pdf,http://mcsp.wartburg.edu/zelle/python/python-�rst.html

9http://www.ibiblio.org/obp/pyBiblio/schools.php

HS programming is by no means new, the combina-tion of these seems to be a �eld in which much stillremains to be explored. The aim of this paper is tobegin this exploration.

3 The Introductory Programming Course

Since there is no compulsory programming curricu-lum for HSs in Finland,10 we began by de�ning coursegoals according to what we feel HS students havingtaken their �rst course on programming should beable to do: (1) understand and use basic program-ming concepts and data structures, (2) develop spec-i�cations of problems to be solved, (3) write and testprograms, and (4) communicate their work to othersby thorough documentation.

SyllabusAccording to the Finnish educational system, HScourses should include at least 28 hours of instruction.The course covered the basics of imperative program-ming: variables, types, boolean logic, I/O, subrou-tines, �ow control, exception handling, modules anddocumentation. In addition, we began with a ratherextensive introduction to algorithms, �owcharts andpseudo code, before moving on to actual program-ming. This theoretical introduction was consideredessential, particularly for students who had no priorexperience in CS-related topics. Only after under-standing the concept of algorithms can one go onto translating these into programs. We also cov-ered lists and dictionaries (a collection type similar tohashmaps in Java); topics that generally, using otherlanguages, are not included in introductory program-ming courses.

Teaching ApproachActive learning11 builds on constructivist principles,according to which students become active partici-pants in their own learning process (Ben-Ari 1998).Instead of viewing learning as passive transmissionof information from the teacher to the students, con-structivists see learning as an active, re�ective processin which the students themselves construct the knowl-edge by building further upon their prior knowledge.

Moreover, both constructivism and active learningare related to the cone of experience12 developed byDale in the 1940s. This model suggests that learn-ers retain more information by what they �do� (90%) compared to what they �read� (10 %), �hear�(20 %) or �observe� (30 %). Consistently with thismodel, recent literature on active learning (for ex-ample (Ramsden 1992)) suggests that most studentscannot learn unless they are actively involved.

As a result of the issues discussed above, we tooka �learning by doing�-approach,13 and did not givetraditional lectures, but instead introduced so calledlab-lessons in which theory and practice were inter-weaved during class. The lab-lessons were interactive,hands-on sessions, which took place in a computerlab. The exercises and other activities were problem-oriented, engaging the students in both problem-solving and analysis, in addition to writing the actual

10CS is not included as an individual subject in the curriculum,but is instead integrated in other subjects. Schools also have theopportunity to arrange optional courses in CS and related topics.

11http://www.ericdigests.org/1992-4/active.htm.12http://www.mc.uky.edu/pharmacy/edinnovation/pdf/Step

Dales Cone.pdf13The concept of �learning by doing� was introduced by John

Dewey in the early 1900s (Dewey 1910).

code. Each lab-lesson started with the teacher for-mulating a problem, covering topics likely to be rele-vant and motivating to the students, including simplegames and web programming. A solution was devel-oped collaboratively by gradually re�ning the code.The classroom thus made up a community, in whichauthentic problems were solved in a �real� context.This can be seen as an implementation of situatedlearning, a theory introduced by Lave and Wegner inthe early 1990s, and discussed by Ben-Ari (2004b).

We chose the lab-lesson approach in order toaddress issues that have emerged from literature:Winslow (1996) states that �[g]ood pedagogy requiresthe instructor to keep initial facts, models and rulessimple, and only expand and re�ne them as the stu-dent gains experience�. According to Spohrer andSoloway (1986), �students are not given su�cient in-struction in how to 'put the pieces together.� ' Lahti-nen et al. (2005) have stated that �[t]he more practi-cal and concrete the learning situations and materialsare, the more learning takes place�. The lab-lessonswere designed to make it easier for the students tosee the reason for introducing new concepts: why newconstructs are needed, and when, and how, these areto be used. Programming concepts and structureswere covered in the order needed to be able to solvethe problem; not just because they �had to� be in-troduced according to the order of the chapters in abook. In this manner, new features were learnt oneat a time, at the same time as they were combinedwith previously learnt programming structures usingknown strategies. This approach of mixing theory andpractice is not unique (Haberman & Kolikant 2001),but to our knowledge not common in Finnish HSs.The more traditional way of instruction is to sepa-rate the two parts by �rst covering theory and onlythen implementing the newly learnt ideas in practiceas a separate part of tuition.

MaterialA tutorial was written for each problem containinga problem description and theory about the conceptsneeded to solve the problem, also providing a strat-egy for solving the problem at hand. Although thecourse was held in class, all material was made avail-able on a web page in the course framework Moo-dle.14 The course page acted as a repository for coursematerial, examples, assignments, announcements andlinks. The students were to document 1) what theyhad experienced as most di�cult and 2) what theyhad learnt after each lab-lesson in their private onlinelearning diary (called progress report since we wantedto use a more neutral term that would not have directassociations with �traditional� diaries). The purposewas to make it easier for us to see when students hadproblems; in our experience, HS students are seldomwilling to express their uncertainties or admit theirdi�culties in front of their classmates.

ExaminationThe �nal grade was based on the level of participationin the lab-lessons, a �nal project (including documen-tation) and a two-part exam. The �nal project was alarger assignment that the students completed at theend of the course. Since we wanted to meet the indi-vidual needs and interests of the students, they wereallowed to choose the topic for the project quite freely.The students were allowed to complete the project ei-ther individually or in pairs. In cases where the stu-dents collaborated, documentation had to be precise,clearly stating who had done what. The �nal exam

14http://www.moodle.org

consisted of one part to be completed using only penand paper and another, in which the students were towrite the solution programs on the computer.

4 Study Methodology

Action ResearchOur research is loosely built on the principles of actionresearch (Clear 2004). In action research, practition-ers in a �eld improve practice by doing or changingsomething and re�ecting on the results. The improve-ment can be in three areas: �improving a practice;improving the understanding of a practice [...] andimproving the situation in which the practice takesplace� (p. 106). The main purpose is to collect dataand experience that help in gaining a better under-standing of the practice. Our study follows a prac-tical action research model, in which �the researcherfacilitates re�ection by individual practitioners uponsome aspect of their practice� (p. 109). In our case,the researchers and the practitioners were the samepersons.

SettingsThe introductory course presented in the previoussection was given four times as an optional HS courseduring the school year 2004/2005 (four di�erent stu-dent groups in two di�erent schools). In total, 42 boysaged 16-19 have completed the course; unfortunatelythe course did not attract any female students. Thestudents in our study constituted nearly 40% of all HSstudents taking a basic programming course in Turku(the center of the third largest metropolitan area inFinland) in 2004/2005.

When teaching programming, one is bound to befaced with a situation in which the students are on dif-ferent levels; some students might have programmeda lot, whereas others might not have any program-ming background at all. There were also di�erencesbetween the groups: all students in groups A-C hadtaken at least one basic CS course, our programmingcourse was part of their curriculum, and they metregularly thrice a week during a period of 1 1

2 months.The students in group D had not had any previousCS courses, and due to school arrangements, they metonly once a week for three hours in the late afternoon,making the course span a period of three months.

Data CollectionThe learning results were mainly derived by analyz-ing the progress reports, the �nal projects and theexam. In order to gather additional information weconducted two surveys during each course. The aim ofthe pre-course survey was to collect background dataof the students, such as information about age, pro-gramming background and mathematical skills. Moregeneral questions, such as concerning the bene�ts ex-perienced from learning to program and the students'awareness of Python, were also included. The purposeof the post-course survey was to gather informationabout the students' attitudes towards the course, itsdi�culty level and Python as the language of instruc-tion. Students who had some pre-course program-ming background were also asked to compare Pythonwith the languages used earlier.

5 Results and Discussion

In this section we present and discuss the learning re-sults and the data extracted from the surveys. Wealso discuss our experiences from teaching Python

0

10

20

30

40

50

60

70

1st (9-10) 2nd (7-8) 3rd (5-6) 4th (4)

Grade division

Pro

po

rtio

n(%

)

PB NPB All

Figure 1: The distribution (in percent) of students in divi-sions based on whether they had programmed before (PB) ornot (NPB).

compared to prior experiences using other languagessuch as C, C++ and Java.

5.1 Learning ResultsCourse GradesThe course grade was given on the scale 4-10 (4 =failed), and was derived from the di�erent parts ofthe examination mentioned in section 3. When calcu-lated based on the data from all four student groups,the average course grade was 7.71. Over 85 % of thestudents passed the course. The grades were dividedinto four divisions (1st (9-10), 2nd (7-8), 3rd (5-6)and 4th (4)), which resulted in a distribution follow-ing a reversed Gaussian curve; this �nding is well inline with our experiences from university level pro-gramming courses. Our data indicate that the resultsfor the students who had some programming back-ground were good: nearly 90 % achieved the grade 8or higher. Although the diagram in �gure 1 does notprovide any comparable data, since this was the �rsttime we gave these courses, it does show that nearly80 % of students who had not programmed beforepassed the course. For students who achieved oneof the lowest grades, the course exam was the weak-est point of the examination parts. This calls for adiscussion on how to prepare students for written ex-ams: should tuition perhaps include elements of writ-ing programs using only pen and paper? This wouldenforce the students to really think their programsthrough and trace the execution, test and debug thecode - all by hand.

The number of students that failed the coursewas somewhat higher than for HS courses in general,but completely normal for programming courses, andtherefore an expected result. The number of studentsin the �rst division was, however, larger than whatcan be seen as normal for any HS course (especiallyfor programming courses): almost 45 % of all studentspassed with one of the two highest grades.

Since this was the �rst time a programming coursewas given at the school of group D, we did not haveany data to compare the results of this group with.However, programming courses have been given atthe school of the other groups (A-C), most recentlyusing Java. For these courses, all other factors butthe language have been the same as for groups A-C in our course (at least one background CS course,same teacher, same course requirements, scheduledand frequent meetings). When comparing the re-sults, the di�erences were notable. As �gure 2 shows,the proportion of students that failed decreased usingPython, whereas the number of students achievingone of the two highest grades increased: half of the

0

10

20

30

40

50

60

1st (9-10) 2nd (7-8) 3rd (5-6) 4th (4)

Grade division

Pro

po

rtio

n(%

)

Python (groups A-C) Java

Figure 2: Comparison of the grade distribution (in per-cent) from introductory programming courses using Pythonand Java.

Figure 3: The distribution (in percent) of grades achievedby students in di�erent groups with regard to whether theyhad programmed before (PB) or not (NPB).

students in groups A-C achieved a grade in the �rstdivision. The reliability of this result might naturallyalso depend on other variables, such as motivationlevel, prior programming experience and mathemat-ical skills, of the students. However, given that theprerequisites and the practical arrangements of thecourses were identical, as was the teacher, the resultsshould be comparable.

As expected, there were di�erences between thegrades achieved by students in groups A-C and thosein group D. Figure 3 shows that the overall result forthe students in groups A-C was better than for thosein group D. The biggest di�erence was among stu-dents who had not programmed prior to the course;whereas only 11 % of the novices in groups A-C failed,40 % of those in group D failed the course. On theother hand the percentage of students achieving ahigh grade is just as good for students with some pro-gramming background in both groups A-C and groupD. Our �ndings thus suggest that the di�erences inthe environment (for example meeting rarely late inthe afternoon) and the lack of previous CS-courses,complicated the learning process among true novices.Moreover, not meeting more frequently resulted in thestudents �nding it di�cult to remember the syntaxand programming in general. Considering, in addi-tion, that over 75 % of all students stated that theyprogrammed most in class, one can conclude that thestudents in group D were not exposed to program-ming as much as would have been needed. However,when starting on the �nal project, most students alsoworked at home. Since the students enjoyed workingon the project, it could be bene�cial to let the stu-dents work on smaller projects throughout the courseto ensure that they program continuously.

Progress ReportsWe were pleasantly surprised to see that most stu-dents took the progress report seriously. Naturally,there were also non-informative comments, but moststudents �lled out the report regularly, stating whatthey had learnt and what they had experienced asmost di�cult. The analysis of the reports showedthat students had in general been positive. Codingitself was frequently mentioned as the most enjoyablepart of the lab-lessons. No di�culties were mentionedat the beginning of the course, whereas some studentsstarted to report di�culties when dealing with sub-routines and exceptions.

An interesting observation was that the weakerstudents more often wrote comments such as �rathereasy�, �did not sound too di�cult�, �it will be OKwhen I practice�, whereas the more advanced studentswere able to point out the di�culties more preciselyif they had any. One explanation for this could bethat weaker students do not dare admit their di�cul-ties, but it might also be that they do not recognizewhich things are problematic. This could imply thatteachers should try more actively to make studentsaware of their di�culties, for example by arrangingmore mid term quizzes and discussing the results -perhaps even in private.

Characteristics of Student ProgramsWe are currently in the process of analyzing the stu-dents' �nal projects, and we will later report on our�ndings from this analysis elsewhere. Our prelim-inary results indicate that the programs have beenof at least the same standard as during similar HS-courses given using other languages. Most �nalprojects include di�erent control structures, self-madeand built-in subroutines, modules as well as some doc-umentation. Several projects can be ranked as partic-ularly good considering both quality and complexity:programs that consist of several modules interactingat runtime, providing user guides and thorough doc-umentation including testing and debugging reports.

Code listing 2 for-loops in PythonPython Javafor element in set: for (i = 0; i < set.length; i++) {

print element System.out.println(set[i]);}

Some interesting �ndings have been made alreadyat this point of our analysis. First, the �o�-by-onebugs� (Spohrer & Soloway 1986) seem to be less fre-quent in students' programs using Python comparedto our previous experiences in, for instance, Java.One evident explanation can be found in the di�er-ing format of the for-loop in Python. When writ-ing for-loops that are truly �Pythonish�, no indexesare needed (code listing 2). Whereas the for-loop inJava can be seen as quite cryptic, the Python for-loopmight remain unclear due to the missing indexes: thesyntax does not give an intuitive understanding forwhat the computer does and how many times it re-peats it. The avoidance of indexes naturally cleans upand simpli�es the code, but the Python version mighteven be too simpli�ed. In this sense, the for-loop ofPascal can be seen as a good compromise: simpli�ed,but still containing indexes, thus forcing the studentsto get used to �thinking� in terms of the computer andits memory. However, the lack of indexes can also beseen as an advantage: when teaching programmingas an all-round learning skill in HSs (to students, ofwhich by no means all will become programmers), the

most important thing is for students to learn how tosolve problems and translate solutions into programcode. The question is whether indexes play an im-portant role in this. If the answer is yes, the Pythonfor-loop can indeed be regarded as too simple; oth-erwise, its simplicity is an additional feature due towhich Python can be found suitable for novice pro-grammers.

Another interesting issue concerns the use of I/O.When teaching HS programming using Java andC++, our students have frequently found user in-put di�cult. Di�culties related to input statementshave also been reported on by several researchers(for example (Bayman & Mayer 1983, Haberman& Kolikant 2001, Rosenberg & Kölling 1996)). InPython, no input or output streams have to be openedor closed. Getting input from the user is accomplishedby using simple built-in functions (code listing 3),and the students learnt to use I/O e�ectively in anhour. The same comments as for the for-loop can bemade concerning I/O as well; while Python's solutionis compact and simple, it can be discussed whether ithas been made even trivial.

Code listing 3 I/O in Python# Prints out a question and reads user input as a stringname = raw_input("What is your name? ")

# Prints out a question and reads user input as a numericage = input("How old are you? ")

5.2 Survey ResultsDi�culty LevelThe data from the post-course survey showed that thecourse was not considered particularly di�cult. Thestudents graded the di�culty level of the course ona �ve-point scale (1 = very easy, 5 = very di�cult),giving a mean of 2.58 (std dev = 1.03).

Students rated the di�culty level of each coursetopic on the same scale as the course. The data (table1) showed that no topic had been regarded as partic-ularly di�cult, the averages lying between 1.33 and3.11 on the scale 1-5 (1 = very easy, 5 = very di�-cult). Subroutines, exception handling and documen-tation were considered the most di�cult topics. Openquestions established this �nding: whereas variablesand control structures were considered rather simple,abstract topics such as algorithms, exception han-dling, documentation and subroutines were regardedas more di�cult.

Topic Mean Std DevAlgorithms 2.68 0.87Variables 1.72 0.97Lists 2.51 1.21Boolean expressions 2.32 1.04For-loops 2.32 0.93While-loops 2.05 0.94If-statements 1.33 0.74Subroutines 2.76 1.08Modules 2.44 1.02Dictionaries 2.51 1.07Files 2.69 1.15Exception handling 2.89 1.09Documentation 3.11 0.85

Table 1: The perceived di�culty level of course topics (1 =very easy, 5 = very di�cult)

Di�culties in Abstract TopicsSubroutines are known to be di�cult among novices,for example due to parameter passing (Fleury 1991).Another plausible explanation is that it might be dif-�cult to understand why subroutines are needed whenwriting short programs. The same goes for exceptionhandling: students might not grasp why such a thingis needed. Finding out what might go wrong in one'sprograms, and recognizing the parts of the code inwhich errors could occur, can be di�cult. Exceptionhandling has traditionally not been seen as one of the�rst things to cover in programming courses, result-ing in it being introduced rather late in the schedule.This might make it even more di�cult for the stu-dents to understand why it is suddenly needed; afterall, their programs have �worked� before (providedthat the user has given the correct input).

As for the di�culties experienced with documen-tation, researchers have suggested di�erent reasons:students �nd writing comments and documentationuseless for small programs, and is also considered toslow down the programming process (Deveaux et al.1999). Moreover, Weinberg (1998) stated that �thegood documenter has to be a good programmer� (p.169). Clearly, not all students having taken their �rstprogramming course can be regarded as �good pro-grammers� and explaining one's programs, ideas andlogic in one's own words is completely di�erent fromwriting code. In our case, the fact that the studentswere young might be an additional reason: studentsof this age are simply not used to writing thoroughdocumentation, and have, most likely, not yet devel-oped the necessary writing skills.

Many of our �ndings are supported by previousstudies: in a study made by Haataja et al. (2001)among students in a web-based introductory pro-gramming course in Java, 60 % of the respondentsstated that methods (in other words, subroutines inJava) were one of the most di�cult topics. Accord-ing to a study conducted by Lahtinen et al. (2005),students �nd error handling (exception handling) andlibraries (modules) more di�cult than, for example,selection and looping structures when learning to pro-gram in Java or C++.

Although many of our �ndings are supported byresults from earlier studies, some di�erences can befound: compared to the results reported by Lahtinenet al. (2005), variables and selection structures wereconsidered easier by our students (average di�culty of1.72 and 1.33 vs. 2.10 and 1.98). Loop structures wereconsidered to be of similar di�culty level in both stud-ies. Moreover, our students found the if-statementeasy, whereas 48% of the respondents to the studyof Haataja et al. (2001) perceived if-statements asone of the most di�cult topics. It thus seems thatalthough some of the di�culties are the same acrossstudies, there are di�erences as well, which, in ad-dition, can be contradictory. These di�erences cannaturally be due to various factors, the di�ering pro-gramming language being only one. More researchcomparing students' attitudes towards the di�erenttopics in introductory programming courses would beneeded to make clearer the potential impact of thelanguage.

Petre et al. (2003) have found indications of top-ics being introduced early in a course to be generallyperceived as �easy� by students, whereas later top-ics are usually considered more di�cult. They foundtwo possible explanations for this: 1) students havemore time to truly learn the early topics and 2) theearly topics are emphasized more by the teacher. Inthis light, our �ndings and the results from previ-ous afore-mentioned studies suggest that the �di�-cult� topics would bene�t from being introduced ear-

lier in the syllabus. For instance, exception handlingcould be introduced when discussing user input, tolet the students get used to including it in their pro-grams from the beginning. Later on in the course, we�nd it imperative that the students are made awareof the di�erent types of exceptions that can occur andlearn how to look for parts in the code that could beprone to errors. This could potentially result in stu-dents paying more attention to debugging and try-ing to write correct programs. Documentation couldalso be emphasized more in the very beginning of thecourse, in order for the students to get used to de-scribing the goals and the process of their programs.This can be done for small programs, but takes awaysome time from actual programming. One must thenconsider the bene�ts of introducing these �di�cult�topics earlier - is it worthwhile to rethink the way inwhich we teach programming if we can give studentsbetter opportunities to learn the di�cult topics? Weare tempted to say �yes�, or as one student statedin the post-course survey: �Is it truly necessary tospend so much time on printing in the beginning ofthe course? The simple issues will still be practicedthroughout the rest of the course[...]�. It would beinteresting to see if the results were to be di�erent ifthe �simple� topics were covered quickly, and the onesthat have commonly been viewed as �di�cult� weregiven more time.

Attitudes towards PythonAccording to the pre-course survey data, almost halfof the students had never heard of Python before.About 65 % of the students mentioned a languagethey would prefer to use, the majority mentioningC++, C or Java.

The students who had prior experience in pro-gramming (60 %) were asked to compare the lan-guages used previously to Python. We used a �ve-point scale (1 = totally disagree, 5 = totally agree)and the results were in Python's favor: compared toother languages, Python was perceived as easier tolearn and also as somewhat more pleasant to use. Thestudents strongly agreed with the statement �Pythonwas easier to learn [than languages previously used]�(mean of 4.1) and they also agreed with the state-ment �Python was more fun to use� (mean of 3.7).Naturally, new languages might be considered �easier�when one has already learnt to program in anotherone. However, the fact that Python was regarded asat least somewhat more fun to use is a positive �nd-ing. According to the students, aspects such as sim-plicity, compactness (resulting in shorter code), clar-ity and a rich range of modules made Python betterthan other languages; that is, the kind of features thatinitially suggested that Python would be suited as a�rst language. The other languages were, on the otherhand, perceived as more �exible and �hard-core�, en-abling programming on a lower level. However, thecourse being an introductory one, no �hard-core� de-tails could (or even should) be covered.

Nearly 80 % of the students that �lled out thepost-course questionnaire planned to continue pro-gramming, and over 65 % of these stated that theywould do so using Python. Other languages men-tioned were C++, C, Java and PHP. Half of the stu-dents who had programmed prior to the course (insome other language than Python) reported that theywould continue programming using Python after tak-ing this course. This can be seen as an interestingresult, which could imply that Python was consid-ered better than the languages used previously; onecould expect that one does not lightly change one'spreferences concerning what language to use.

Student SatisfactionThe post-course survey showed that the course hadful�lled the expectations of most students (90 %).Over half of the students had learnt exactly as muchas they had expected in the course, whereas 23 % feltthey had learnt more and 20 % felt they had learntless than expected. The students found writing code,working on the �nal project and �getting a programto work� most satisfying. The lack of graphical pro-gramming was the main reason why the expectationshad not been ful�lled. Considering again the fact thatthe students were young, one can assume that somedid not have any expectations at all, and some hadexpectations focusing on technical and �cool� details.

Collaborative or Single ProgrammingThe results from the post-course survey did not indi-cate any preference to work alone or with a friend. Ingroups A-C, all students worked individually on theproject, whereas most students in group D workedin pairs. One explanation for most students workingalone could be the additional requirements on docu-mentation, since, as stated earlier, the students founddocumentation di�cult. We believe that collabora-tive programming could facilitate producing docu-mentation: when working together with someone else,one is bound to express thoughts and ideas to theother(s), that is, exactly the same things that onedoes when documenting programs. In the future, wewill therefore consider guiding the students into work-ing in pairs or groups.

5.3 Our ExperiencesPowerful Built-in ConstructsCompared to for instance teaching Java, it was possi-ble to introduce the powerful list data type at an earlystage, thus enabling writing more advanced programs.The students did not use the same variables for di�er-ent data types, although this is allowed, and dynamictyping did, thus, not turn out to be a drawback aswas presumed in section 3.

Ease of Debugging and Error DetectionWe had expected that Python's easy and clear syn-tax would facilitate students' learning, but we hadnot considered the consequences for us as instructors.The indented structure of Python programs forcedthe students to write structured programs, since in-correct indentation results in syntax errors. Theclear indentation facilitated debugging, error detec-tion and made correcting students' programs easierthan, for instance, in Java or other languages whereprogram blocks are denoted by curly brackets. Insuch languages, the compiler does not put any re-quirements on the structure of the program; one caneven write an entire program on one single line, pro-vided that all semicolons and brackets are in the rightplaces. Programs of this kind are nearly impossible tocheck. However, such horror code cannot be writtenin Python. We feel that writing structured programs,which are easy to check, follow and maintain is one ofthe main lessons in any programming course. UsingPython, this lesson is taught automatically.

Interactive ModeThe interactive mode was useful when introducingnew constructs and showing examples. Since eachconcept could be demonstrated in isolation, no other

syntax �got in the way�. In addition, the students fre-quently used the interactive mode for checking namespaces and reading documentation.

Ease of Re-UseThe core of a programming language should not beoverly extensive (Weinberg 1998): all necessary con-structs and concepts should be compact. To be trulyuseful, the language should, however, be extendable.Most of the languages today can be extended by in-dividual programmers, who are also given the possi-bility to re-use code written by others or themselves.However, in Python the advantages of re-use are evenmore evident, since all programs automatically be-come modules that can be used in other programs.Our students were able to share their programs withothers and re-use programs written earlier alreadyduring the �rst parts of the course. The studentsrecognized the importance of also writing small andseemingly unusable programs, by seeing how these areused when building more complex software.

Our suspicions of the negative impact of the lackof information hiding proved to be without grounds.Even though the students found writing documenta-tion di�cult, they learnt to e�ciently read and makeuse of formal documentation, and were able to useready-made subroutines correctly without knowingwhat was going on �behind the scenes�. This made itpossible for us to discuss abstraction and informationhiding, which suggests that the students managed todevelop some level of abstract thinking skills in thisshort time - even though object orientation was notincluded in the syllabus.

Code listing 4 Use of the webbrowser module

import webbrowser

options = {"A" : "http://www.google.com","B" : "http://www.yahoo.com","C" : "http://www.altavista.com"}

for site in options:print site + " : " + options[site]

try:choice = raw_input("\nChoose a site: ")webbrowser.open(options[choice])

except:print "You did not pick a valid alternative."

In addition, using modules that appealed to thestudents made it possible to teach the basics of pro-gramming in a motivating way. Since the modulesare easy to use, and do not enforce notational over-head, these did not take the students' attention awayfrom the programming itself. In our experience, whentrying to incorporate external packages or modules inother languages, the extra notation usually turns thestudents' focus to learning the speci�c package in-stead. In Python, the modules and the functionalitythey provide can really be used as what they shouldbe, in other words, as tools, without becoming the fo-cus of attention. One example is the open-function ofthe webbrowser-module, which can be used to openweb pages using a browser. The sample programin code listing 4 illustrates a program that displaysa menu of search engines of which the user choosesone by simply entering the corresponding menu let-ter, whereas the web page is opened using the defaultbrowser. As the code illustrates, this lets the stu-dents practice important concepts such as user input,

iteration, dictionaries and exception handling in aninteresting way, without extra notation. In our opin-ion, modules truly supported teaching and we feelthat this ease of making tuition interesting is a greatadvantage for a language used by novices.

6 Summary

When choosing a programming language for educa-tional settings, one has to consider many di�erentfactors: although learning aspects should be most im-portant, institutions, pressured by for instance indus-try, usually feel a responsibility to select a languagewith market appeal. The competition is heavy, andindividual institutions do not dare to make radicalchanges or try something new - even if they wantedto; the risk of losing students to a competitor is toobig. Python is not one of the most widely used lan-guages today, but statistics indicate that it is amongthe top ten languages.15 But should this even be anissue at HS level? This is again a question of whatwe want our students to learn. If we focus on a cer-tain language, we are most likely primarily teachingthe language and its syntax, the core concepts of pro-gramming becoming a secondary objective. Should itnot be the other way around? Should we not focus onteaching programming skills and leaving the languageto be something of subordinate importance? The factstill remains - we need a language when teaching pro-gramming, and the challenge is to �nd the most suit-able one. In this paper we have presented a case studyof using Python to introduce programming in HSs,with emphasis on programming, not Python, and wewill now summarize our main �ndings.

Introducing Programming in High School...Our intention was to introduce programming as anall-round learning skill at HS level, and to some extentwe succeeded. The students experienced feelings ofsuccess, learnt to write structured programs and thinkin terms of re-use and interfaces; a highly needed andappreciated skill in today's society.

Our �ndings indicate that students �nd it di�cultto deal with abstract concepts, regardless of language.Naturally, the easier the syntax, the better, but inorder to truly understand, one cannot focus on puresyntax or technical details; these can be looked up in abook and copied into one's programs. However, usingabstract concepts properly and in the correct placeof the code is nearly impossible without understand-ing the underlying principles of why these conceptsare needed and in which situations. Abstract topicsshould thus be given more time in the syllabus, evenearly on in the course.

Another source of di�culty was related to theyoung age of the students: HS students have not nec-essarily yet developed good writing skills required, forexample, for producing proper documentation. A �-nal issue is that of attracting girls into CS: so far, allstudents have been boys, and considering the role ofHSs as all-round learning institutions, this is alarm-ing. We tried to build a programming course thatwould be suited for everybody, but were not able toattract any female student - even though both teach-ers were women. A future challenge is therefore, asis probably the case for all CS faculty, trying to �ndways to make programming more appealing to girls.

...Using PythonPython's simple and �exible syntax signi�cantly re-duced notational overhead compared to other lan-

15http://www.tiobe.com/tpci.htm

guages we have used in instruction, and thus left moretime for actual coding. In addition, the interactive en-vironment o�ers immediate feedback even with lim-ited language experience, and lends itself to in-classcoding, testing and demonstration. This interactionalso supports active, hands-on learning, since the stu-dents can easily try out and analyze di�erent solu-tions. We identify the advantages of using compiledsystem languages such as Java and C++ at higherlevels of education and in industry, but we do be-lieve that one should remember that there is quitea di�erence between teaching professionals or expe-rienced programmers, and high school students, whoare about to take on programming for the �rst time.The main goals of programming education at HS levelare (1) to teach the basics of programming and algo-rithmic thinking as general all-round skills, and (2)to prepare the students for future studies.

Moreover, the ease of re-use has many bene�ts:the easy-to-use modules makes it possible for the stu-dents to practice basic concepts in a motivating man-ner, and the students learn how smaller programsare crucial when building larger systems. Althoughthe �nal product might be very complex, the build-ing process must be easy; using Python this is some-thing that seems possible to achieve. Python is anopen-source language, and this openness further in-creases its suitability for teaching purposes. Books,course readings, syllabi, exercises and other materialcan be downloaded from the Internet free of charge,and news groups and mailing lists provide forums fordiscussions and questions. The international commu-nity may also have welcome side e�ects: reading ma-terial in foreign languages and exchanging ideas withpersons with the same interests in other countries de-velop language skills and promote understanding forother cultures. In some cases, Python's syntax can beseen as perhaps even too simpli�ed, but as a whole,our initial experiences indicate that Python could besuitable as a language for novices.

7 Future Work

It is always di�cult to judge the e�ects of curricu-lar changes objectively, and the case study presentedin this paper is too small for giving any signi�cantstatistical results; that was, however, not our originalgoal either. We set out to investigate programmingat HS level and the suitability of Python in this pro-cess. Our experience has been positive, but to be ableto make more conclusive statements, we are activelycontinuing our work in the �eld of using Python inHS programming courses.

Since the four courses presented in this paper,we have given a HS continuation course in program-ming covering object-oriented topics and graphics us-ing Python. As we speak, we are also conducting anew study, similar to the one presented here. Somechanges have been made, based on the results fromthis �rst study, for example by rethinking the syllabusin order to introduce abstract topics earlier. We willalso continue the analysis of the student projects fromthe courses given so far. Finally, some of the stu-dents that have participated in our Python coursesare now studying Java, and we are following up ontheir progress.

ReferencesAgarwal, K. K. & Agarwal, A. (2005), `Python for CS1 CS2

and Beyond', J. Comput. Small Coll. 20(4), 262�270.Aiken, R. M. (1972), Experiences and observations on teaching

computer programming and simulation concepts to highschool students, in `SIGCSE '72: Proceedings of the 2ndSIGCSE technical symposium on CS Education', ACMPress, pp. 67�71.

Anthony Robins, Janet Rountree, N. R. (2003), `Learning andteaching programming: A review and discussion', Com-puter Science Education 13(2), 137�172.

Bayman, P. & Mayer, R. E. (1983), `A diagnosis of beginningprogrammers' misconceptions of basic programming state-ments', Commun. ACM 26(9), 677�679.

Ben-Ari, M. (1998), Constructivism in Computer Science Ed-ucation, in `Proceedings of the 29th SIGCSE technicalsymposium on CS education', Atlanta, Georgia, UnitedStates, ACM Press, pp. 257�261.

Ben-Ari, M. (2004a), `Computer Science Education in HighSchool', Computer Science Education 14(1), 1�2.

Ben-Ari, M. (2004b), `Situated Learning in Computer ScienceEducation', Computer Science Education 14(2), 85�100.

Biddle, R. & Tempero, E. (1998), `Java pitfalls for beginners',SIGCSE Bull. 30(2), 48�52.

Ceder, V. & Yergler, N. (2003), Teaching Programming withPython and Pygame, in `PyCon 2003'.

Clark, D., MacNish, C. & Royle, G. F. (1998), Java as ateaching language - opportunities, pitfalls and solutions,in `ACSE '98: Proceedings of the 3rd Australasian con-ference on CS education', The University of Queensland,Australia, ACM Press, pp. 173�179.

Clear, T. (2004), Computer Science Education Research, Tay-lor and Francis Group, chapter 2, Critical Enquiry inComputer Science Education, pp. 101�125.

Close, R., Kopec, D. & Aman, J. (2000), Cs1: perspectives onprogramming languages and the breadth-�rst approach,in `CCSC '00: Proceedings of the 5th annual CCSC north-eastern conference on The journal of computing in smallcolleges', New Jersey, United States. Consortium for Com-puting Sciences in Colleges, pp. 228�234.

de Raadt, M., Watson, R. & Toleman, M. (2002), LanguageTrends in Introductory Programming Courses, in `Inform-ing Science and IT Education Conference', pp. 329�337.

Deveaux, D., Fleurquin, R. & Frison, P. (1999), Software engi-neering teaching: a "docware" approach, in `ITiCSE '99:Proceedings of the 4th annual ITiCSE conference', Cra-cow, Poland, ACM Press, pp. 163�166.

Dewey, J. (1910), `How We Think'.Retrieved June 21, 2005 fromhttp://spartan.ac.brocku.ca/�lward/Dewey/Documents.html.

Elkner, J. (2001), Using Python in a High School ComputerScience Program, in `9th International Python Confer-ence'.

Elkner, J. (2002), Using Python in a High School ComputerScience Program - Year 2, in `10th International PythonConference'.

Fleury, A. E. (1991), Parameter passing: the rules the stu-dents construct, in `SIGCSE '91: Proceedings of the 22ndSIGCSE technical symposium on CS education', San An-tonio, Texas, United States, ACM Press, pp. 283�286.

Gal-Ezer, J., Beeri, C., Harel, D. & Yeduhai, A. (1995),`A high-school program in computer science.', Computer28(10), 73�80.

Ginat, D. (2003), The novice programmers' syndrome ofdesign-by-keyword, in `ITiCSE '03: Proceedings of the 8thannual ITiCSE conference', Thessaloniki, Greece, ACMPress, pp. 154�157.

Guzdial, M. (2003), A media computation course for non-majors, in `ITiCSE '03: Proceedings of the 8th annualITiCSE conference', Thessaloniki, Greece, ACM Press,pp. 104�108.

Haataja, A., Suhonen, J., Sutinen, E. & Torvinen, S. (2001),`High School Students Learning Computer Science overthe Web', Interactive Multimedia Electronic Journal ofComputer-Enhanced Learning 3(2).

Haberman, B. & Kolikant, Y. B.-D. (2001), Activating "blackboxes" instead of opening "zipper" - a method of teachingnovices basic cs concepts, in `ITiCSE '01: Proceedings ofthe 6th annual ITiCSE conference', Canterbury, UnitedKingdom, ACM Press, pp. 41�44.

Hadjerrouit, S. (1998), `Java as �rst programming language: acritical evaluation', SIGCSE Bull. 30(2), 43�47.

Hagan, D. & Markham, S. (2000), Does it help to have someprogramming experience before beginning a computingdegree program?, in `ITiCSE '00: Proceedings of the5th annual ITiCSE conference', Helsinki, Finland, ACMPress, pp. 25�28.

Halasz, F. & Moran, T. P. (1982), Analogy considered harmful,in `Proceedings of the 1982 conference on Human factorsin computing systems', Gaithersburg, Maryland, UnitedStates, ACM Press, pp. 383�386.

Lahtinen, E., Ala-Mutka, K. & Järvinen, H.-M. (2005), A studyof the di�culties of novice programmers, in `ITiCSE '05:Proceedings of the 10th annual ITiCSE conference', Ca-pacrica, Portugal, ACM Press, pp. 14�18.

Lister, R., Adams, E. S., Fitzgerald, S., Fone, W., Hamer, J.,Lindholm, M., McCartney, R., Moström, J. E., Sanders,K., Seppälä, O., Simon, B. & Thomas, L. (2004), A Multi-National Study of Reading and Tracing Skills in NoviceProgrammers, in `ITiCSE-WGR '04: Working group re-ports from the ITiCSE conference', Leeds, United King-dom, ACM Press, pp. 119�150.

Mayer, R. E., Dyck, J. L. & Vilberg, W. (1986), `Learning toprogram and learning to think: what's the connection?',Commun. ACM 29(7), 605�610.

McCracken, M., Almstrum, V., Diaz, D., Guzdial, M., Hagan,D., Kolikant, Y. B.-D., Laxer, C., Thomas, L., Utting, I. &Wilusz, T. (2001), `A Multi-National, Multi-InstitutionalStudy of Assessment of Programming Skills of First-YearCS Students', SIGCSE Bull. 33(4), 125�180.

Merritt, S. M., Bruen, C. J., East, J. P., Grantham, D., Rice,C., Proulx, V. K., Segal, G. & Wolf, C. E. (1993), `Acmmodel high school computer science curriculum', Com-mun. ACM 36(5), 87�90.

Milbrandt, G. (1993), `Using problem solving to teach aprogramming language in computer studies', Journal ofComputer Science Education 8(2), 14�19.

Mody, R. P. (1991), `C in education and software engineering',SIGCSE Bull. 23(3), 45�56.

Oldham, J. D. (2005), `What Happens after Python in CS1?',J. Comput. Small Coll. 20(6), 7�13.

Palumbo, D. B. (1990), `Programming Language/Problem-Solving Research: a Review of Relevant Issues', Reviewof Educational Research 60(1), 65�89.

Petre, M., Fincher, S. & et al., J. T. (2003), My criterion is: Isit a boolean?: A card-sort elicitation of students' knowl-edge of programming constructs., Technical Report 6-03,Computing Laboratory, University of Kent, Canterbury,Kent, UK.

Ramsden, P. (1992), Learning to Teach in Higher Education,London: Routledge.

Rosenberg, J. & Kölling, M. (1996), I/o considered harmful (atleast for the �rst few weeks), in `ACSE '97: Proceedingsof the 2nd Australasian conference on CS education', TheUniv. of Melbourne, Australia, ACM Press, pp. 216�223.

Schollmeyer, M. (1996), Computer programming in high schoolvs. college, in `SIGCSE '96: Proceedings of the 27thSIGCSE technical symposium on CS education', Philadel-phia, Pennsylvania, United States, ACM Press, pp. 378�382.

Sha�er, D. (1986), `The use of logo in an introductory computerscience course', SIGCSE Bull. 18(4), 28�31.

Shannon, C. (2003), Another breadth-�rst approach to cs iusing python, in `SIGCSE '03: Proceedings of the 34thSIGCSE technical symposium on CS education', Reno,Navada, USA, ACM Press, pp. 248�251.

Soloway, E. (1993), `Should we teach students to program?',Commun. ACM 36(10), 21�24.

Spohrer, J. C. & Soloway, E. (1986), `Novice mistakes: are thefolk wisdoms correct?', Commun. ACM 29(7), 624�632.

Stajano, F. (2000), Python in Education: Raising a Genera-tion of Native Speakers, in `Proceedings of the 8th Inter-national Python Conference'.

Stephenson, C. & West, T. (1998), `Language choice and keyconcepts in cs 1', Journal of Research on Computing Ed-ucation 31(1), 89�95.

Treese, W. (2003), `Programming literacy: is it for everyone?',netWorker 7(2), 15�17.

van Rossum, G. (1999), Computer Programming for Every-body. CNRI: Corporation for National Research Initia-tives, 1999.

Weinberg, G. M. (1998), The Psychology of Computer Pro-gramming, Dorset House Publishing.

Winslow, L. E. (1996), `Programming Pedagogy - a Psycholog-ical Overview', SIGCSE Bull. 28(3), 17�22.