(Presented at the Tenth Internationl Python Conference, February, 2002)
In our paper to the Eighth International Python Conference [Elkner], we wrote about the early stages in Yorktown High School's experiment using the Python programming language in a high school computer science environment. A year later, we are in a much better position to evaluate Python's effectiveness in this context, particularly as it relates to the Computer Programming for Everybody (CP4E) [van Rossum] initiative that inspired our efforts.
The number of students taking our course has increased since last year, and increased enrollment is an important component of CP4E. Increased enrollment naturally follows increased student interest, which in turn results at least in part from greater student success as made possible by the use of Python.
Our greatest technical challenge this past year has been the development of an effective working environment for learning. Confusion between running programs in the shell vs. using the Integrated DeveLopment Environment for Python (IDLE), as well as in using Windows at home vs. Linux at school delayed progress for several weeks. We are still addressing this problem.
Python's greatest strength as a language for teaching comes from its ability to put power in the hands of its users. By making it possible for students to do as they want with the language, the relevance of learning to program becomes clear to them. To fully take advantage of this power on a broader scale, however, strong collateral teaching materials still have to be developed (current plans for the completion of the text How to think like a computer scientist - Python Version [Downey] are centered on programming power and relevance).
We are still far from our goal of greater student diversity in the classroom. Of key importance in reaching that goal is development of new curricular approaches together with the strong teaching materials needed to support these approaches. The recent open source release of the Livewires course materials [Wright] helps fill this void. In addition, our new eGovernment course may offer an opportunity to try out new curricula.
Using Python with advanced programmers has proven to be the most exciting and indisputably successful part of our Python project. We are in the early stages of an open source development effort, a suite of software tools for the classroom called the OpenClassroom Zuite [Berezhny]. This project involves extensive planning including the creation of effective web hosting, and coordination and promotion of the project to foster the collaborative development that will be necessary to take it from a dream into a reality.
Upon entering Yorktown High School's room 217, the growing interest in Computer Science is immediately apparent. The small, somewhat crowded (let's say cozy) classroom is now cozier than ever. So many students have signed up for the Computer Science I and II classes using Python that many had to be turned away even after the number of available seats had been increased from 24 to 27.
Much of the reason for this increased interest is due to the language of instruction. The "word on the street" is that Computer Science is a challenging but fun course in which it is not too difficult to be successful. Our belief as a program has been affirmed: Python greatly simplifies programming examples and makes important programming ideas easier to teach [Elkner]. This, in turn, helps students succeed in learning. Student success promotes student interest. Learning clearly works best when our kids are educationally challenged yet not overwhelmed and frustrated by the content. Python has proven to be a good tool for achieving this balance with increasing numbers of students.
In addition to mastering the content, learning to program involves overcoming another challenge, effectively learning to navigate the development environment. Figuring out how to accomplish this is a major problem, particularly for those less familiar with computers.
An effective Computer Science program needs to bring all students to a level of mastery of the development environment as quickly as possible. This is an important task that is made more difficult in the face of unexpected network access problems.
Python provides a wonderful development environment for beginning programmers once they come to understand when it makes sense to type code directly into the interpreter, to import code into the running interpreter for interactive testing, or to run a program from the command line. They then find themselves with fluency in using a powerful environment for program development.
It is a significant challenge for many students to reach the point of comfort with the development environment, and the difficulty increases exponentially with too early an addition of variables such as multiple operating systems, editors, and integrated development environments (IDEs). If installation and configuration issues are front ended as well, then getting started with Python can become a daunting experience. Newcomers to computing are at a greater disadvantage in learning to use the development environment than they are in learning programming logic. Since this challenge is among the first things they encounter in the beginning of the course, it is very important to find a way to assure students who have not yet had the opportunity to experience success and build confidence in their ability to learn computer science.
My approach to this problem has been to keep variables to a minimum, especially early on. The greatest potential cause of confusion is the differences students find between using their systems at home, where they are usually running some incarnation of Windows or MacOS, and school, where we run Linux. To avoid this problem I teach students to run Python from within a Unix command shell. I then give students remote shell access from home and teach them to use one of the free secure shell clients available for either MacOS or Windows. In this way they work from home exactly as they do in school. Since we have enough donated computer hardware to provide any student who does not have a computer at home with a loaner machine, all students have equitable access to the resources needed for class.
This year began with remote access being blocked by the school system's IT department (for those unfamiliar with school system operations, the school system IT department's main function is to be the bane of the computer science teacher's existence ;-). This unexpected crisis meant we had to rethink how we would operate. To work at home, students would have to run Python on their Windows machines. The easiest way to do this was to use IDLE. We quickly installed IDLE on the Linux workstations in the lab, but soon found that switching back and forth between IDLE and the Python interpreter in the shell caused a great deal of confusion. Students who had been taught that simply pressing the up arrow key will bring back previously entered commands suddenly found out that in IDLE that does not work. Invariably they found this out while they were struggling to keep up with some quick moving example being presented in the front of the room. In frustration they would call out for help, and I would need to halt instruction until they could catch up. Worse yet, there were the more timid students who would sit quietly and become lost, suffering in silent frustration.
It became clear that I had to settle on one way of doing things. I called Guido at this point to ask him about the future development of IDLE, and he informed me that active development of IDLE had been discontinued. Thankfully, a short while later our network access was restored, and I returned to doing things in the Unix shell as I had before, but as a result of these difficulties, valuable learning time was lost. It was mid October before most students achieved comfort using the development environment. It was several weeks more until all students were at home with the process of writing programs. The principle lesson here is just how important an issue the development environment is for beginning programmers. This is an issue that the Python community will need to address if Python is to achieve its full potential as a language for teaching programming.
It is my sincere hope that a standard, easy to use open source integrated development environment for Python will become available within the next few years. In the mean time, I will continue to operate as I have been, but with new appreciation for and added attention to the difficulties beginning programmers experience learning to first use the development environment.
Possibly the greatest strength of Python as a language for learning to
program is its ability to put power in the hands of its users. While elements
such as file I/O and data persistence are a nightmare in C++, they are trivial
in Python. This is significant because being able to do these things is not
just an academic exercise. It is essential to making the need to program real
to students. As soon as I teach lists I give students a project called
blackbook.py in which they write a program to store important
information about their friends and loved ones. Without any prompting from me,
the question "Is there any way we could save this information between program
runs?" rises from the class. Because I am using Python, I can answer "Sure!
Let me show you how..." Even this early in the year, I can show them how
to use open and pickle. The whole process takes only
about half a class period, and my ability to meet their programming needs
as they arise empowers them and greatly enhances their perception of
programming's relevance.
To bring Python's programming power into classrooms on a wider scale, however, we still need to develop the required educational support materials. Principal among these needed support materials is a textbook. Thus the completion of How to think like a computer scientist - Python Version (HTTLCS) has been my central focus for the past year. Much progress has been made, thanks largely to Allen Downey's active involvement in its development, but it is still several chapters short of completion. My plans for the remaining chapters will reflect my experience using Python in the classroom at Yorktown High School.
It is the goal of making programming relevant to as many students as possible that is driving plans for the completion of the book. HTTLCS now has thirteen chapters. At the time of this writing, both of my classes have finished reading through chapter 10: Dictionaries. We have thus completed procedural programming in the first semester. We can now move on to object oriented programming, which is introduced in the three remaining chapters. I have yet to use these last three chapters with the students, and they are likely to undergo extensive revision once I have. It is clear even before any revisions, however, that the text is several chapters short. My goal for these chapters is to include a case study that will captivate student interest and address the relevance issue in an effective way.
My plan is to use a large program as a case study for a discussion of object oriented design. To be fully effective, this case study should be a program that students will really want to use (and even show their friends). So choosing the program is not something I can take lightly. In addition to this effective requirement, there are still several Python topics that have yet to be discussed in the text.
Heading up the list of missing topics are file I/O and data persistence using pickle and shelve. I have actually introduced these to my classes already, but they are not yet discussed in the text. I also think that exceptions under Python should be discussed. Python's exception handling mechanism is beautiful in its simplicity, and this is yet another advanced topic made teachable to beginning programming students by using Python. Three other topics complete the list: a discussion of the effective use of modules, a brief discussion of using Python as a glue language, and a short introduction to graphics programming. With the inclusion of these topics students will not only recieve a strong introduction to "thinking like a computer scientist", they will also have all the tools they need to use Python to write real programs.
I hope that this article will help generate discussion beneficial to the further development of the textbook. I would also greatly appreciate feedback on what topics should be included in an introductory textbook and how best to order these topics. I have been pleased and encouraged by the emerging user community for the book, which is reflected in the rapidly growing contributor list that is now included in the front [Downey]. Perhaps some of you will be inspired to help out with the development of the case study program. Lex Berezhny, Yorktown's Python wizard, is looking at an MP3 player as a possible candidate. We need a program of no more than a few hundred lines that makes use of all the missing topics mentioned above. It is an exciting challenge, and I look forward to bringing you a report on our progress soon.
Reaching more students by increasing success potential and broadening the level of interest in the course was one of my chief goals in looking for a replacement for C++ in the first place [Elkner], and it is clearly an essential part of CP4E's goal of "empowering all users to be computer programmers" [van Rossum]. I have already discussed the increased interest in computer science at Yorktown, but there are two other aspects to this issue that remain: retention and diversity.
It is one thing to get students into my programming class. It is another thing to keep them there. Learning to think like a computer scientist involves a great deal of abstract reasoning and applied logic that is extremely difficult for many students. Students new to computing fall behind because they experience difficulty in the beginning mastering the developing environment. Over the past several years, about twenty percent of those enrolled in Computer Science I have chosen not to continue on to Computer Science II. The fact that in Arlington County the first year course is split into two half year courses exacerbates this phenomenon.
When I first started teaching Computer Science in Arlington County I looked on the end of semester one as an opportunity for those who found that they did not like computer programming to choose some other half credit course for the second half of the year. As I began to think more in terms of a framework of Computer Programming for Everybody, I realized that my view of the semester dropout situation would have to change. If computer programming was an important skill for everybody, then it was my job to find ways to make it doable to greater numbers of students.
In reality, many of the students who were dropping the course were not doing so because they found computer programming to be in some way boring or distasteful. I confirmed in one-on-one discussions with students who were considering leaving the course this year that many of them still wanted to learn to program. Instead, they were leaving because they were experiencing frustration understanding the course material and completing their assignments. Many of them were in danger of failing the course, and they wished to leave before a bad situation became worse.
An exciting opportunity to do something about this situation became available just a few short weeks ago when the LiveWires team released their wonderful "LiveWires Python Course" [Wright] under an open source license. I learned about the LiveWires Python Course last year at the Eighth International Python conference when I met Richard Crook, one of the developers of the the LiveWires graphics application programming interface which is used with the course. The LiveWires Python Course is a complete introductory programming course used with middle school students in a summer camp ("holiday" on that side of the pond) in England. Richard sent me the course materials soon after the conference. I tested them on several student volunteers last spring.
The materials are enjoyable to use and they take a much more concrete, learn by doing approach to the subject than How to think like a computer scientist does or was intended to do. This different approach gave me yet another strategy to use with those students who were not benefitting from what I had done with the class in general. Offering students at risk in the class a chance for a new start with an alternate set of learning materials will inspire them to stay and successfully continue learning to program.
The timing of the open source release could not have been better, as I was reluctant to use any materials that might have licensing issues. Now that these issues are resolved I can feel free to use the LiveWires materials. At the time of this writing I have six of the twenty-six students from each class trying out the LiveWires course. Early indications are that they are finding it as exciting a learning experience as it is fun. So it appears that I have found a way to significantly reduce the drop-out rate for Computer Science II.
One of the key goals of our program is finding creative ways to expand the diversity of those students taking the course. While our school wide increased interest in the course is definitely encouraging, we still have a long way to go before reaching everybody. My classes this year are little more diverse than they were in years past, and in each of the two sections of Computer Science, only three of the twenty-seven students are women.
A report published by the American Association of University Women (AAUW) entitled, "Tech-Savvy: Educating Girls in the New Computer Age" [AAUW] provides some important suggestions for what needs to be done to open the doors of computer science to women. The AAUW commission concluded that girls hold well founded reservations about the current computer culture. They express concern about the passivity of their interactions with the computer as a "tool" and reject the violence, redundancy, and tedium of computer games. They dislike narrowly and technically focused programming classes [AAUW]. Among the important suggestions of the commission are to apply what we learn from girl's concerns to change both the software we use and the way we teach computer science, and to rethink the goals we have for using computer technology. Computing across the curriculum is listed as the initial recommendation for what can be done concretely to promote equity in computing [AAUW].
I found "Tech-Savvy" to be fascinating reading, and was struck by the overlap between that document and many of the ideas in CP4E. It is clear to me that achieving equity in computer science classes will require conscious efforts to change the current computer science culture. Next year I will be team teaching a pilot course at Yorktown called eGovernment. The course will combine a credit in Government with a credit in Computer Science. My co-teacher, Sue Rafferty, is an excellent teacher and I am looking forward to working with her. We share the concern over gender equity that is a key motivation for creation of the new course.
The central Computer Science focus of the course will be using technology as a tool to better understand and participate in government. I would very much like to teach some basic programming (with Python, of course), but I can only do this if it makes sense in terms of the rest of the curriculum. The possibility exists between now and next year to do some exciting and creative thinking out of the box about how to use Python in a Government class, and I invite anyone reading this who shares an interest in these goals to join in the discussion.
There can be no doubt that the most successful aspect of Yorktown's Python initiative is the development of advanced programmers. I have watched with awe and enthusiasm as programmers Jason Straw and Lex Berezhny have gone from being my students to being my teachers in a very short time. It is the power and excitement of Python that has helped make that transition possible. Jason and Lex have received tremendous support from the Python community, and they are rapidly becoming active contributors to this community. They are also leading the growth of the Python community at Yorktown, as more of our students are catching the Python bug after seeing what Jason and Lex are doing.
Perhaps the most exciting form our collaboration with the Python community has taken is our growing partnership with Jose Lacal and openclassroom.org [Lacal]. Jose was among the most enthusiastic supporters of Python's potential in education at last year's Python conference, and he has been a source of guidance and encouragement to us ever since. Jason and Lex are now working on a very exciting project under the OpenClassroom umbrella, and the best thing to do at this point would be to turn this discussion over to them...
A little over a year ago we were introduced to a new programming language. Now we are using it to write sophisticated applications. This quick learning curve was made possible by Python. Notable for its initial simplicity, it still provides a large feature set down the road. The appendix to our paper from last year [Elkner] sheds light on the specific benefits gained through using Python. Most noticeable of these is Python's ability to facilitate a fast development process, unrivaled by other programming languages.
We want to begin by describing our SPAM. We do not mean that email about free webspace that just re-populated your mailbox for the ten-thousandth time today, but rather the real meaty programs that we have already written. These are the programs that are not vaporware, but for the most part running and working Python software on which we cut our programming teeth.
Development of what will eventually become the OpenClassroom Zuite began at the Eighth International Python Conference when we met Jose Lacal from OpenClassroom. Jose was enthused by the work already being done at Yorktown and suggested that we combine forces. Over the Summer of 2000 Jose hired Jason Straw to write a Zope Product. The program would allow teachers to create homework assignments, and have their students submit the work back to the teacher.
This first Zope opus was finished in late October and was put into use in early November. The next month was spent debugging. Once all the bugs were stamped out, the program was cleaned up and an installer created. A Zope Product was created from that and the version 1 designation was given to it. We call this a Zite.
The Assignment Zite is now in use by four classes at Yorktown. There are two Computer Science classes which turn all of their home work in through the web and the only paper used in class is for notebooks, quizes, and texts.
When we started three issues really gave us problems. First was a problem with the basic idea. As Zite's direction was missing something, the design was updated over time. A new field for assignment locking and using a file upload field instead of a textarea were tried and included. Another problem was that there was no DTML way to import a file and create a document from it. It requires an external method, which has the disadvantage of being new to us. We had done lots of Python and DTML but never tried to put it together. Finally, we had a security problem. After users logged in they could get to the admin interface. About this time, your project mentor (Elkner:-) starts to panic as he realizes that his students can change the assignments. He expresses his panic by turning toward you and getting really mad. It is experiences like this that teach you to fix problems yesterday (not to mention to consider creating a short application which applies random bursts of low amperage current to the seats of teachers' chairs).
Thus, there are two interfaces to the Assignment Zite; Student and Instructor. The Students have an interface in which the only available options are submission and view.
The Teacher Interface is a little more interesting. Three things stand out when you look at it:
Having cooked up enough SPAM, we noticed that our recipes had many similarities. At the same time we were extensively exploring Zope, and we were especially interested in something called ZPatterns [Sarna], a Zope Product. ZPatterns is an elaborate system for developing adaptive web applications which emphasizes code reuse, modular programming, and separation of data versus implementation. We were confident that we could use this to greatly improve the way we develop our applications. This new approach supercharges the OpenClassroom project and our quest to build the most robust core for a school administration system.
A major hurdle we encountered as we began to explore ZPatterns was lack of solid documentation on ZPatterns and the Zope application programming interface. Rather than being a setback, this provided us with an opportunity to learn the inner workings of a complicated system by reading its source code. An intimidating concept at first, it ultimately proved invaluable to our development as programmers. In fact, sometimes it was easier to browse a source file than skim through documentation. Especially when code is well commented, reading it may be of greater value. We had been taught the value of commenting code in our computer classes, but this experience really made us see why it is important to do so. I can honestly say that we actually practice commenting now. By reading code we also learned new tricks, and interesting programming techniques. Python makes reading source easy, and we took full advantage of that.
With a comfortable understanding of Zope and a lot of enthusiasm, we started our work on OpenClassroom. Reflecting our past experience, we focused on code reuse and modularity, which would make it possible for several developers to work independently on separate parts, while consulting with the rest of the group. Further understanding of ZPatterns introduced us to several important programming techniques, specifically The Demeter Law and adaptive object-oriented programming [Lieberherr, (a)]. The Law of Demeter enforces a strict rule limiting object method propagation by limiting the interaction between immediate object methods. Adaptive object-oriented programming builds on this concept by providing patterns for application design [Lieberherr, (b)].
Each of us has more than a year and a half to go before graduation from high school. Through working on the OpenClassroom project, we are gaining experience and real world understanding that most of our peers could not even dream of.