Subsetting Language Elements in Novice Programming Environments

Subsetting Language Elements in Novice Programming Environments

Peter J. DePasquale
Department of Computer Science
Virginia Tech
660 McBryde Hall
Blacksburg, VA 24061, USA
pjdepasq@vt.edu
Phone: 540 231-5914
Fax: 540 231-6075
URL: http://csgrad.cs.vt.edu/~pjdepasq

 

Abstract

This author has concerns of two issues with respect to student instruction in CS1 courses (1st semester programming courses). The first is that novice programming students need not be exposed to professional strength programming tools so early on in their curriculum. Many of these environments have highly complex interfaces and include a plethora of features and tools (including profilers, project management features, etc.) which are not needed initially by novice programmers. In the author's experience, many times these additional "features" only confuse and frustrate the student. Secondly, I argue that a novice programmer's environment should grow in lockstep with their in-class experience. Novice programmers generally are introduced to simple, stand-alone concepts that can be easily digested and understood. Further concepts are then added in an iterative manner as additional language elements are introduced. In essence, what educators are doing in the classroom is subsetting a programming language and introducing successive supersets to the student participants. The programming environment novice programmers utilize should be modeled after the pedagogical style used in the classroom.

Keywords:

Novice Programmers, Programming Environments, Language Subsetting

Paper Category: Position Paper
Emphasis: Education


1. Introduction

Within the computer science community, there has been an examination of programming languages and integrated development environments (IDEs) for use in conjunction with teaching CS1 courses (introductory programming courses generally follow the syllabus for ``CS1'' within the ACM/IEEE-CS curriculum of 1991 [TUCKER]) to novice programmers. [FELLEISEN, KOLLING96, GRIES, DEEK, PERIS]. Most striking about these teaching / learning environments is that for the most part they seek to follow one of the following approaches:

Ironically these approaches seemingly lack a similarity to the methods by which we teach introductory programming in the classroom. When first introduced to a programming language, novice programmers generally are introduced to simple, stand-alone concepts that can be easily digested and understood. Further concepts are then added in an iterative manner as additional language elements are introduced. In essence, what educators are doing in the classroom is subsetting a programming language and introducing successive supersets to the student participants. By semester's end, the students gain exposure to a majority of the components of the programming language and usually have the ability to author programs given only problem requirements.

As they learn to implement (code) programs, students use either a simplified programming environment (mentioned earlier) or a programming environment with an interface and compiler designed for professional application development. While there are many commercial professional programming environments, there are few learning environments for novice programmers.

Are these CS1 students developing large-scale applications? Do they need full strength debuggers, or project management tools (such as source code control tools and profilers)? In many cases, these extraneous tools are never covered as part of the syllabus in novice programming classes and their presence in the programming environment only serves to confuse novice programmers (if discovered at all). To make matters worse, the courses that follow CS1 may assume that these tools were covered as part of the learning experience.

2. The Problem

This author argues that novice students do not need complex tools and that the introduction of a highly complex structured programming environment to these students is detrimental to a clear understanding of their first programming language and programming in general. In essence to require students to learn both a programming language and the command language of the implementation environment is akin to learning French and Spanish at the same time. A novice programmer's first development environment should be simple to use, provide clear consistent error and warning messages (which do not befuddle the student), and should grow in lockstep with the pedagogical methodology used in the classroom.

3. The Position

In support of the author's dissertation, a prototype programming environment for use by novice students is being constructed. The environment has three distinct goals in mind:

4. Justification

Through the use of this prototype, the author plans to explore the following hypotheses:

Obviously, this is a work-in-progress and lacks quantitative data to prove or disprove the hypotheses at this time.

The author has previously run a pilot study to monitor the reactions to a professional strength programming environment on novices programming their first project(s). The results of the study clearly indicated the need for a simplified interface, clearer error messages and more straightforward in-application help dialog windows.

The author plans to initiate an experiment in the fall of 2002 utilizing the prototype programming environment in a CS1 course offering at Virginia Tech. While the experiment design is still taking shape, the basic plan is to divide one section of students (roughly 150 students) into three demographically equal groups and study their academic results using one of three programming environments:

5. Related Work

The introduction to this position paper points out several related works that are currently available. While the exploration of programming enviroments and support applications for novice programmers and students alike has been ongoing for more than 30 years, there are several worth a closer look. Theses were selected as the best representative samples of related works that are currently in use today.

BlueJ

BlueJ is an integrated Java software development environment which contains an editor, compiler, debugger and other assorted development tools. What makes BlueJ unique is the graphical representation of executing objects with which a user can interact. That is, the user can instantiate objects (in the runtime environment, see them represented graphically and then send messages interactively to them (call methods contained within the object) or have objects interact with each other.

BlueJ attempts (with a good deal of success) to change the level of abstraction that users face while using their environment to produce Java programs. As with many programming environments, the users must deal directly with the file level while editing source code. BlueJ seeks to modify the file view to one of an object view, where the users can codify, compile and manipulate objects directly (interactively). More over, by having the BlueJ programming environment interact directly with the Java runtime environment, some tricky linguistic issues can be avoided. Specifically, a main method in Java must be of the form:

public static void main (String[] args) {

}

To cover this statement at the beginning of a course (so that one understands where their program begins) may involve a discussion on visibility modifiers, static methods, arrays and void return types. Creation and instantiation of Java objects directly in the programming environment (with the help of the runtime system) avoids the need to implement a main method and increases the level of abstraction to the user.

One of the arguments against the BlueJ environment is that it focuses less on program development and more towards the visualization of the object-oriented paradigm. Additionally, the environment abstracts the object-oriented paradigm to such a high degree that one could argue that the programming environment abstracts away the concept of a single method of execution of the resulting program.

DrScheme

DrScheme is an ongoing project of the Programming Languages Team at Rice University. DrScheme is a Scheme programming environment targeted toward CS1 students who are beginning to learn how to program.

DrScheme provides a graphical user interface to a Scheme programming environment. The DrScheme approach however, is somewhat unique in that it utilizes a tower of Scheme subsets within the programming environment. There are only four such subsets in the DrScheme environment: Beginning Student, Intermediate Student, Advanced Student and Full Scheme, each of which are coded into the application by the DrScheme developers and can not be modified. Users can select a language level (Beginning Student is the default level) prior to developing a Scheme program in the environment. The advertised design of Dr.Scheme is that each of the levels matches the natural introduction of Scheme to novice students.

While DrScheme is one of the most recent programming environments to utilize layers (or towers of the language as referred to in the documentation), this author has been unable to location any published empirical evidence on the efficacy of improving student learning through their environment.

ProgramLive

ProgramLive is a multimedia textbook authored by David and Paul Gries for learning Java and object-oriented programming. The ProgramLive software graphically reproduces a book paradigm for the students (complete with chapters, sections, page tabs and a spiral bound edge). ProgramLive contains narrative presentations using recorded audio tracks to present programming concepts to the learner.

Other features of the Gries effort include in-text quizzes, a glossary linked to the chapter prose by hypertext links, an index, and the ability for the learner to set a bookmark and return to it at a later point. One of the most interesting features is the code tool section, which is a simulated program development environment. The code tool features a panel of Java source code which is animated to a voice narration and a textual and graphical presentation in a second window. Users can enter this section to observe code development complete with a narrative track which can be stopped and repeated.

An more complete analysis of the ProgramLive system was not possible on the demonstration disk made available for review. Attempts failed to obtain a complimentary copy for examination purposes. It is hoped that complete review can be undertaken in the near future as the ProgramLive environment seems to have promising aspects to it.

GRASP

The GRASP (Graphical Representations of Algorithms, Structures, and Processes) project at Auburn University is a software package that parses Java, C, C++, Ada or VHDL input, and produces control flow and data structure diagrams of source code input. GRASP output aims to assist in the comprehension of a program flow of control during execution. This is accomplished by overlaying the coding display with a series of graphical notation objects (lines, boxes, ellipses) to denote the relevant portions of the input (source code) which affect the execution path.

GRASP utilizes a pre-installed compiler (though a command line interface) to provide an environment in which a student can author and visualize their programs. The graphical notation that GRASP provides can be generated without the use of an installed compiler. That is, the compiler is required only using the environment in which to compile the code. GRASP is implemented with a language recognizer to support the creation of the notation.

6. Conclusion

Novice programmers must learn a great deal to become proficient (even in the most rudimentary sense) in computer programming. This includes the syntax and the semantics of the language they are striving to learn; and the concepts and actions which lead to a meaningful executable program. Additionally, the command language of the programming environment into which software is to be written (which in itself has its own language that the student must master to properly operate it); and in some cases, the language of the source code editor must also be mastered.

This author believes that through the application of subsets to the programming language it can be shown that novice programmers will yield better academic results (higher grades), and have a reduced time-on-task (due to utilizing a programming environment which does not assume the learner is familiar with the breadth of the language). An additional side-effect may be shown that novice students may feel less intimidated by a less-complex and more intuitive interface. In conclusion, all signs point towards this type of programming environment being able to positively affect students in a CS1 programming course.

The author would be interested in discussing the issues of interface complexity (in programming environments) as well as the notion of applying subsets to a novice's programming language. This author believes that by reducing the complexity and applying controlled access to language constructs we may find improved student understanding of programming as well as lessening the anxiety of a CS1 course.

References

[CROSS] James H. Cross. Introduction to the CSD - Overview. Internet WWW page, at URL: <http://www.eng.auburn.edu/grasp/documentation/intro_to_CSD/c_index.html> (last accessed 5/1/2001).

[DEEK] Fadi P. Deek and James A. McHugh. A review and analysis of tools for learning programming. In Proceedings of the 10th World Conference on Educational Multimedia and Hypermedia and on Educational Telecommunications, pages 251-256, 1998.

[FELLEISEN] Matthias Felleisen, Robert Bruce Findler, Matthew Flatt, and Shriram Krishnamurthi. Functional programming: The DrScheme Project: An overview. ACM SIGPLAN Notices, 33(6):17-23, June 1998.

[HOLT] Holt Software Associates Inc. Ready to Program. Internet WWW page, at URL: <http://www.HOLTsoft.com/ready/home.html> (last accessed 5/1/2001).

[GRIES] David Gries and Paul Gries. ProgramLive: A Multimedia, Java-based Livetext on Programming. Internet WWW page, at URL: <http://www.datadesk.com/ProgramLive > (last accessed 5/1/2001).

[KOLLING] Michael Kölling. Why BlueJ? An introduction to the problems BlueJ addresses. Internet WWW page, at URL: <http://bluej.monash.edu/why/why.html> (last accessed 5/1/2001).

[KOLLING96] Michael Kölling and John Rosenberg. An object-oriented program development environment for the first programming course. In Proceedings of the 27th SIGCSE Technical Symposium on Computer Science Education, pages 83-87. ACM, February 1996.

[MICROSOFT] Microsoft Corporation. Microsoft Visual C++, version 6.0.< http://msdn.microsoft.com/visualc/default.asp> (last accessed 5/1/2001).

[PERIS] R. Jiménez-Peris, C. Pareja-Flores, M. Patiño Martínez, and J.A. Velázquez-Iturbide. Towards truly educational programming environments. In Tony Greening, editor, Computer Science Education in the 21st Century, pages 81-111. Springer-Verlag, 2000.

[TUCKER] A.B. Tucker et al. A summary of the ACM/IEEE-CS joint curriculum task force report computing curricula 1991. Communications of the ACM, 36(6):68-84, June 1991.