Programming Proficiency in One Semester:
Lessons Learned
Don Colton
doncolton2@gmail.com
Aaron Curtis
aaron.mosiah.curtis@gmail.com
Computer and Information Sciences
Brigham Young University Hawaii
Laie, Hawaii 96762 USA
Abstract
Programming is a fundamental skill for Information Systems and Information Technology students. It is also a subject that some students fear, avoid, fail, retake, and fail again. An effective, inexpensive, one-semester approach is presented. Early indications suggest dramatically improved student interest and performance compared to our previous two-semester approach. Key features include heavy use of web-based online programming, use of a scripting language (Perl), development of general-purpose programming skills, and a free textbook (PDF).
Keywords: programming, curriculum, Perl, online programming, free textbook


1. INTRODUCTION
Programming is a fundamental skill for information systems and information technology students and professionals. Although some professionals seldom write a program, the skills can come into play in understanding what subordinates do, in writing spreadsheets, and in automating processes.
Accreditation standards (ABET, 2008) and model computing curriculum recommendations emphasize the importance of programming proficiency, (Shackelford, 2005; Gorgone, 2002). However, many of our students in IS and IT seem to consider programming to be a CS activity, and one they would rather avoid. Programming is not something these students visualize themselves as doing in their future careers. Students within the IS and IT programs, therefore, have difficulty maintaining engagement in computer programming courses.
Introductory students in these programs often find programming to be boring and difficult (Jenkins 2002) and experience high rates of failure (Bennedson and Casperson, 2007). Many students respond to these challenges by concluding that they are simply incapable as programmers (Jenkins 2001). These perceptions of incompetence result in significant dropout / failure rates in introductory programming courses and poor performance in subsequent programming courses (Guzdial and Soloway, 2002).
Educator responses to these failings include believing some students really cannot program, thereby lowering expectations of student performance (Evans and Simkin 1989), attempting to innovate in their teaching techniques to promote greater engagement (e.g., Leutenneger and Eddington 2007), and blaming poor performance on “unmotivated” students (Gill and Holton, 2006).
In this paper, we outline our experience in developing a one-semester approach that meets the standards and curriculum recommendations of teaching programming fundamentals while creating a learning environment in which students can develop competence and confidence as emerging programmers. The preliminary results of this approach suggest that student performance and perceptions of computer programming have improved significantly. We anticipate that the lessons learned in our experience will be helpful to educators attempting to address these issues in their local institutions.
2. THE WAY WE WERE
Many of our students in IS and IT seem to consider programming to be a CS activity, and one they would rather avoid (much like Calculus). Despite accreditation standards and model curriculum recommendations, it is not something they visualize themselves doing as part of their job. We have to sell it well for students to decide to really engage in learning.
Some years ago we set the bar fairly low. Students read and discussed simple programs but did not actually write them. Some teachers were afraid that students would fail, become discouraged, and change majors. Such an overview did not give students adequate programming skills to actually do even small-scale projects.
We tried setting the bar higher, with a long, shallow learning curve, using a two-semester approach and numerous micro-projects (Colton et al, 2005; Colton et al 2006). It worked much better. Most students developed skills but were not eager to use them. For them programming was tedious instead of fun.
We looked at other approaches but were put off by the high proportion of “magic” that seemed to be involved. By magic we mean that students developed skills that work marvelously well in a small number of settings but did not transfer to more general settings. This felt like “training” instead of “education.”
Finally we abandoned a key element of our two-semester sequence, creating in its place a new two-semester sequence. As the change worked its way through the system, we discovered some useful economies that led eventually to the development of a single, one-semester programming course.
2.1 The Two-Semester Sequence
Our department hosts three majors: Computer Science, Information Systems, and Information Technology. Where possible, courses are made to serve more than one major. The introductory programming class is taken by students in all three majors.
(One goal of the introductory programming class is to help computing students select the major that will best suit them. As freshmen, students often do not understand the differences between CS, IS, and IT. Seeing all three types of students in the same class helps students self-identify more accurately.)
We used C in CIS 101 as our foundational language. This choice was motivated by several factors. First, C is well known and highly respected. Second, C is small enough to be well understood. Third, programming skills seem to transfer well from C to other languages students may need to learn later. Fourth, the class was to be taught by CS faculty and C or C++ or Java was their language of choice. C (C++) seemed easiest.
The learning objective from the CIS 101 course was that students be proficient with variables and data types (int, float, char) and be introduced to arrays, and that they be proficient with if/else and loops (while, do while, for) and be introduced to subroutines.
We used Perl in CIS 201 as our follow-on language. (For those unfamiliar with Perl, Appendix B gives a few short example programs written in this language.) This choice was also motivated by several factors. Scripting languages (like Perl, Python, and Ruby) are much faster for completing small- to medium-sized programming projects. Scripting skills are important for CS, IS, and IT students. Among scripting languages, Perl is well known and highly respected. It is not small like C, but it has a large body of open source shared archives (since 1995, the Comprehensive Perl Archive Network at http://CPAN.org/).
The learning objective from the CIS 201 course was that students transfer all their CIS 101 skills to Perl, thus seeing how easy it is to learn a second language, and in addition become skilled at database access and online programming (CGI) on a Linux platform. This also created the opportunity to introduce and develop skill with regular expressions. The capstone project was to build from scratch a small online store complete with shopping cart and inventory system.
2.2 Mistaken Assumptions
We assumed that after learning C for a semester, students would find it easy to learn Perl. They would conclude that it would be easy to learn additional languages later, as needed. This confidence was a major goal of using two different languages.
Unfortunately, for IS and IT students the single semester of C did not result in adequate programming skills on which to springboard into another language. Students had to relearn everything and the learning speed was only slightly faster than the first time they learned it.
In CIS 201, it was too easy to become frustrated by the slowness of students in demonstrating skills they should have already mastered. It was too easy to blame the CIS 101 teacher for failing to teach. It was too easy to blame the students for being stupid. In retrospect, it appears the problem was the course design in CIS 101. There was a mismatch between the expectations in CIS 101 and the abilities and interests of the students in CIS 101.
It was not immediately obvious, but instead of having two semesters of programming, students were having one semester of programming, twice. The synergy was missing.
3. TIPPING POINT
There were other frustrations with the existing programming sequence. The CS faculty did not see enough value in the CIS 201 class and wanted to remove their students from it, substituting an additional semester of Java. CS was one of the longest majors on campus in terms of credit hours, and felt the need to add new courses but also wanted to abandon old courses of limited value.
This gave rise to the question of whether CS students should learn a scripting language at all. It was decided that there was still a real need for scripting in CS. A suggestion was then made by CS to convert the CIS 101 class over to scripting. It was a totally unexpected suggestion, but it quickly developed broad support. The new approach would be to teach scripting in CIS 101 to all students, and more advanced scripting in CIS 201 to just the IS students. IS students would forego the learning of C.
The Resulting Curriculum
Starting August 2008 we converted the CIS 101 course into Perl and merged in the major features of the old CIS 201 class.
Under the old plan, the 201 class spent 1/3 of its time reviewing basic concepts from 101 but recasting them in the light of Perl. The next 1/3 of the course was online programming. The final 1/3 of the course was database using mySQL and simple queries (select, insert, update, no joins). Under the new plan it was hoped that the first 1/3 of the course would no longer be needed and new material could be added.
Because there were already students in the pipeline, in Fall 2008 both 101 and 201 were taught in Perl. In Winter 2009 the 201 students included some who had learned Perl before as well as some that had only learned C before. But over the course of Fall and Winter we made some interesting discoveries.
The immediate results were very interesting. During the first semester after the change, CIS 101 and CIS 201 were taught by the same instructor. CIS 101 students learned Perl as their first language, and CIS 201 students learned Perl for the first time, but as their second language. Remarkably, the 101 students did nearly as well as the 201 students. 201 students continued to perform largely as before. Also, CIS 101 students gave the teacher high ratings and CIS 201 students gave the teacher lower ratings.
Table 1 (in the Results section below) presents results in terms of learning objectives mastered by 101 and 201 students respectively. It shows that for many objectives, the top 90% of 101 students performed at the same level as 201 students.
Several theories emerged to explain this phenomenon. (1) Perhaps 201 students were frustrated that they were being asked to learn a second language when their first language had been boring. This frustration was realized as push-back against the course and decreased learning. (2) Perhaps 201 students had not learned C well enough that the programming skills were transferrable to a new language yet.
Whatever the reason (both seem to be plausible), it called into question our old theories about how best to teach programming. It was concluded by the faculty that if 101 students could perform at roughly a 201 level, then the 201 course was not needed.
It was decided to do away with CIS 201 and create instead a new capstone CIS 401 web programming course involving additional prerequisites and featuring the PHP language. The new course would have as prerequisites courses in webpage development (xhtml, css) and in database (SQL including join). This would allow greater development of marketable skills for our students.
CIS 201 was taught for the last time in May 2009. CIS 401 is being taught for the first time in September 2009.
4. PROGRAMMING IN ONE SEMESTER
The new model is for all things programming to be taught in CIS 101 such that students emerge with programming proficiency to the degree expected of IS graduates. That is a tall order, but we try to deliver on it by using the following approach.
First, students learn a single language. We teach them Perl but keep it simple, at least at first, in hopes that the skills will be transferrable to any other language they may need to learn. There is a great emphasis on portability of approach, skills, and knowledge. (For those unfamiliar with Perl, appendix B gives a few small sample programs.)
Second, we wrote our own textbook. This was a major step, not undertaken lightly, and not something we recommend to everyone. But the book, version 1.0, is in use and freely available to other schools for adoption as a primary text or as a supplement.
Third, we strongly emphasized online programming. We found that students respond enthusiastically to having their programs run on the web and being able to share them with friends near and far. At the same time we were very cautious to not delve too much into magic, where students do not really understand what they are doing but look up recipes in some index. This was greatly facilitated by having our own textbook.
4.1 Single Language
Ideally we might teach the language that all future employers will demand. Unfortunately, employers have not converged on a standard. Fortunately there are some favorite languages among employers, and most of these are similar to one another. We hope to teach a language that will be an easy basis for students to go on to other languages as their circumstances may demand.
We generally agree that any of several scripting languages could be used effectively. Our current choice is Perl. Factors in language selection include being typical, powerful, well known, portable, and well supported.
Typical: By this we mean that skills transfer well to other programming languages.
Powerful: By this we mean useful programs can be written fairly easily with the level of skill our students would achieve.
Well Known: By this we mean employers have heard of it, so it could be meaningfully listed on a resume.
Portable: By this we mean programs written for the Linux platform will also work on Microsoft or Macintosh and vice versa.
Well Supported: By this we mean there is a large user community that is actively helping each other and there are large collections and archives of program libraries available to everyone.
4.2 Textbook
Our textbook, Introduction to Programming Using Perl, is available free online as a PDF file at http://ipup.doncolton.com/.
The book is designed to support an introductory (100-level) college course that meets for about forty hours during a semester or quarter.
The book contains about 60 chapters divided into eight units for a total of about 340 pages. Most of the early chapters are designed to be read at the rate of one to two chapters per hour of time in the classroom.
We assume that students are not yet convinced of the importance of programming and may be taking the class simply because it is required. We motivate their study by emphasizing questions of “why” as well as showing “how.” We focus on introductory issues.
Advanced topics are usually mentioned briefly but with enough detail that students can follow up by searching the Internet. We assume the students of today are skillful at using search engines and other tools to get in-depth answers on topics of interest to themselves, once they know the topics exist and what they are called.
4.3 Online Programming
Our students turned out to be VERY enthusiastic about online programming. We believe this is for two reasons. (a) It allows them to share their work with friends and family anywhere in the world. (b) It allows them to integrate graphical elements easily.
During the first semester of our new course, we deferred online programming until almost the end of the semester because of the difficulty of parsing online input. Enthusiastic student response to online programming made us to look for ways to teach online skills earlier in the course.
The downsides of online programming are (a) the difficulty of maintaining state (conversation), and (b) the difficulty of working with “open set” input. (Restricted, “canned,” or “closed set” input turns out to be easily handled.)
We reorganized the course to give students very early success at creating online programs, starting from a simple graphics program that rolls dice or tosses a coin, and continuing closed set inputs, and finally reaching open set inputs through regular expressions.
Rolling dice or tossing coins requires very little beyond the “Hello, World” level of programming. We need only include a lesson on random numbers. The results are immediately impressive. Students have something to show off within the first two weeks of the semester. If/else is not required. Loops are not required. Subroutines are not required.
Closed-set input allows programs to respond to button presses. Because there are only a few possible inputs to consider, they can be handled through an explicit series of if/else statements. One classic game we program is Rock Paper Scissors, where the human pushes a button for one of the three, the computer program randomly selects one of the three, and a series of if/else statements resolve the winner. Graphics are included to improve the appeal of the program. We find this can be done by around the fourth week of a 14-week class.
Open-set input requires the use of mysterious library functions or an understanding of regular expressions. We take advantage of the opportunity to introduce regular expressions. However, because of the complexity involved, we feel this cannot be well done until about week 10 of a 14-week class.
5. LEARNING OBJECTIVES
Our learning objectives have been designed to be realistic for 80 percent of our students.
We do not assume any prior programming knowledge or experience. We do assume students have math skills to do simple algebra (solve x - 7 = 3) and that they have access to a computer with Perl installed.
5.1 Basic Expectations
Our standard is that basic material must be mastered so later courses can build on it. This is not a survey course or a high-level overview like, say, Art Appreciation. It is a “do it” class like, say, Drawing.
Because programming must become a basis on which other courses can build, we measure student performance on closed-book programming tests.
Mastery is divided into five topics: basics, decisions, iteration, arrays, and subroutines. By the end of the semester, students must master the first two topics to pass the class (with a D). They must master the first three to get a C. They must master all five to get a B. They must also demonstrate ability with some advanced material to earn an A.
Basics: Students write correct programs that use standard input and output to get information into and out of the computer. Programs run from a Graphical User Interface (GUI) or from a Command Line Interface (CLI). Students demonstrate the ability to use normal (scalar) variables to do calculations such as inches to centimeters. Students use fundamental mathematical operators including add, subtract, multiply, divide, and parentheses. Students understand that statements are executed in order, one after another, and that later statements can change the values of variables from what the earlier statements established. We introduce style rules including naming of variables and spacing of written programs.
Decisions (if/elsif/else): Students write correct programs that deal differently with alternate cases, such as whether to put AM or PM after the time, or whether a check will be honored or will bounce. This includes skill with Boolean operators (those yielding a True or False answer) such as comparatives (less than, greater than, equal to, not equal to) and conjunctives (and, or). This also includes following style rules of indentation and spacing to make complex programs more readable.
Loops (Repeated Actions): Students write correct programs that deal with repetition of actions, such as filling out a table. Style is also emphasized. Operators like ++ and += are mastered. next, last, and redo are introduced.
Arrays/Lists (Repeated Data): Students write correct programs that deal with lists of information. The foreach loop is mastered. push, pop, shift, unshift, and indexing ([1] and [-1]) are mastered.
Organizing (Subroutines, Functions, Methods, Objects): Students correctly write subroutines to better organize and structure their code. Local and global scope of variables is understood.
5.2 Proving Mastery
To prove mastery students are given a Final Exam that has five sections (one per topic area) each with several programs of varying difficulty. Students must correctly write those programs in a topic area before we consider it to be mastered.
(We chose to do this instead of having everyone do a major project for the unfortunate reason that too many students were turning in project work they did not understand. They were apparently turning in someone else’s work as their own. However, once a student demonstrates adequate mastery on exams, we DO utilize a term project as a way to motivate the A students and separate them from the B students.)
A large number of sample problems from the Final Exams are given in the free PDF textbook.
Because students do not all learn at the same rate, we do not care when students demonstrate mastery as long as it is by the last day of class. The jury is still out on how much this simply invites students to procrastinate.
The course grade is based almost totally on the final exam, so little else really matters. This takes the teeth out of midterms and homework assignments. What do we do about that? An all-or-nothing final can be pretty scary. So we compromise by giving the Early Final.
5.3 The Early Final
About once a week we offer an actual final exam. The questions are different each time, but are basically the same or of the same difficulty. The rule is that if a student passes any section of the exam, they don't have to take that section again. This gives them a reason to take the tests and to make progress. The entire final is too much to take on the last day of class. Knowing that part of the final is completed seems to be a good motivator.
Toward the start of the semester, the weekly exam covers only material already studied in class, so it is much shorter than it will eventually become. We allow about ten minutes for the test for the first few weeks. As more material is covered in class, new sections are added, making the test longer. Student performance also spreads out, with some students having completed the early sections while other students continue to struggle. We increase the amount of time allowed to 20 or 30 minutes. The last few weeks of the semester we allow the full class period once a week for the exam.
Because each Early Final is actually the real final, all the normal rules apply. The exams are closely proctored and performance must be at a final-exam level. Toward the start of the semester very few students pass anything. Toward the end many students are passing things.
The unit tests throughout the textbook give actual test questions that have been used in the Finals to assess mastery of each topic. Students are also allowed to keep a copy of the exam and the work they did. One day later they can share their efforts with each other.
During the exams we allow the students to test their work by running it at their local machine. However, they are not allowed to use any notes or outside resources, including web pages. They are only allowed to test their programs by running them locally. If there are reference materials we wish to make available, we put them in the test itself.
Scoring: We grade programs “by hand,” visually examining the student code. In addition to working, we expect student programs to demonstrate the requested programming style (indentation, spacing, comments, naming) to make the programs easy to read and understand.
6. RESULTS
It is probably not possible to give definitive results given the small sample size, but preliminary results are encouraging. The following table gives the percentage of students achieving 100% in each level of skill during our Winter 2009 term. Winter represents the main transitional term, where students in 201 had a previous term probably in a different language.  We do not have directly comparable performance metrics for 101 students under the old plan.
Nearly identical final exams were used across all sections of both courses. The same textbook was used in all courses. The same instructor taught all sections. The 101/201 column tells how well the 101 students did as a group compared to the 201 students.
Table 1: Mastery of Learning Objectives
Skill
101
201
101/201
Basics
93%
96%
97%
if / else
83%
92%
90%
Iteration
72%
80%
90%
Arrays
29%
32%
91%
Subroutines
9%
16%
56%
Online Skills
28%
24%
117%
Term Project
3%
20%
15%
N (students)
58
25

Performance on basics, if/else, iteration, arrays, and online skills was all at the 90% or better level for the group of 101 students compared to the 201 students.
With subroutines, only half as many 101 students performed at the 201 level. With term projects, only a small fraction performed at the 201 level.
The online skills section is noticeably better for the 101 students, but this may not be statistically significant given the small sample size. It seems however to suggest that 101 students may have been riding a wave of excitement while 201 students were fighting pre-conceived notions of whether it would be interesting.
7. INSTRUCTOR RESPONSE
The primary author of this paper also wrote the textbook. His experience has been that it is wonderful to control the textbook in such an intimate way because it allows the book to be adjusted from time to time to match the performance of the students and to respond to the difficulties they face. However, writing a textbook is a major commitment and takes a lot of time.
Another instructor to teach a full course using the book responded: “I really liked the format and pace of the class. I would like to extend [the book’s coverage] into [the next CS class] as well.”
8. CONCLUSIONS
Online programming is HIGHLY motivational to students because it facilitates sharing their achievements and allows graphical and other creative elements to be involved.
Programming proficiency seems to be achievable in a one-semester course that is well structured and adequately supported.
A free textbook (PDF) is available for use as a primary text or as a supplementary text in classes such as this.
9. REFERENCES
ABET Computing Accreditation Commission, (2008). Criteria for Accrediting Computing Programs, Effective for Evaluations During the 2009-2010 Accreditation Cycle. PDF accessed 2009-07-30 from http://abet.org/forms.shtml
Colton, Don, 2009. Introduction to Programming Using Perl. Available at http://ipup.doncolton.com/
Colton, Don, Leslie Fife, and Andrew Thompson. 2006. A Web-based Automatic Program Grader. ISEDJ 4(114). http://isedj.org/4/114/
Colton, Don, Leslie Fife, and Randy Winters, 2005, Building a Computer Program Grader. ISEDJ 3(6). http://isedj.org/3/6/
Evans, Gerald E., and Mark G. Simkin. 1989. What best predicts computer proficiency? Commun. ACM 32, no. 11: 1322-1327. doi:10.1145/68814.68817.
Gill, T. G, and C. F Holton. 2006. A self-paced introductory programming course. Journal of Information Technology Education 5: 95–105.
Gorgone, John T, Gordon B. Davis, Joseph S. Valacich, Heikki Topi, David L. Feinstein, Herbert E. Longenecker, Jr, (2002). Model Curriculum and Guidelines for Undergraduate Degree Programs (IS2002), ACM, AIS, AITP.
Guzdial, Mark, and Elliot Soloway. 2002. Teaching the Nintendo generation to program. Commun. ACM 45, no. 4: 17-21. doi:10.1145/505248.505261.
Jenkins, AMJ, and Davy, JR. 2001. Diversity and motivation in introductory programming. Innovations in Teaching And Learning in Information and Computer Sciences 1.
Jenkins, T. 2002. On the difficulty of learning to program. In Proceedings of the 3rd Annual Conference of the LTSN Centre for Information and Computer Sciences, 53–58.
Lahtinen, Essi, Kirsti Ala-Mutka, and Hannu-Matti Järvinen. 2005. A study of the difficulties of novice programmers. In Proceedings of the 10th annual SIGCSE conference on Innovation and technology in computer science education, 14-18. Caparica, Portugal: ACM. doi:10.1145/1067445.1067453. http://portal.acm.org/citation.cfm?id=1067445.1067453.
Leutenegger, Scott, and Jeffrey Edgington. 2007. A games first approach to teaching introductory programming. SIGCSE Bull. 39, no. 1: 115-118. doi:10.1145/1227504.1227352.
Shackelford, Russell, James H. Cross II, Gordon Davies, John Impagliazzo, Reza Kamali, Richard LeBlanc, Barry Lunt, Andrew McGettrick, Robert Sloan, Heikki Topi, comprising the Joint Task Force for Computing Curricula 2005 (ACM, AIS, IEEE-CS), (2005). Computing Curricula 2005, The Overview Report covering undergraduate degree programs in Computer Engineering, Computer Science, Information Systems, Information Technology, Software Engineering. (30 Sep 2005) http://www.acm.org/education/curricula-recommendations


APPENDIX
Free IPUP Textbook
http://ipup.doncolton.com/
Detailed Table of Contents
(First Edition)
0 Preface 17
0.1 Why This Book? 17
0.2 Why Programming? 18
0.3 Why Perl? 18
0.4 Coverage 19
0.5 Passing the Class 19
0.5.1 Basic Expectations 20
0.5.2 Proving Mastery 21
0.5.3 Advanced Expectations 23
0.6 Advanced Material* 24
0.7 Installing Perl on Your Personal Computer 24
0.8 Suggestions? 24
0.9 Exercises 25
I Basics 26
1 Output: Hello, World! 27
1.1 Our First Program 27
1.2 Making it Run 27
1.3 Making it Wait 28
1.4 Making it Wait Temporarily 28
1.5 The Language of Computers 29
1.6 Narrow-minded Wording 30
1.7 Exercises 31
2 Syntax and Semantics 32
2.1 Communication 32
2.2 Semantics is Meaning 33
2.3 Do What I Mean, Not What I Say 34
2.4 Syntax is Wording 35
2.5 Computers Are Stupid (But Fast) 35
2.6 Key Points 36
2.7 Exercises 36
3 Input: Hello, Joe! 37
3.1 Standard In 37
3.2 Line Breaks 37
3.3 NewLine 39
3.4 Exercises 39
4 Simple Variables 41
4.1 What's Simple? 41
4.2 Variable Names 42
4.3 Putting Something Into a Variable 42
4.4 Printing a Variable 44
4.5 Calculating with a Variable 45
4.6 Use Meaningful Names 45
4.7 Summary 46
4.8 Exercises 46
5 Basic Calculation 48
5.1 Add 48
5.2 Subtract 48
5.3 Multiply 48
5.4 Divide 49
5.5 Precedence and Parentheses 49
5.6 Assignment 49
6 Names, Parsing, Scanning 51
6.1 Computers Are Stupid 51
6.2 Robust 52
6.3 Parsing 52
6.4 Summary 53
6.5 Exercises 54
7 Style 55
7.1 Whitespace 55
7.2 Spaces 56
7.3 Separate Lines 57
7.4 Blank Lines 57
7.5 Names 57
7.6 Comments 58
8 Sequence 60
8.1 Equations 60
8.2 Steps 61
8.3 Sequence 62
8.4 Later 62
8.5 Exercises 62
9 Crafting Formulas 64
9.1 Coin Purse 64
9.2 Rough Formula 64
9.3 Improved Formula 65
9.4 Test Your Formula 66
10 Debugging 67
10.1 Syntax Errors 67
10.2 Run-Time Errors 68
11 Going Online 70
11.1 Using a Browser 71
11.2 Static Web Page 71
11.3 Hippopotamus Offline, Online 72
11.4 All on One Line? Adding Markup 73
11.5 Errors: What Could Go Wrong? 74
11.6 Roll The Dice 75
11.7 Putting Images on Web Pages 76
11.8 Summary 77
12 Games and Projects 79
13 Unit Test: Basics 81
13.1 Vocabulary 81
13.2 Exercises: Strings 83
13.3 Exercises: Numeric 84
13.4 Exercises: Numeric Story Problems 84
II Making Decisions 86
14 The If Statement 87
14.1 Syntax 87
14.2 Coordinated Alternatives 88
14.3 Exercises 88
15 Numeric Comparison 89
15.1 Numeric Operators 89
15.2 Exercises 90
16 Two Alternatives: The Else Statement 92
16.1 Syntax 92
16.2 Completeness 93
16.3 Exercises 93
17 Block Structure 94
18 Programming Style 96
18.1 Indentation 96
18.2 Special Numbers 98
18.3 Internationalization (i18n)* 99
19 Many Alternatives: Elsif Statement 101
19.1 else vs elsif 102
19.2 Exercises 102
20 And, Or, Xor, Not 104
20.1 Logical And 105
20.2 Logical Or 105
20.3 Exclusive Or 106
20.4 Not 107
21 String Comparison 108
21.1 Several Kinds of Equal 108
21.2 Comparison Operators 109
21.3 Upper Case, Lower Case 110
21.4 A-I, J-R, S-Z, etc 110
21.5 Barewords 112
21.6 Exercises 113
22 Remainder 114
22.1 Remainder 114
22.2 Cookies and Children 115
22.3 Calculating Leap Years 115
22.4 Integer Division* 116
23 Precedence 117
23.1 Precedence Tables 118
23.2 Unary Operators 119
23.3 Short Circuits 120
23.4 Assignment 121
24 Online 122
24.1 Rock Paper Scissors, Online, No Inputs 122
24.2 Adding Graphics 124
24.3 The SUBMIT Button 125
24.4 Rock Paper Scissors, Online, With Inputs 125
24.5 User Interface 127
25 Unit Test: Choices 128
25.1 Vocabulary 128
25.2 Exercises: Numeric 129
25.3 Exercises: Strings 131
III Repeating Actions 133
26 While Loops 134
26.1 Finding the Pattern 135
26.2 Explicit versus Implicit 135
26.3 Repetition 135
26.4 while Loop 136
26.5 last, next, and redo 138
26.6 Infinite Loops 138
26.7 if versus while 139
26.8 Exercises 140
27 For Loops 141
27.1 Comparison of “while” and “for” 141
27.2 Infinite Loops 143
27.3 Summary: if vs while vs for 143
28 Self-Modification 144
28.1 Plus Plus, Plus Equals 144
28.2 Dot (Concatenation) 146
28.3 Precedence of Self-Modification 146
29 Games and Projects 147
29.1 Hi Lo Game 147
29.2 99 Bottles of Carbonated Non-alcoholic Beverage 148
29.3 2 Nim 149
29.4 3 Nim 150
29.5 Variations 150
30 Unit Test: Repeated Actions 151
30.1 Vocabulary 151
30.2 Exercises 152
IV Repeated Data 156
31 Lists 157
31.1 Adding Items (push) 158
31.2 Deleting Items (pop, shift) 158
31.3 Adding Items (unshift) 158
32 Arrays (Indexed) 160
33 Walk the List 163
33.1 foreach 163
33.2 $_ (dollar underscore) 164
34 Split and Join 165
35 Unit Test: Repeated Data 167
35.1 Vocabulary 167
35.2 Exercises 168
V Organizing with Subroutines 171
36 Subroutines 172
36.1 Clean Your Room 172
36.2 The Subroutine Call 173
36.3 Syntax of the Call 174
36.4 Syntax of the Definition 174
36.5 Return 175
36.6 Code Factoring 175
37 Arguments 178
37.1 Direct Access 178
37.2 Unlimited Parameters 180
38 Global versus Local 182
39 Black Boxes 185
39.1 Formal Interface 186
40 Games and Projects 188
40.1 Games Menu 188
40.2 Input Edits 188
40.3 Input Edits with Default 189
40.4 Input Edits with Alternatives 189
41 Unit Test: Organizing 191
41.1 Vocabulary 191
41.2 Exercises 192
VI Complex Programs 195
42 Complex Programs 196
43 Nested Loops 197
43.1 Counting the Hours 197
43.2 Starbox 198
43.3 Right Triangle 199
43.4 Centered Triangle 200
43.5 Times Tables 201
44 Games and Projects (Loops) 203
44.1 Calendar 203
44.2 Double Nim 204
44.3 Tic Tac Toe 205
45 Hashes 207
45.1 Store and Retrieve 208
45.2 List by Key, Value, or Both 208
45.3 Lookup 209
46 Games and Projects (Hashes) 210
46.1 Animal 210
46.2 Exploration 212
47 Unit Test: Complex 215
47.1 Exercises 215
VII Publishing 218
48 Web Hosting 219
49 Passwords 221
49.1 Methods of Authentication 221
49.2 Creating a Password 222
50 HTML 224
50.1 Web Forms 225
50.1.1 <form> 225
50.1.2 <input> 225
50.1.3 Example 226
50.2 Tables* 226
50.3 Validator* 227
51 Forms: Web-based Input 228
51.1 Counting to N: Offline versus Online 228
51.2 Regular Expression Fundamentals 230
51.3 Testing 231
51.4 Prototype 232
51.5 Adding Two Numbers 233
51.6 Special Characters (plus and percent) 234
51.7 Debugging 235
51.8 Exercises 236
52 Regular Expressions 237
52.1 Recognition 238
52.1.1 License Plates 238
52.1.2 Character Classes 239
52.1.3 Character Ranges 240
52.1.4 Matching Several Characters 242
52.1.5 Multipliers 242
52.1.6 A Small Lie 243
52.1.7 More Shortening 244
52.2 Data Extraction 244
53 State: Persistent Data 246
53.1 Medical Records 247
53.2 Persistent Data 248
53.3 Clutter 248
53.4 Trust 249
53.5 Data Kept by the User 250
53.6 Data Kept by the Provider 251
54 HTTP Cookies 252
54.1 Advantages of Cookies 252
54.2 Disadvantages of Cookies 253
54.3 How To Set A Cookie 253
54.4 How To Read A Cookie 254
55 Database 255
55.1 Databases for Trusted Persistent Storage 255
55.2 MySQL by Hand 256
55.2.1 Connect to the MySQL Server 256
55.2.2 How To Quit 256
55.2.3 A Few Alerts 257
55.2.4 Change Your Password 257
55.2.5 What Databases Exist? 258
55.2.6 Creating a Database 258
55.2.7 Focus on Your Database 258
55.2.8 Databases Contain Tables 259
55.2.9 Create a Table 259
55.2.10Enter Data into Your Table 259
55.2.11 Display the Data in Your Table 260
55.2.12 Think Beyond the Example 260
55.3 MySQL by Program 260
55.3.1 Connect to MySQL 260
55.3.2 Issue a Query 261
55.3.3 Viewing Results 261
55.3.4 Display Your Data 262
55.4 $x and $y ?? 263
55.5 Sample dbselect Program 263
55.6 Advanced Queries 265
55.6.1 Column Data Types Allowed 265
55.6.2 Updating a Row 266
55.6.3 Deleting a Row 266
55.6.4 How to Add a Column 267
55.6.5 How to Delete a Table 267
55.6.6 Not Case Sensitive 267
55.7 Doing More 267
VIII Projects 268
56 Projects 269
56.1 Invent a Project 269
57 Risk Roller 271
58 Hangman Project 272
58.1 Requirements 272
58.2 Suggestions 273
58.3 Design 274
58.4 Sample Code 275
59 Hotter, Colder 278
59.1 Computer Picks 278
59.2 Human Picks 279
IX Appendices 281
A Answers to Selected Exercises 282
B Formatted Printing: printf 298
B.1 Background 298
B.2 Simple Printing 299
B.2.1 Naturally Special Characters 299
B.2.2 Alternately Special Characters 300
B.3 Format Specifications 300
B.3.1 The Argument List 300
B.3.2 Percent 301
B.3.3 The Width Option 302
B.3.4 Filling the Extra Space 302
B.3.5 The Justify Option 303
B.3.6 The Zero-Fill Option 303
B.3.7 Fun With Plus Signs 304
B.3.8 The Invisible Plus Sign 304
B.3.9 Plus, Space, and Zero 305
B.3.10 Summary 306
B.4 Printing Strings 306
B.5 Floating Point 307
B.6 Designing The Perfect Spec 308
B.7 Conclusion 309
C File I/O 310
C.1 Redirection 310
C.2 Explicit Reading 311
C.3 Explicit Writing 312
C.4 Close is Optional 312
C.5 Multiple Files 313
D Patterns 314
D.1 The Difference Method 314
D.2 Constant 315
D.3 Odd 315
D.4 Squares 315
D.5 Fibonacci 316
D.6 Triangles 317
E Random Numbers 319
E.1 Roll the Dice 319
E.2 Pick a Card 320
E.3 Flip a Coin 320
E.4 Normal Distribution* 321
E.5 What is Random Good For? 322
E.6 Truly Random or Not? 322
E.7 srand: Seeding the Sequence 323
F The True Meaning of Solution 324
F.1 Boys, Girls, and Dogs 324
F.2 Complexity 326
F.3 Statements are Sentences 326
G Binary Numbers 327
G.1 Bitwise Operators 327
G.2 What is Binary? 328
G.3 Binary Shortcut 329
G.4 32 Bits 329
G.5 Binary Numbers 330
G.5.1 Divide and Shift 330
G.5.2 Powers of Two 331
G.5.3 Numbers to Memorize 334
Index 335
APPENDIX B
Brief examples of Perl.
Following are some short programs in Perl to give a flavor for the language for those that may not be familiar with it.
Basic I/O
Print the words “Hello, World!”

print “Hello, World!\n”
Read in a name. Print on one line “I think (name) is nice.”

$name = <STDIN>;
chomp ( $name );
print “I think $name is nice.\n”
Simple Calculation
Read in two numbers. Print their total.

$x = <STDIN>;
$y = <STDIN>;
$z = $x + $y;
print “$z\n”;
Simple Decision
Read in a number. If greater than 10 print “Big”. If less than 5 print “Small”. Otherwise print “Medium”.

$x = <STDIN>;
if ( $x > 10 ) { print “Big” }
elsif ( $x < 5 ) { print “Small” }
else { print “Medium” }
Iteration
Read in a number. Print the numbers from 1 up to the number read in.

$max = <STDIN>;
for ( $i = 1; $i <= $max; $i++ ) {
  print “$i\n” }
Array by Index
Given an array abc, print the fifth element.

print “$abc[4]\n”;
Given an array abc, print the next to last element.

print “$abc[-2]\n”;
Subroutine
Write a subroutine abc that accepts two parameters and returns the sum of them.

sub abc {
  my $x, $y, $z;
  ( $x, $y ) = @_;
  $z = $x + $y;
  return $z }
Online (CGI)
Write a program that rolls two dice and displays the results in a web browser. (Notice that the html is barely adequate. We teach html in a different course.) This presumes that 1.jpg through 6.jpg are available to display. rand(6) returns a uniformly distributed random number between 0.00 and 5.99.

print “content-type: text/html\n\n”;
$d1 = int ( rand(6) ) + 1;
$d2 = int ( rand(6) ) + 1;
print “<img src=’$d1.jpg’>”;
print “<img src=’$d2.jpg’>”;