Some other languages that are sometimes named as candidates for teaching might be worth mentioning. These languages did not make it into our shortlist and were not analysed in detail. Here we present some reasons why they were not considered more seriously.
Beta
Beta [Madsen 1993] is a very modern object-oriented language with interesting language constructs. Its outstanding characteristic is the use of a single syntactic structure (the ÒpatternÓ) for the representation of a wide variety of concepts. Routines, classes and processes, for example, are all represented by a pattern. This generality provides a powerful tool, since operations applicable to a pattern (passing as a
CHAPTER 3: LANGUAGES
parameter, for example) are automatically available for a range of constructs. We felt that this unification does not aid the student in understanding the respective roles of the different concepts. The unification, in the context of first year teaching, becomes a disadvantage, since the resulting techniques remain largely unused, but simple concepts are clouded. Several other aspects, such as the fact that Beta does not enforce information hiding, contributed to the decision not to consider Beta further.
Sather
Sather [Omohundro 1991] can be seen as a cross between C++ and Eiffel. Its development started explicitly to create a Òsimpler EiffelÓ. Unfortunately, it adopts some of the characteristics that we mentioned as problematic in the discussion of C++.
These are:
· the inclusion of untyped objects and a reduction in the level of static type checking. Some type checks are static while others are dynamic.
· the need to explicitly identify dynamic dispatch. This is done in Sather on the basis of a variable holding an object reference. Only specifically marked variables will cause method calls to be dynamically dispatched.
Overall Sather operates at too low a level for good conceptual development. The reason for this approach is the aim for high efficiency of the resulting code, which is not a major concern for us.
Ada
Ada [DoD 1983] was, at the time we conducted our initial survey, not seriously considered because it did not provide essential object-oriented constructs. Since then, a new version of Ada (Ada95) has been released that supports object-orientation. This has certainly made it more interesting, but other characteristics still speak against Ada. The main problem is its size. Ada is a huge language (in terms of language constructs). While this might be desirable for an all-purpose programming language, it is certainly too daunting for first year students to learn. Defining and teaching a subset would be unavoidable Ð a situation that we identified as undesirable in chapter 2.
Ada95 also has disadvantages in the style in which its object-oriented features are implemented. Object-orientation is added onto the pre-existing ÒpackageÓ construct, with the result that some undesirable features remained in the language while some object-oriented features are implemented in unusual ways. For example, the receiver class of a message must be named as a method parameter, rather than the method being implicitly part of the class. On the other hand, functions may be written in a package that do not have the class as parameter Ð these are then independent (non- class) functions. This is further complicated by the fact that the programmer must be aware of the controlling parameters for dynamic binding. Dynamic binding is not automatic, and constructor functions are not available in a straightforward way. All of these details make Ada95 unsuitable for an introduction to object-orientation.
CHAPTER 3: LANGUAGES
Oberon
Oberon [Wirth 1988a] is not a pure object-oriented language, but a hybrid. Code may be written in an object-oriented or a non-object-oriented style. The prerequisites discussed earlier stated that such languages are undesirable.
3.6 Summary
A survey of the languages commonly used for teaching object-orientation reveals problems with all of them. The problems are of a different nature and of different scale for each of these languages. Two methods of analysis are available to us: experience reports from teachers who have used the language in practice and a comparison of the language against our requirements listed in chapter 2.
Experience reports are mixed in their conclusions, but a general trend can be found. Object-orientation itself was seen unequivocally as a powerful and valuable teaching tool, while almost all authors reported problems with specific languages and systems they used. Most of the studies reported difficulty in switching to the object-oriented paradigm from the procedural approach.
In analysing the languages, the language itself and the programming environment used both have to be considered. A well designed language is only half of what we need and is rendered useless by the absence of a suitable environment. With some languages, the environment was the source of the most serious problems. Thus, programming environments will be discussed in more detail in the next chapter.
4 Environments
The programming environment is the second major determining factor in the percep- tion students gain of the programming process. It has a large influence on the degree with which students can concentrate on the programming problem rather than become distracted by secondary issues. The programming environment can fundamentally shape the way programmers think about programming [Dumas 1995]. Yet, in discussions about introductory programming languages, the environment is often ignored. While teachers discuss at length benefits and drawbacks of particular languages, arguments about the suitability of particular environments are rare.
When using an object-oriented system for first year teaching, the environment increases in importance compared to the use of a procedural system. Since even small programs typically involve several files, issues such as multi-file-editing, compilation dependencies and linking become immediately relevant. A good environment that manages these issues is essential in order to let students focus on the programming task. In fact, it seems that many of the problems reported in the literature with teaching object-orientation have their roots in the use of unsuitable environments.
In this chapter we discuss the background and characteristics of some existing de- velopment environments, from early ÒtraditionalÓ systems to modern object-oriented integrated packages. We will point out shortcomings of existing systems and discuss what a good object-oriented environment should look like, emphasising again issues especially important for first year teaching. Some of the arguments presented here have been published in shorter form in [Kšlling 1996b].
4.1 Background
Concurrent with the development of object-oriented languages we have seen major improvements in program development environments. Whereas early systems simply provided an editor and a compiler, modern programming environments provide facili-
CHAPTER 4: ENVIRONMENTS
ties such as source code control, library management, support for group work, version control and integrated edit/compile/test/debug environments.
The focus of recent research in software development environments has been on a wide variety of problems that confront professional software engineers. They include emphasis and support for collaboration between multiple programmers [Smith 1997], debugging facilities [Baecker 1997, Ungar 1997], testing [Clarke 1988], low-level language (syntax) support [Fry 1997], cross development [Dumas 1995], design [Winograd 1995] and the software process [Notkin 1988].
As object-oriented languages have grown in popularity there have been attempts to bring together environment and object-oriented technologies [Haarslev 1990, Holt 1994, Meyer 1993]. Environments were developed that support the development of programs in object-oriented languages, sometimes supported by object design tools. In most cases the approach has been to adapt an existing software development environment to an object-oriented language. Such attempts have not, in general, managed to capture the potential advantages offered by object-orientation.
The most significant reason for the failure to fully exploit the possible benefits is that existing systems concentrate on abstractions that are appropriate for procedural languages. Consequently they provide support for development of procedural programs, management of source files, organisation of test data, etc. An object- oriented development environment should provide support for classes and objects as the fundamental abstraction. Attempting to use mechanisms designed for procedural program development to develop objects is not necessarily appropriate.
As a simple example, consider testing. A procedural program development environment will provide support for testing procedural programs. This would include setting up of input data, capture of output data and comparison of the actual output with some expected output data. An object development environment will provide an object test facility. This should allow interactive invocation of the interface routines of an object Ð a quite different paradigm than that required for procedural programs. An object-oriented test environment has several potential advantages, which include support for incremental development and the removal of the need to write test programs.
The lack of truly object-oriented development environments has created major difficulties for teaching object-oriented technology. In particular, students have major conceptual difficulties and tend to write procedural programs in an object-oriented language. This is particularly prevalent when using hybrid languages. If we expect our students to fully embrace object-orientation then we must provide them with an appropriate program development environment.
In systems traditionally used in many universities, such as Unix, program development has been based around a textual command line environment, where a set of separate tools is provided to support the development process. These tools (typically an editor, a compiler, a debugger and a make facility) are based on concepts developed in the 1960s and have not changed much since their introduction. They are basically stand-alone tools and have only been slightly enhanced to cope with the
CHAPTER 4: ENVIRONMENTS
increased complexity issues and new programming paradigms. The make command, for example, a tool intended to help manage the complex compilation process for large systems with source code that is spread over multiple files, often becomes a complexity problem itself.
This situation has been dramatically improved by the appearance of integrated graphical programming environments, which are most prevalent on personal com- puters. These environments are able to significantly reduce the management overhead in software development, integrating editors, compilers and debuggers into one coherent system, thus significantly reducing the complexity of the overall software development task. All tools are seen as part of the overall process to build an application and link smoothly together. A debugger, for instance, can use the editor to point to source lines corresponding to code currently being executed.