---------------------------------------------------------------------------- ####### ######## ######## ########### ### ### ## ### ## # ### # Interpersonal Computing and ### ### ## ### ## ### Technology: ### ### ## ### ### An Electronic Journal for ### ######## ### ### the 21st Century ### ### ### ### ### ### ### ## ### ISSN: 1064-4326 ### ### ### ## ### April, 1993 ####### ### ######## ### Volume 1, Number 2 --------------------------------------------------------------------------- Published by the Center for Teaching and Technology, Academic Computer Center, Georgetown University, Washington, DC Additional support provided by the Center for Academic Computing, The Pennsylvania State University, University Park, PA 16802 This article is archived as GRIGAS IPCTV1N2 on LISTSERV@GUVM (LISTSERV@GUVM.GEORGETOWN.EDU) --------------------------------------------------------------------------- AN EXPERIMENT OF COMPUTER PROGRAMMING PRACTICE BY E-MAIL Gintautas GRIGAS Institute of Mathematics and Informatics Vilnius Lithuania The work was supported by the UNESCO under contract CII 408 018.2 ABSTRACT Teaching technique of computer programming including the elements of competition and using e-mail is presented and discussed. An experiment of computer programming practice with school students is described. The outcome of experiment is summarized, discussed, and conclusions are presented as guidelines for further work. The experiment of computer programming practice by e-mail was performed in Lithuanian schools. School students of upper grades (10-12) took part in the experiment. INTRODUCTION Computer programming is a part of informatics - a school subject compulsory at high schools. Therefore, practically all the school students have a chance to get the essentials of programming in the classes of informatics. However, there is a number of advanced students eager to get extra knowledge and skills in computer programming. Those gifted students are scattered in various schools. Many schools cannot offer them any more knowledge in programming than that defined by the curriculum for an average student. The task is to help those advanced students. Such a help may be ensured by some form of distance teaching (distance learning). It seems this situation to be common for many countries, especially for those of the developing world. A similar reasoning may be relevant not only for programming but also for any other school subject. However, two distinguishing features of the computer programming bring it into a favorable position among other subjects if e-mail is used as a medium for the distance teaching. The main product (result) of programming is an executable computer code. It may be transmitted by e- mail and then immediately executed. However, it is in fact impossible to transmit an executable code by the traditional media of distance education - a printed text. Extra technical skills necessary to operate an e- mail are similar to those of programming. So all technical difficulties related with the usage of e- mail may be easily overcome by school students interested in programming. The second observation is true only at the very start of distance teaching by e-mail while the first one remains in effect during the whole process of teaching. The choice of programming as a starting school subject for experiments of distance teaching by e-mail was also stimulated by our previous experience of teaching to programming, namely: Since 1981 the Lithuanian Young Programmers School had been using correspondence school methods (Grigas, 1992). This is a sort of a distance teaching, however, using exclusively an ordinary land mail (texts mailed as letters or printed matter) for the communication between teachers and students. A lot of experience was gained from the indirect self- dependent teaching of programming by means of competitions and olympiads (Dagiene & Grigas, 1993; Papert, 1980). PROJECT A project for distance teaching of programming by means of e-mail was developed on the grounds of previous experience, peculiarities of programming as a professional activity and its teaching. The following assumptions were taken into account and afterwards were reflected in this project. Practical activities are more interesting and attractive than theoretical studies for school students especially for those of lower grades (Papert, 1980). Elements of competition stimulate the learning process (Grigas, 1992; Schwiel, 1985). School students deal with small programs individually at school, while professional programmers usually work on large projects in teams. Programming is a proper discipline to develop thinking and creative skills of a student (Papert, 1980; Grigas, 1989). Just like in the Young Programmers School, the teaching is performed through problem solving in this project. The difference lies only in the aspects of problem formulation and the requirements for solutions of these problems. An algorithm is a corner-stone of solution at the School and the teaching of how to develop various algorithms is the main task of this School. The possibility of transmitting an executable program code by means of e-mail opened new possibilities to this project. Thus, it is reasonable to concentrate attention on computer programs. The requirements for problem solution (the job of a school student) are formulated so that these solutions were as close as possible to a real programming product made by a professional programmer. Of course, a student's product can be very small in size. A program must be accompanied by the documentation, including: 1) summary, 2) presentation of the idea of solution and its motivation, 3) user's guide with test samples and 4) programmer's guide. A group of school students possessing one computer with a modem makes up a team. There is no limitation on the students' number in the team. It is expected that every advanced student in programming will find place in such a team. As a matter of fact, the team may consist of only one member. The teaching session is divided into 4 phases: 1. Development of the first (preliminary) version of the programming product. 2. Analysis and evaluation of the products made by a fixed number (3-6) of teams (competitors). 3. Development of the final version of the programming product using their own first version of the product, products of other teams obtained at the beginning of the second phase of the session for analyses, and reviews of other teams as a result of the second phase. 4. Analysis and evaluation by teachers of the results obtained during all the previous phases and discussion (teleconference). Duration of each phase varies from a day to a week. It depends on the complexity of a programming problem and how busy school students are during the session (i.e., whether they have or have not classes), etc. Before the session(s) each team receives a package of materials: 1. Regulations of the session. 2. Requirements for each component of a programming product to be developed by students. 3. A sample of a programming product. 4. A questionnaire for the analysis and evaluation of all components of the programming product as well as the dialogue between a user and a program (computer). Those materials are the same for all e-mail sessions and may be distributed in advance by e-mail or as hard copies. The similar approach is successfully used in other distance teaching schools (Paulsen, 1992). The exchange of information during the session is organized in a standard manner. The coordinator supplies all the teams with the following startup information at the beginning of each phase 1-3 of the session: Phase 1 - formulation of a problem, Phase 2 - programming products of other teams to be analyzed, Phase 3 - reviews of other teams as a result of analysis. All teams send their results to the coordinator at the end of each phase 1-3. During the last phase a discussion is organized so that everybody can send messages to all the other participants of the session. EXPERIMENT The first experiment of programming practice according to the format given above was carried out from November 16 to December 11, 1992. Each phase lasted for 5 days (a week without the week-end). Turbo Pascal versions 5.5 and 6.0 were used as a programming language and the noncommercial version of FrontDoor communications package. PARTICIPANTS The call for participation was e-mailed to all secondary and high schools of Lithuania which have modems. The number of such schools at that time was 62. Only 9 schools joined the event. Those were located in Alytus, Druskininkai, Elektrenai, Kaunas, Kursenai, Silute, and Vilnius (3 schools), Kaunas. However, only seven teams took part in the experiment. Those were as follows: Druskininkai 3rd secondary school (3), DR; Elektrenai 3rd secondary school (7), EL; Kaunas High Technology School (10), KN; Silute 4th secondary school (5), SL; Vilnius High Electronics School (4), VLH; Vilnius Gymnasium of Science (9), VLG; Vilnius 6th secondary school (6), VL6. At the end of each line an acronym for the team is given and will be used in further references. The number of students in a team ranged from 3 to 10 and is indicated in the parentheses. PROGRAMMING TASK The programming task was to develop an interactive training program for Morse code. It was originally stated as follows: "Input data are represented as a text file. A computer reads input data, encodes the characters (letters, digits, and punctuation marks) into symbols of Morse code - dots and dashes, and outputs them as the sounds of a particular frequency (say, 1000 Hz.). The duration of a dash symbol is 3 times more than that of a dot symbol. The duration of the interval between two adjacent Morse code symbols of the same character is equal to the duration of a dot symbol. The duration of the interval between two adjacent characters within the word equals the duration of a dash, and that between two adjacent words is equal to the duration of 5 dots. A person accepts the sounds generated by the computer, recognizes, decodes them back into text characters, and immediately types them on the keyboard. The computer accepts these characters, compares them with the original text (input data), and checks, if the person's response is correct. If so, the process goes on. If not, the computer produces a special sound signal and repeats the whole word. If the person cannot manage to type the word in time, the computer waits for a while, i.e., the pause between the words is prolonged. The interactive work terminates when the end of input file is reached. Then the computer displays the outcome of the whole training session: the number of characters accepted, the actual symbol transmission rate (number of characters per minute), percent of errors, etc). It is programming task is to write a training program. The text transmission rate (10-500 symbols per minute) and the frequency of sounds (300-1500 Hz.) are obligatory parameters of the program. The text of words 'PARIS' is used as a default to measure the transmission ratio. The task formulation was not so strict or exhaustive. That was done deliberately in order to leave some room for school students to make their own options and decisions. The results of the experiment convinced us later on that all the successful teams managed to formulate the task more exactly and included various options, menus, etc. into their programs. The selection of the task has a symbolic motivation, too. The telegraph may be considered as a prototype of e-mail and the year of 1992 happened to be the anniversary of such an event: 155 years since the telegraph device was invented by Samuel Morse. Phase 1. Development of the preliminary version of programming product The enthusiasm in the first phase was ran high. However, the results were not encouraging. Two teams gave up. We managed to run only two programs (DR, VLG) on our computer without any problems. Some pieces of unavailable software (program modules) were used and not included in their program package in the program of one team (EL). The identifier of input data file was strictly predetermined in the program (e.g., "A:\MORS.DAT") but this was not told to the prospective user in some other programming products. Naturally, programs went to the runtime error "File not found". Thus, all the programs might be considered as runable, however, most of them only by the authors themselves and/or on their own computers. The bugs inside the programs were rare. The character transmission rate was incorrect only in one program (DR). One or two letters were missed from the Morse code alphabet in some programs. However, the interaction between the user and the computer was far from perfect in all the programs. The most common shortcoming was the lack of information on the display, especially when the user's reaction was illegal (e.g., illegal parameter value was typed, illegal key was pressed). There were cases when no information was displayed during the whole reception of the Morse code (EL),nor any information as to what the user may do next when the whole input text was read in and "played" out (DR). In general, the trace from the start to the end of the training session, running through the whole program, was not always easy for the user. There were some spelling errors in messages (KN), and some unfriendly phrases were used as error messages in reaction to the user's errors. Only 3 teams (DR, EL, and VLC) submitted all the required pieces of documentation. Other 3 teams did not present programmer's guide. However, they presented this document later at the end of the 3rd phase and included it into the revised programming product. The quality of the documentation was not satisfactory. It seemed that it was prepared very hurriedly. All the teams improved their own products more or less in the 3rd phase. Therefore, we'll return to this topic later on in a discussion on that phase. The first phase seemed to be most difficult. Phase 2. Analysis of programming projects Before the experiment it was planned that each team would review the results of other four teams assigned by the coordinator. Since only seven teams presented their results, it was decided to ask the teams to analyze the results of all the remaining six teams. The teams were provided with a list of mistakes, inaccuracies, imperfections, and other undesirable properties which are often found in programming products especially developed by students. The list contained as many as 62 items, e.g., "Accidental action of the user (e.g., pressing not engaged key) are not ignored", "The notation (e.g., names of variables) known only within the program is used in the messages to the user". This list could serve as a guideline to analyze of the programming product. However, the form of the presentation of the results of analysis was not fixed. The results of the analyses were submitted by six teams. One team (VL6) gave up. Only one team (SL) presented an exhaustive review of all parts of programming products. This was a merit of team leader Tatjana Balvociene. Reviews of other teams were not very systematic and exhaustive. However, they all together led to considerable improvements of the final version of programming products. The teams were asked to prepare the test data sets and to test all the programs under the review. The teams proposed various texts as input data tests for the training program. One or two sentences from a book, a magazine, or some favorite phrase were used as the test data. It was fun to read those texts. However, their value as the tests was not high: they did not ensure a systematic and exhaustive check whether all the characters of the alphabet were correctly encoded into Morse code. Only one team (DR) offered all the letters arranged in alphabetic order as a test. No test was proposed that would determine the transmission rate of characters and frequency of sounds, and to evaluate a dialogue. It turned out that the second phase was less difficult. However, as we learned from the further discussion, it was less attractive for the majority of the students. They expressed unwillingness to analyze others' programming products, especially, if the quality of such product was not very high. Phase 3. Development of the final version of programming product Before the start of the 3rd phase all teams received all critical comments made by other teams. In order to test students reaction to the criticisms of their colleagues we did not include our own comments. Indeed, the reaction was good. All the teams made considerable improvements in their products. Most of the improvements were connected with programs in general and with messages produced by a computer during the dialogue in particular. This was due to the fact that everybody can see these messages while executing the program and most of the critique was directed to them in the 2nd phase of the experiment. Indelicate phrases disappeared (VLG), the messages became more comprehensible, their style was improved. Despite numerous improvements, the weakest point in the programs remains the interface between a program (a computer) and its user. The dialogue with the user is not always fluent. In every program one can face situations that leave the user very uncertain, i.e., the user is not supplied with sufficient information concerning what he must or may do next (i.e., how to select the next step of the program to be executed, how to change options of the program, etc.). The programming style of all the programs was more or less satisfactory. All the texts are readable. Most of them were supplied with comments. The length of program texts ranges from 4K (KN) to 21K (SL) bytes. In the final version of the programming product all teams included all the parts of documentation that were required. The improvements made during the 3rd phase were mostly stylistic. Parts of documentation concerning the program text itself (a programmer's guide and user's guide) were written better than those more sophisticated texts concerned with the first phases of the development of a programming product (description of an idea of the solution, summary). Evaluation of programming products The final versions of the programming products of three teams (DR, VLG, VLH) were very close to the real programming product. Perhaps after one or two extra iterations (revisions, improvements) these best students' programs might turn into real programming products. The best product was developed by the team VLG. Later on, a contract was concluded between this team and the Center of Informatics and Prognosis at the Ministry of Culture and Education for the elaboration of the real programming product - A Morse Code Trainer - on the basis of the results of this experiment. The leader of this most successful team (a teacher) was Stasys Mykolaitis. The members of the team were as follows: Gintaras Banevicius, Vaidotas Brazauskas, Tomas Garboravicius, Antanas Lenksas, Saulius Narkevicius, Marius Skuntsikas, Jonas Udrys, Dainius Ulke, and Tomas Verbaitis. Information transmission and its costs A new component of expenditure in this experiment was payment for using telephone lines. An average amount of information transmitted during the whole session from the coordinator to one team was approximately 93K bytes, and that in the opposite direction was 27K bytes. The total amount is 120K bytes. The transmission rate varied from 300 up to 2400 bps dependent on the interferences in the telephone lines. The total transmission time of this amount of information was about 10 minutes. At that time the payment for the interurban telephone lines in Lithuania was rather low: one minute of the conversation by phone is equal to the cost of postage stamps for a letter. Therefore, the information transmission cost makes up only a small fraction of the total expenditure. OBSERVATIONS AND CONCLUSIONS Let us summarize observations made during the experiment and concerning the programming products as well as the process of their development. The experiment showed that school students better cope with the first stages of programming (making a problem formulation more exact, developing methods and algorithms for problem solution) than with the last stages (programming and debugging), in particular, with a development of a fluent dialogue between a computer and its user. This can be explained by the fact that more attention is paid to the teaching of algorithms in our schools and less attention is paid to programming and especially to programming practice. School students get basic knowledge of algorithms in the general classes of informatics. In some schools they get some acquaintance with programming too. However, they write the programs only for themselves in order to carry out some calculations there. The results of calculations (not the program itself as a product) is the goal. Another goal was declared in this experiment. Students were to elaborate a programming product for the user. This product (program text together with documentation) was the goal. Their activities during the programming practice modeled the work of professionals to some extent. They need the additional literature on the design of a dialogue between a computer and the user, and on testing of programs. More exhaustive teaching materials are desirable including textbooks, tutorials, examples of programming problems together with samples of their solutions. We are already planning some further work in this direction. The analysis of students' programming products by the peers leads to considerable improvements in these products. This may be explained by the fact that reviewing exerts some influence on the product in two ways. One way is direct and obvious: the author of the work learns about mistakes and shortcomings in this work from reviews. The second is indirect: when the author of the product becomes a reviewer of another realization of the same product, he gets an opportunity to compare his own product with the products under review and better to see mistakes and shortcomings in his own product. Thus, the analysis of products by students themselves may be expected to be an important component of learning and teaching. More investigations and special attention are needed in the further experiments. The distance teaching based on the e-mail is a proper medium for such experiments because it ensures a fast exchange of information. However, the teaching methods need some corrections in order to make the analysis more interesting and attractive for school students. The programming practice project was preliminarily planned as a prototype of programming competition. However, the experiment showed that it suits for teaching as well. Therefore, in future it may be used for teaching, for competition or for both together. It is planned to continue the programming practice according to this project by arranging nationwide teaching events of programming with the elements of competition as well as competition together with Latvian schools. ACKNOWLEDGMENTS The author thanks to Mr. Aidas Zandaris for carrying out the experiment as coordinator and for valuable suggestions. REFERENCES Grigas G. (1990) Some Aspects of Teaching the Art of Programming by Correspondence. - Informatica, v. 1, No 1, p. 156-166. Dagiene V. (1992) Lietuvos jaunuju programuotoju olimpiados [Lithuanian olympiads of Young Programmers]. - Kaunas, "Sviesa", (in Lithuanian). Dagiene V., Grigas G. (1993) Jaunuju programuotoju konkursai [Contests of Young Programmers]. - Kaunas, "Sviesa", (in Lithuanian). Papert S. (1980) Mindstorms: Children, Computers, and Powerful Ideas. New York, NY: Basic Books. Schwiel A. (1985) Evaluating and Improving Informatic Education in Secondary Schools by Means of Programming Contests. - Computers in Education. Elsevier, Sci. Publ. B.V., IFIP, 25-30. Grigas G. (1989) Informatics and Creative Thinking. - Third International Conf. "Children in the Information Age". Preprints. - Sofia, Part I, May 20-23, 229-240. Paulsen M. F. (1992) The NKI Electronic College. Five Years of Computer Conferencing in Distance Education. - DEOSNEWS, v.2, No.9, 1992. ---------------------------------------------------------------- BIOGRAPHICAL NOTE Gintautas GRIGAS Institute of Mathematics and Informatics Akademijos 4, 2600 Vilnius Lithuania tel. 7-0122-359601 fax. 7-0122-359209 e-mail: sps@sedcs.mii2.lt --------------------------------------------------------------------------- Interpersonal Computing and Technology: An Electronic Journal for the 21st Century Copyright 1993 Georgetown University. Copyright of individual articles in this publication is retained by the individual authors. Copyright of the compilation as a whole is held by Georgetown University. It is asked that any republication of this article state that the article was first published in IPCT-J. Contributions to IPCT-J can be submitted by electronic mail in APA style to: Gerald Phillips, Editor IPCT-J GMP3@PSUVM.PSU.EDU