3CSE.tex

\chapter{Computer Science Education}
\label{chapter:cse}

Learning to program is not easy and related problems are quite manifold. Some of the issues can be tackled with the help of educational software while others are more related to course design. Du Boulay~\cite{duboulay:1986} separates the difficulties of learning to program into five partly overlapping areas; \emph{orientation}, problems related to understanding \emph{the notional machine}, \emph{notation}, \emph{structures}, and \emph{pragmatics}.

Problems of \emph{orientation} are related to recognising the advantages of learning to program and what can be achieved after learning the skill. Closely related are the issues of understanding the properties of a computer and how to control one programmatically. A mental model of program execution on a computer --- functioning of \emph{the notional machine} --- should be formed at the right level of detail. \emph{Notational} problems relate to not only semantics but also the syntax. \emph{Structures}, such as loops or if-else statements, often prove difficult for novice programmers. Finally, mastering the \emph{pragmatics} of programming, including specifying, developing, testing and debugging a program, requires mostly practise.

Currently, the dominant theory of learning is constructivism according to which students actively construct knowledge rather than passively absorb it from lectures and textbooks. Glasersfeld~\cite{glasersfeld:1995} points out that teaching is not about giving students the right answers but it is far more important to teach students \emph{``to see why a particular conception or theory is considered scientifically viable in a given historical or practical context``}~\cite{glasersfeld:1995}. Theories are considered viable in relation to their context and it is critical to realise that there will always be more than one way to solve a problem.

In order to apply constructivism to computer science education two domain specific characteristics should be taken into account. The beginning computer science students do not have viable conceptions about the computer similarly like the beginning physics students have naive theories about their field. Additionally, the computer provides immediate feedback about whether a student's solution was successful.~\cite{ben-ari:1998, ben-ari:2001} The computer is not an easily accessible entity, whose inner functionality could be intuitively deduced. As we teach computer science with the help of hands on programming, the student will face in her first computer science course early on the inevitable conflict between her ineffective model of the computer and the behaviour of an actual computer. To some this feedback may be discouraging and contributes to the conception that programming is difficult.

However, Smith et al.~\cite{smith:1994} argue that misconceptions can have a productive role in acquiring more effective scientific conceptions and that expert reasoning is based on reused and refined prior and intuitive knowledge. The claims are based on the core of constructivism; new knowledge is created through accommodation and assimilation so that prior knowledge is either reasserted or remodelled. Smith et al.~\cite{smith:1994} conclude that knowledge acquisition is a gradual process and misconceptions can not be substituted directly for expert concepts.

By providing students with motivating opportunities to refine their conceptions and good examples on how those conceptions are relevant in practice, we hope to tackle the difficulty of orientation as well as ensure that students reach the course's learning objectives. Additionally, we hope that EDCAT could provide a simpler approach for the teacher to achieve set goals while easily managing the course and its exercises.

This chapter is organised into three sections. In Section~\ref{section:orientation}, we concentrate on the motivation of novice programmers by discussing successful exercise designs and topics. Section~\ref{section:edusw} outlines the relevant technical tools available for supporting novice programmers in their quest for mastering the skills required in development of computer programs. Finally, Section~\ref{section:conslusions} sums up this chapter and analyses the presented research areas from the point of view of implementing EDCAT.


\section{Designing Motivating Exercise Topics}
\label{section:orientation}

The programming exercises should most importantly provide an opportunity to practice the basic programming structures covered by the course. Nevertheless, they should be interesting so that students are motivated to work on and finish them as well as possible. However, an appropriate level of difficulty should be maintained taking into account that most of the students have no prior programming experience.

Most of the approaches to motivate the students in CS courses presented in the literature fall usually in one of the two categories; the use of game assignments or the use of graphics or media computation assignments. Furthermore, Sung et al.~\cite{sung:2007}, who themselves use games in computer graphics class, distinguish three separate types of courses that use games; \emph{games development}, \emph{games programming} and \emph{games development client} courses. Because we are not specifically interested in game design and development, we will only consider literature that describes \emph{games development client} courses that integrate games into introductory programming courses' curriculum by using games as programming assignments.

There are many successful examples of using games for teaching students the basic programming concepts in an introductory programming course~\cite{becker:2001, hansen:2004, jimenez-peris:1999, lewis:2006}. It is not really significant what kind of games are used, as long as they fit the course curricula. Although some games work better than others. Becker~\cite{becker:2001} substituted the assignments of Conway's Game of Life in a CS1 course and a drawing program in CS2 course with \emph{Minesweeper} and \emph{Asteroids!} respectively. She found that students were much more motivated than in previous years of the courses; they put in extra hours and continued to work on their games even after the submissions date. Using games already familiar to the students motivated students to outdo themselves while achieving the learning outcomes set for the course.

Furthermore, games can be used to introduce programming constructs that might otherwise prove too difficult for students to grasp. Hansen~\cite{hansen:2004} successfully used the game of Set to familiarise students with polymorphism and design patters --- topics usually seen too advanced for an introductory programming course. Similarly, Lewis~\cite{lewis:2006} introduced design and implementation aspects of a larger program by using a full semester long game project. Furthermore, in the course described by Lewis, the students had the same briefing but were free to choose their own topic for the game within the given technical requirements. The technical implementation of Lewis' project framework will be further discussed in Section~\ref{section:edusw}.

However, when choosing games for course material --- or equally media computation --- the teacher should consider the appropriate difficulty level. Jimenez-Peris et al.~\cite{jimenez-peris:1999} have found that by providing more background materials, even the assignments that at first seem difficult can be suitable for entry level programmers. By providing students with interesting assignments at an appropriate difficulty level Jimenez-Peris et al.~\cite{jimenez-peris:1999} have succeeded in introducing students a breadth of topics in computer science covered thoroughly in the later courses.

Regardless of the aforementioned successful uses of games in introductory programming courses, they do not provide a silver bullet. Bayliss and Strout~\cite{bayliss:2006} found that indeed not everyone is interested in games, and they should not be used on every course. 

Use of media computation, or MediaComp, in those cases might prove more suitable; originally it was designed to appeal to non computer science majors but has proven also successful among computer science majors~\cite{simon:2010}. Simon et al.~\cite{simon:2010} found that students learned comparable skills to a traditional computer science course. Although the focus is on the more complex use of core constructs and not that much on class or program design. Additionally, the retention rate was significantly higher than in a traditional course.

Assignments in MediaComp appeal to the students' creative side and showcase how programming is used to solve the real-world computational problems of sound and image editing programs. Additionally, they result in intriguing programs that students enjoy working on and are proud of.

As mentioned, MediaComp assignments have proven especially successful with non computer science majors as Guzdial and Soloway proposed in their first article in 2002~\cite{guzdial:2002} and Guzdial~\cite{guzdial:2003} later confirmed with the 2003 paper. Guzdial, based on these and his later works on the same subject, synthesises his findings into five hypothesis and analyses them against other research papers on MediaComp~\cite{guzdial:2013}.

Guzdial proposes that MediaComp assignments (1) reduce incentive to plagiarise other students' work, (2) result in higher retention rates than on a traditional course, (3) are more interesting to female students, (4) result in as good learning outcomes as in a traditional course, and (5) inspire students to take more computer science courses.~\cite{guzdial:2013} Of these hypotheses the second, the fourth and the fifth are especially interesting as we wish all of our students to successfully pass the course having met the set learning goals and motivated to continue onto further computer science courses, including non-mandatory ones.

Guzdial found that indeed in MediaComp courses students' retention rates were higher compared with the corresponding traditional course both in Georgia Tech, his institution, as well as other institutions. The student interviews revealed that students found the MediaComp approach motivating, because the course was tailored, relevant and provided an opportunity to be creative. Furthermore, Guzdial found that the sense of relevance is not uniquely attributable to MediaComp context and can be achieved with other topics as well.~\cite{guzdial:2013} Although research has observed higher retention rates in MediaComp courses compared with the traditional programming courses~\cite{guzdial:2013, simon:2010}, there is no clear reason as to why the MediaComp approach is successful.

The learning outcome hypothesis resulted in inconclusive results in Guzdial's work; the results were contradictory in two consecutive years of the same courses. First it seemed that the learning outcomes were different after the first course between MediaComp students and other students, however the differences evened out after the second course which was the same for all students.~\cite{guzdial:2013} However, those results were not repeated after the change of the assessment method. Later the results indicated that MediaComp students failed to reach similar learning outcomes than other students. However, they also had the least programming experience. The disparity between Guzdial's and Simon et al.'s~\cite{simon:2010} research can in part be explained by the relative differences in the compared courses as well as the assessment method.

However, even if MediaComp courses do not reach identical learning outcomes as the traditional CS1 courses, as long as the learning outcomes are comparable and the differences dissolve after the subsequent courses, there is still big advantage to choosing MediaComp over a non contextual approach as students will be more motivated to complete the course. Furthermore, as we are aware that a MediaComp course will inevitably nourish some skills over others, we can systematically focus on those areas that naturally get less attention by either modifying the assignments accordingly or by assigning assignments that solely concentrate on those issues.

Because there are students who are not necessarily motivated to learn to program in our course, Guzdial's fifth and final hypothesis is relevant in the context of this research. We want our Information Networks students to see Computer Science as a viable option for their minor subject. Guzdial found that less than 5\% of the students in MediaComp course continued on to the following course, specifically aimed at them, and less than 10\% of those students continued on to the computer science minor or changed to CS major~\cite{guzdial:2013}. The curriculum will most likely have no effect to the interests that students have before beginning their university studies.

In the light of Guzdial's findings, perhaps the most we can do is not to discourage our students who might be inclined towards computer science studies. Furthermore, by introducing the different areas of the computer science field early on, like Jimenez-Peris et al.~\cite{jimenez-peris:1999} suggest, we could capture students' interest and motivate them to pursue computer science concentrating on their area of curiosity.

What is common to both the games and the MediaComp approaches, is that students are given some freedom implementing their solution and get to work on relevant problems. Students get to use their own judgement and creativity in defining the rules of game play or designing an image filter while working on a project that results in a usable program. These approaches might indeed appeal better to non technically oriented students while other students might find them not serious on inauthentic. As our course is mandatory for students with varying technical inclinations, we should provide challenges to all skill levels.


\section{Educational Software Tools}
\label{section:edusw}

Many tools have been developed in order to help novice programmers. There are integrated development environments (IDE) designed specifically for students (e.g. BlueJ\footnote{ \url{http://www.bluej.org}} or DrJava\footnote{ \url{http://www.drjava.org}}) and web-based IDEs integrated with a submission system. There are tools that demonstrate and visualise code execution and those that analyse code and help to find elusive bugs. There are systems for grading and giving feedback on the exercises. However, there really are few systems that allow web-based program execution comparable to locally executable programs --- the kind that would allow interaction and provide a graphical user interface (GUI). 

While some program execution visualisation tools might be interesting from the technical point of view, they are outside the scope of this thesis. Even if they execute student written program code online and provide a visual context, they are primarily designed to aid students in code tracing and problems related to the notion of the notational machine. Similarly, we are not interested in web-based IDEs as such nor in automated assessment tools. However, some of them not only compile and run the program against test cases but also return the executable program for student's use and might allow user input during the execution process.

Section~\ref{section:wpe} reviews some of the web-based programming environments that allow the creation of interactive programs. In Section~\ref{section:graphics}, we inspect some libraries that could enable the easy creation of GUIs or otherwise visual content. Closely related is the use of skeleton projects as a basis of programming assignments, which is shortly discussed in Section~\ref{section:skeletons}.


\subsection{Web-Based Programming Environments}
\label{section:wpe}

W4AP~\cite{vazhenin:2005} is a programming and execution environment that students access via browser. The user can create and modify program files online or upload locally prepared files, which are then compiled into an executable application. W4AP also provides a monitoring system that tracks the execution of the compiled program in real time and visualises the program state. W4AP supports different kinds of projects and programming languages, including Java. To support multimedia projects the environment uses a specially designed Java library~\cite{vazhenin:2005}. Because the produced program is an applet, there should be no obstacle in creating an interactive application.

Ng et al.~\cite{ng:2005} propose a similar system to W4AP where students can access programming activities defined by the teacher, edit files needed for submission inside an editor in browser and submit files for compilation on a server. The result of a successful compilation is an executable JAR file that students can use locally. The focus of the system described by Ng et al.~\cite{ng:2005} is in distance learning and tutoring. The unique contribution of the system is an interface for leaving a help request to the tutors.

Furthermore, Truong et al.~\cite{truong:2003} describe a very similar system that provides students with gap filling exercises in Java and returns executable programs. Unlike W4AP or Ng et al.'s systems, Truong et al.'s Environment for Learning to Program (ELP) does not have any interaction with the tutors or analysis of program execution. The motivation is to lower the barrier to begin to program and it also integrates the lecture materials and tutorials to help students to solve the exercises.

Unlike the solutions described above Hitz and Krögeler~\cite{hitz:1997} outline a system that will accept student input prior to running the program remotely. The system supports fill in the gap type of C++ exercises that are embedded in the course material. Although input is supported, the interaction is nonexistent after the initial input values.

Perry's VECR (View/Edit/Compile/Run)~\cite{perry:2007} environment for C, Java, and Unix shell script programming exercises supports also exercises where students are required to create interactive GUIs with HTML forms. Additionally, the environment supports the creation of mathematical plots with a specialised library and the use of audio manipulation and output. The technical implementation uses Java applets that use only the simple functionality so that environment would work also with older versions of Java~\cite{perry:2007}.

Yoo et al.~\cite{yoo:2011} describe a solution for Scheme and Racket that can execute interactive REPL programs. WeScheme~\cite{yoo:2011} is implemented with more modern technology and benefits from the latest capabilities of HTML. The compilation is performed on a remote server initially as well as during the execution of the program when input is given in REPL. This requires a constant connection to the server during the execution. WeScheme has a sharing functionality, that allows users linking to their projects anywhere from the Internet; the users can choose whether the source code will be visible or not.

Another modern implementation of a similar system for Python assignments is presented by Edwards et al.~\cite{edwards:2014}. Pythy~\cite{edwards:2014} implements a modern web interface with the underlying installation of \texttt{git} for the version management of students' work. It is implemented as a Ruby on Rails application and uses a modified version of Skulpt (introduced in Chapter~\ref{chapter:web}). While the implementation supports media computation like image manipulation, the created problems rely on REPL for interaction.


\subsection{Graphics and GUI Libraries}
\label{section:graphics}
The most commonly used programming languages for CS1 courses (e.g. Python and Java) have powerful albeit complicated GUI libraries. Furthermore, these days students starting their first programming course are mostly familiar interacting with the computer through GUIs and working with command line can be seen as difficult. Many teachers have thus provided their students with easy to use but powerful ways of building GUIs.

RacketUI~\cite{hamid:2012} enables automatic web form generation based on students' program code written in Racket. After importing the RacketUI library, students only need to create a \texttt{web-launch} macro and specify labels for the function and its parameters. Using RacketUI seems quite easy, but there is little control over how the resulting GUIs look.

BreezyGUI~\cite{lambert:2000} is a toolkit for building realistic GUI applications with support for event-driven interaction. BreezyGUI is implemented on top of Java AWT and hides its intricacies from students. The ideology is still very much the same, so when students are ready they will probably have little trouble moving onto the real Java GUI libraries.

QuickDraw~\cite{stephenson:2009} offers a different approach with system and language independent multimedia application that works as a rendering engine. The functionalities provided by QuickDraw can be used by connecting an application via pipe to the QuickDraw application. QuickDraw provides both 2D and 3D graphics, audio playback and a text to speech engine which can be used through one sided pipe; Input capabilities require a bidirectional pipe. The student's program should print out QuickDraw commands and pipe the output to QuickDraw application. The syntax of QuickDraw is simple --- command names are descriptive and the amount of needed parameters is kept small by separating style and primitive commands.~\cite{stephenson:2009}

A more straightforward solution has been introduced by Roberts, who has created simple graphics libraries first in C~\cite{roberts:1995} and then in Java~\cite{roberts:1998}. The graphics libraries are constructed especially for novice programmers to use in CS1 course. They provide the basic drawing functions and hide the potentially confusing event loop based paradigm employed by typical graphics libraries. Especially Roberts' Java graphics library hides much of the required boilerplate and provides a conceptually strong object-oriented approach to programming with graphics.~\cite{roberts:1995, roberts:1998}

Bruce et al.~\cite{bruce:2001} created a graphics library that simplifies the use of Java's graphics functionality. The aim was to use the object-oriented approach from the very beginning of the CS1 course and familiarise students with the use of objects and methods. The library defines a number of objects that are placed on a drawing canvas that is controlled by a class that is an extension of a Java applet; The complete programs are indeed event-driven Java applets.

Similarly, Shultz~\cite{shultz:2006} proposes that the use of 3D graphics could be possible in CS1 and CS2 courses with the help of an appropriate simplified library. Learning 3D programming involves understanding complex concepts, which Shultz proposes concealing so that students can concentrate on relevant issues. Compared with QuickDraw's approach, Shultz's proposed 3D graphics API is much closer to the APIs used by the industry.


\subsection{Use of Skeleton Projects}
\label{section:skeletons}

The practice of providing the students with a project skeleton that they should supplement with the implementation of some classes or methods has been around already for some time. Grissom~\cite{grissom:2000} summarises the discussion on teaching students I/O in Java. Depending on the approach students can be given a class that encapsulates the needed functionality or a program with a GUI that students need to modify. Grissom himself proposes supplying students with a package they can integrate into their program. The use of the teacher prepared code allows students not to worry about aspects that are not yet relevant in their learning process.

Reges'~\cite{reges:2000} use of skeleton projects is very similar to what we have been doing in our course. The projects distributed to students implements mostly just the GUI code while students are in charge of implementing the logic of the program. Reges' findings are also quite similar with our experiences --- students like working with full programs although preparing the needed GUIs is time-consuming and students might sometimes misuse the teacher prepared codes.

Buck and Stucki~\cite{buck:2000} found similar difficulties as Reges while using skeleton projects to enhance the outcomes of student work. They have concentrated on the project design so that students do not need to work with GUI code directly and that the projects do not teach bad habits of program design. Astrachan and Reed~\cite{astrachan:1995} have similar aspirations by providing their students with complete applications that the students are asked to re-use and re-work. Students learn that well designed programs are easy to modify and get to work on full applications.

Sung et al.~\cite{sung:2008} have designed game themed assignments that contain material both for the students and the instructor of a course. The assignments are distributed to the students as skeleton projects which they complete by following step by step instructions to achieve a fully functional program. The students get to concentrate on the core programming concepts while the graphical functionality is already implemented. The materials are in theory freely available~\footnote{ \url{http://depts.washington.edu/cmmr/Research/XNA_Games/index.php}}, but unfortunately some resources are missing and the projects cannot be accessed.

As mentioned in Section~\ref{section:orientation}, Lewis~\cite{lewis:2006} uses a framework on top of which students implement their game project throughout the course. The students are provided with a JAR file containing the full framework without source files and first few class skeletons for their implementation. This is not a skeleton project in the same sense as students are given the supporting functionality as a compiled library; they get to learn how to use Java documentation and existing libraries.

The common finding in use of skeleton projects is that they provide a context of a real program. The instructor can show how a bigger program is build and allow students to concentrate on only the narrow learning objectives set for the week. By writing a package that encapsulates some difficult functionality or by implementing the GUI, the teacher helps the students to create programs above their skill level.


\section{Summary and Conclusions}
\label{section:conslusions}

Both the games and the MediaComp approach are successful solutions when we want our students to work on motivating real-world problems. However, the use of these approaches often requires visually impressive programs that our students are not yet equipped to fully implement on their own. This leads to the use of simplified graphics and GUI libraries, that are manifold and readily available. However, they might be deemed inauthentic by some students. Thus, we must keep in mind in our exercise design that we include real challenges for all skill levels.

The advantage of using a simplified library is that students are allowed to concentrate on the relevant programming concepts instead of understanding the intricacies of the implementation of a windowing system or rendering context. The same advantage can be achieved with the use of skeleton projects, that students are asked to complete with their code. Students get to work on full programs from the beginning of the course instead of unimpressive snippets. By using skeleton projects, we are also more free to utilise the real constructs and libraries of the language employed by the industry.

However, the use of skeleton projects is not without its own difficulties. Students may either accidentally or on purpose modify the supplemented code intended to be used as defined, and end up with a different program that the instructor intended. We should clearly specify what students need to modify and what they should not touch. Additionally, documenting and explaining the supplemented code or library is very important.

EDCAT is intended to provide students with modern interactive GUIs that are executed in browser; what has been previously described in the literature has no real examples of similar systems. The use of REPL in communicating with a program is neither a modern nor an appealing design choice --- as is not the use of Java applets. Additionally, we do not want to create a new system but utilise the existing ones combined with some new technologies.