The Java programming language offers a number of features that make it attractive as a teaching vehicle:

where the displayTime() message invokes an appropriate method in the screen display object.

The ClockMechanism runs in its own thread of control. The sleep(1000) method causes the thread to suspend its execution for at least 1000mS. (This clock will run slow!)

4. Linking the objects

We now have two objects - a Clock and a ClockMechanism that each need to know about the other in order to request services:

We can achieve this by making sure that each object has a suitable reference to the other. However it might not be appropriate for the ClockMechanism, for example, to have access to all of the public interface of a Clock object. In Java there is a language construct called interface that allows us to limit the visibility of methods in an object.

The ClockMechanism object could have been written as:

private Clock myOwner;
public void run()
{

but the decision was taken to use an interface such that only the tick() method was available. The interface is called Timed and it is defined as:

public interface Timed
{

An interface is used to define the methods that can be called - in a sense it defines a new type - certainly as far as the Java compiler is concerned. The Clock class implements this interface:

public class Clock implements Timed

This is a good way of implementing the equivalent of "call- back" functions in Java. The Clock object creates a ClockMechanism object and passes it a reference to itself:

public class Clock implements Timed
{

The ClockMechanism is itself derived from the built- in Thread class and in its constructor it stores the reference to the Clock object it is to control:

public class ClockMechanism extends Thread
{

The entry point for the Java application is a function in the Clock class:

public static void main(String[] args)

This function create a new instance of Clock which, in turn, creates its own ClockMechanism. Each of these objects will stay in existence until one of them is destroyed because of the mutual references - the garbage collector will leave them alone. The call to clock.start() in the Clock() constructor will cause the ClockMechansim to execute its run() method. (Both run() and start() are methods defined in Thread and we override run() to provide the required functionality of our thread.)

5. Software engineering issues

6. The Abstract Windowing Toolkit (AWT)

The core of the model part of the MVC is now finished but it needs a public (inter)face - an on-screen presence.

The Java AWT provides classes that allow us both to create screen output and also to capture events.

To produce a visible window, decorated by the system's own window manager, it is necessary to create a Frame object - i.e. an object derived from the class java.awt.Frame.

For the clock program there are, at least, three strategies open:

Both of the options 1 and 2 suffer from the same kind of problem. A Frame object contains over 75 methods in its public interface and all the code in the Clock object has unrestricted access to them - probably not a good idea. Even worse - a Clock derived from a Frame has these functions in its public interface too! It is attractive in that it is easier to handle events as they can all be captured by the Frame object. As indicated above it would make sense for the user-interface code (view and controller) to be separate from the model code. Many of the example Java programs to be found in current textbooks take one of these two routes - generally deriving an application from Frame. For an example Clock program see pp 535-539 of the excellent SunSoft publication "Core Java" by Cornell and Horstmann.

Taking the third approach we will follow a similar route to that taken when creating the ClockMechanism. The user interface class will be derived from Frame but implement a much more limited interface called TimeDisplay, which is all that will be seen by the Clock. The Clock object should only be responsible for pulse counting and should be able to call upon a suitable display object to carry out the work necessary to present the result on screen. The interface object also needs to process user events and call appropriate methods in the Clock object to start, stop and reset the time.

7. The user interface (GUI) object

This object will act as a container for both the view and controller objects. It must itself be derived from the awt.Frame object so that it can appear on screen. It will implement the TimeDisplay interface so that the Clock object can talk to it:

public class GUI extends Frame

public GUI( Controllable it )
{

The GUI object contains two sub-objects, a DisplayPanel and a ControlPanel and also a reference to the Clock object it is to control. This reference is via a Java interface:

public interface Controllable
{

This interface makes accessible only those methods that are appropriate to a controller. In particular, a controller cannot see, and therefore cannot use, the tick() method. In the same way, the ClockMechanism object cannot see or access the methods start(), stop() etc.

The two sub-objects are both derived from awt.Panel. The displayPanel constitutes the upper section of the screen display holding the time output. The ControlPanel holds the "Start","Stop" and "Reset" buttons.

Looking briefly at the code of the constructor for a GUI object:

setTitle( "GUIClock" ) - this sets the text that will appear in the border of the visible window.

add( "North", displayPanel ) - and the similar line underneath it are responsible for positioning the sub- objects within the window - the actual position is the responsibility of a LayoutManager see below.

pack() and show() cause the Frame to first resize itself so that it accommodates its sub-objects correctly and then to become visible on screen.

8. LayoutManager classes

The Java awt expects that programmers describe how a visible window is to look in terms of "positioning rules" rather than requiring that each object be placed at a prescribed pixel position. This relieves the programmer of the need to interrogate the system to find out the screen resolution etc and it is necessary to make platform independence simpler.

For a Frame object, the default layout is called a BorderLayout. It permits 5 sub-objects to be positioned thus:

The "North" and "South" areas will resize to the maximum width of the Frame but will be no deeper than necessary to hold their components, the "East" and "West" areas expand vertically and the "Center" will expand in both directions.

The Panel objects use a simpler FlowLayout where sub-objects are inserted and centred on a line by line basis. The constructor for the DisplayPanel illustrates this:

public class DisplayPanel extends Panel

public DisplayPanel()
{

Here the four sub-objects, two Label and two TextField objects are added and will appear in the order they were inserted. Resizing the panel (on-screen) so that it is narrow but taller will cause the objects to appear in more than one line. The layout of the ControlPanel is similar.

9. Implementing the GUI functionality

The functionality of the display object is achieved through the single method:

public void displayTime( int min, int sec )

and the GUI object simply passes its values to this method.

The controller object is rather more complicated and requires the processing of events generated by the user.

10. AWT Events

Events are generated either by a user's action or from the operating system. Pressing a key, moving the mouse, clicking a mouse button, uncovering a window can all cause events to be generated. The system always considers a particular awt component to be the legitimate target of the event and it is to this object that the event is sent first. In Java, all events are instances of the class Event and there are a number of public fields of an Event object including:

A method receiving an event can interrogate these fields and decide how to process the event.

10. How do events get to objects?

The simple answer is that a handleEvent( Event e ) method is called with the Event passed as a parameter. However, if the event is not handled in the handleEvent method then a "convenience method" is called for specific classes of event - action(), mouseEnter(), keyDown() .. and so on. Appropriate parameters are passed to these methods. Most component objects are located within AWT containers and, if the component does not handle the event, the container will eventually receive the event - first via handleEvent() then through an appropriate convenience method. Frames and panels are such containers objects.

In the example under consideration, the GUI object is responsible for interacting with the Clock. It is necessary that the processing of the WINDOW_DESTROY event takes place here as it is the object that will first receive the event - when the user closes the window. The following method must therefore be a member of the GUI class:

public boolean handleEvent( Event event )
{

IT IS ESSENTIAL that this method calls the over-ridden method of the parent Frame object otherwise the convenience methods will not be called. The action() method is used to process the responses from buttons as far as interacting with the Clock object is concerned:

public boolean action( Event event,

The argument parameter is, in the case of a Button object, a string containing the button label. The required functionality is provided within the Clock object itself by the following methods:

public void start()
{

public void stop()
{

public void reset()
{

public void kill()
{

There are now two threads of control running - the one running the ClockMechanism and one running the awt components. It is possible that the user could reset the clock just as a time update was taking place. Java provides mechanisms for preventing this type of problem which are outside the scope of this article. However it is possible to provide a guaranteed solution by not allowing reset to occur if the clock is running. The state model presented earlier shows how this could be achieved. It is implemented in the ControlPanel object.

11. Implementing the state model

The ControlPanel object can capture the button events and respond to them before passing them on to the GUI.

The ControlPanel object uses methods available on a button to enable or disable it - which show as black/grey labels. The full code for the ControlPanel is:

public class ControlPanel extends Panel
{

Note: how the action() method returns false even when it has handled a button press. Returning true would prevent the event from reaching the outer Frame object.

12. Software Engineering Issues

By using a number of classes it has been possible to distribute the intelligence around the system - a guideline for object-oriented design (see p64 of Wirfs-Brock ):

13. Conclusion

The Java language is an attractive proposition for software engineering education. It offers a number of important facilities including object-orientation, multi- threaded programming, events, socket-based communication and so on. It is possible to use it to illustrate many of the principles that we, as academics, would like our students to experience. It is important, however, that we realise that many of the "advanced" features may impinge upon otherwise simple programs. (e.g. exceptions must be handled, several threads are always present) The language is also changing. Under the new release (the JDK1.1), the event handling described in this article would be implemented differently although the main architecture of the application would remain essentially unchanged.

References

The full text of the presentation given at the "Java in the Computing Curriculum" meeting together with source code for a set of example programs that further develop the theme of this article sareto be found at the following URL:

The Distributed Computing module is one of the second level modules offered by the Computing Department in its undergraduate programme. The module aims are twofold: to introduce computer networks and to provide some experience of programming simple distributed applications. Assessment is by examination and course-work with each component carrying an equal weight. The workload consists of roughly eighty hours of work delivered over a twelve week period. Contact time is a one hour lecture reinforced by a one hour laboratory session; the remaining time is private study. Material pertinent to the course (with relevant exercises) is available on-line at an internal departmental web site. The course is split into two halves the first half emphasises the structure of computer networks and has no programming content; the second part is to introduce client/server systems, and to demonstrate their implementation. It is this second half of the course that is the subject of the rest of this paper.

2. Course Content

A previous version of the module had used C/C++ as the implementation language. The intention was to build upon the skills acquired in the first level C++ programming modules. The characteristics of Client/Server systems were described starting with simple one-shot clients and ending with concurrent servers. The laboratory work was presented at two levels of abstraction. The lowest level required that the student acquire : a knowledge of UNIX (SunOs 4.1.3) sockets[1] and their strengths and weaknesses, plus an appreciation of forking processes and/or using lightweight threads and semaphores. The higher level of abstraction involved familiarity with remote procedure calls (rpc) [2] and the use of rpcgen.

Examination results indicated that students did obtain a useful overview of these topics in the time available, because the set questions were generally answered satisfactorily. The laboratory exercises however proved to be far more difficult. Many students did not get beyond the initial simple problems. Relative inexperience, plus the general pressures on time, ensured that only the brightest and most dedicated students progressed to the more interesting problems. Many found their C++ experience did little to equip them for the general messiness of using processes, threads and semaphores in a UNIX system. Often they completed the module with a sense of dissatisfaction at being unable to progress to the more interesting problems. It became obvious that the laboratory exercises were not achieving their aim of reinforcing the material presented in the lectures. It had been anticipated that several of the low level programming requirements would prove difficult for weaker students. However, the feedback received at the end of the course led to the reconsideration of the laboratory work in its entirety.

3. The case for using Java

Examination of socket based examples provided in several texts [3][4][5], led to the consideration of Java as a possible substitute for C++. It became apparent that Java was a language offering several advantages over C/C++ for programming network based applications of the type covered by the laboratory exercises.

As a platform independent language Java sweeps all operating system idiosyncrasies out of sight, and provides a cleanly defined, often simple, interface to all major language features. Happily, all features required for the laboratory exercises: sockets, threads, and mutually exclusive access to shared resources, were included as part of the Java language.

Socket support comprises two classes Socket and ServerSocket. These classes elegantly capture the fundamental asymmetry between socket use in client and server programs, and help enforce this difference in usage. Several low level operations (for example, the establishment of a connection) are performed internally and become transparent to the programmer, resulting in a simplification of the program code. A selection of socket constructors provides added functionality enabling the specification of the network host as either an Internet address or a string that is transparently converted to an Internet addresses (by performing a DNS lookup). Sockets come equipped with easily accessible streams making the task of writing or reading data to or from processes straightforward. The result of this thoughtfulness in the implementation of the socket class is to reduce the code required to create and support a connection between client and server. The resulting programs are clean and simple. Figure 1 presents a fragment of code to illustrate the principle.

Concurrent processing using threads is elegantly supported. Classes are executable as threads, either by creating them as an extension of the base Thread class, or by creating them as an implementation of the Runnable interface. An interface presents a list of methods that must be implemented by a class. Those classes implementing the Runnable interface must contain a single method called run() which executes when a thread containing a reference to the Runnable class starts. Using threads, one can write a concurrent server in only a few lines of code using a single ancillary class to handle communication with the client process. Whenever the server accepts a client connection it creates a thread to handle all further communication with that client. The code to provide this functionality is quite simple (see figure 2). Encapsulating shared data in a class and providing synchronized methods to access the data enforces exclusive access to shared resources. The programmer simply needs to add the keyword synchronized in the method definition. An example definition heading would be public synchronized int getData(). Java handles synchronisation using hidden internal monitors. If two threads attempt to access a synchronised method simultaneously, one will be blocked until the other completes.

Making a decision to use Java instead of C/C++ as the language of choice is really only swapping one set of constraints for another. One has to weigh the simplicity of the Java code against the problems inherent in learning a new language in the brief time allocated for practical exercises. Whilst Java is syntactically quite similar to C++ it nevertheless differs in significant areas. I/O is often a problem in any language. Unfortunately, stream based I/O in Java is significantly different from that in C++. Therefore, I/O was one area where one could expect there to be problems and misunderstandings. Another potential problem might occur because Java is a diverse language with many pre-defined classes. Java is not a "lean" language. It comes with wide ranging support in many areas and with many built in classes. Some might find the sheer diversity initially overwhelming.

On the positive side, four other modules offered on the course had already introduced the concept of object-oriented programming. Students were familiar with classes and inheritance albeit from a C++ viewpoint.

4. The new course

It was decided to trial the use of Java in this module. The expectations were that the simplicity of the Java code would allow most students to be more productive than in C or C++, and that the laboratory exercises would again become a reinforcement of the lecture material and less of a encumbrance. The significance of the burden placed on the student in learning Java was unknown. The expectation was that the simplification in code would make the exercises easier, thus promoting a sense of achievement which would carry students through the learning curve resulting in a sense of satisfaction instead of one of underachievement. Focusing attention to a restricted subset of Java ought to flatten the learning curve. Therefore, the topics covered would be confined to: classes, sockets, threads, exception handling, synchronised shared objects, and stand-alone programs, with emphasis placed on those aspects syntactically quite similar to C++. Topics such as Packages, interfaces, threadgroups and the Abstract Windows Interface(AWT) would not be covered.

The introduction of a higher level of abstraction, as represented by RPC in the previous course, was problematic. The equivalent of RPC, remote method invocation or RMI, was then only at a development stage and so it was not really practical to cover this topic. However, it was also impracticable to cover RPC because this would require a switch back to C after only two to three weeks of Java programming. Regretfully, the RPC material was replaced by new material covering the world wide web and three-tier architectures. The new course syllabus was:

The laboratory exercises associated with the module were:

5. Evaluation of the course

Java was used as the implementation language for the Distributed Systems module which ran in the first semester of the 1996-1997 academic year and was taken by over two hundred students. One immediately noticeable outcome was that the course really did run more smoothly. The number of requests for help were significantly fewer than the previous year. The switch from C++ classes to Java classes, with its attendant change in syntax, seemed to pass almost unnoticed, even threads did not cause any undue concern. All managed the initial exercises and were able to write and test a simple concurrent server. The initial practical exercises were automatically assessed; however the student stock- server solution had to be demonstrated. For example, the ability to write a network client was assessed by requiring the student to write their client so it would implement a randomly generated protocol assigned to them. They had to connect their client to a testing server on a given port. If their client successfully implemented the protocol, a unique random key value was returned. To gain the marks associated with this task, the student had then to fill in a form on a web-page to submit their key to an on-line database administrator. The simple servers were tested in a similar manner.

The problems encountered were mainly concerned with I/O and the use of parsers to read numbers from a stream. Several explanatory example programs had to be given as examples and the point covered during lecture time. Some students had to be persuaded that a different language did not necessarily mean that a radically different syntax was being used (for example that a for loop had the same syntax in Java as in C++).

One unexpected bonus was the interest generated simply because Java was the language used. The fact that Applets and the AWT were not being covered did little to affect this enthusiasm. Attendance at laboratory sessions was consistently high with many students asking how they could put Java on their own machines at home.

Feedback at the conclusion of the module was very positive and very supportive of the use of Java on this course. This feedback was substantiated in the examination at the end of the module with over 40% of students attempting both and over 70% at least one of the questions associated with this part of the course. Some comments are listed below:

A colleague in an associated college, who was also presenting this module, did prepare the ground a little better by replacing the last couple of labs in the first half of the course with an introduction to Java. This effectively replaced the first Java exercise and allowed a longer acclimatisation time before the client/server exercises. He reported very few problems in changing to Java. This model will be followed in the presentation of the module.

6. Conclusions

Java proved to be an ideal language for use in this module. Its features support the implementation of client/server systems in a clean, logical and simple way. The simplicity of its code meant that most students quickly produced working programs which gave them the confidence to attempt the later examples. The course ran more smoothly and with fewer problems than in previous years where C++ was used.

References

The Department of Computing at Lancaster University decided to change its first year programming language to Java in the current academic year (1996-97), one of the first British Universities to do so. We are currently something like two- thirds of the way through the new course. This paper describes the structure of the course, and our experience with teaching the Java language.

The Computer Science degree at Lancaster is divided into Part I in the first year and Part II in the second and third year. It is a broad course in the central areas of computer science. In the first year, students intending to major in Computer Science study three subjects, one of which is "Computer Science 110". For their two other subjects they study a variety of disciplines, the most common being Mathematics, Engineering, Physics, and various Management courses. For the Computer Science 110 course students have three lectures a week over 25 weeks, together with a two- hour practical class and a one-hour tutorial each week. The lectures are:

2. Choosing a Programming Language

Over the years there have been a number of different choices for the introductory programming language at Lancaster, although it has up to now always been a language in the imperative tradition. Early choices were Algol 60 and then Pascal, with another language introduced in the second year such as Pop2 or Algol68. A change was made to Ada in the academic year 1990-91, the other possibility at the time being Modula 2. In the second year of the course C was taught in the computer systems architecture stream, and either Prolog or Lisp in the information and knowledge processing stream.

There were a number of reasons for changing over to Java in 1996-97. There was felt to be a need to make the change from Ada to another language more in the C tradition, to allow an easier transition to the use of C in the second year and because we had always had difficulty "selling" Ada to the students as an appropriate language in which to learn programming. There was pressure to change to C++, probably in the academic year 1997-98.

However, with the interest from 1995 in Java, we decided (in the early summer of 1996) to change to this as the introductory programming language, and to make this change immediately rather than wait to follow other Computer Science departments. The main reasons for making the change are:

3. The Structure of the Course

The aim of the course is to develop the student's programming and problem-solving skills, and to introduce them to object-oriented programming and design. We wanted the students to start using object-oriented concepts right for the beginning of the course, so it was structured into five parts, each one approximately five weeks/lectures long:

The first part of the course introduced the basic ideas of programming in an object-oriented environment. Initially the students were given a Web browser, and encouraged to use it to explore the use of applets over the Web. This was followed by an introduction to object-oriented concepts and terminology, as far as possible using real-world examples. The first use of Java proper was for the student to manipulate a "Person" class which modelled simple facts about an individual, declaring instances of this class and calling methods to manipulate or extract the attributes of an instance. This was followed by the introduction of the basic selection (if, switch) and repetition (for, while) mechanisms in the language, using further manipulation of instances of the "Person" class as examples. Some of the Java primitive data types need to be introduced in an ad hoc way during this period, for example an "int" as a counting variable in a "for" loop, but they were then looked at in a more systematic way, contrasting features of the use of these primitive data types with the equivalent features of the use of objects.

In the second part of the course we started to discuss the internals of a class, by opening up the "Person" class which students had been using for several weeks. We introduced the basic ideas of instance fields, methods (including constructor methods), and class constants, also mentioning class (static) fields and methods. Up to this point all the instance fields had been either primitive data types or strings. At this point we introduced the idea of arrays, and then the possibility of an object containing an instance of another class (as an instance field, an argument or a return value), leading on to topics such as deep and shallow copying. The final section of this part was an example to illustrate how the various topics fitted together in defining and then using a class (a simple priority queue data structure, implemented with an array).

The third part discussed more advanced ideas of object- oriented programming, mainly the rather difficult and important idea of inheritance. This was followed by a brief discussion of abstract classes and interfaces; we had considered omitting the latter topic, but there are aspects of the Java class structure (such as for input and output) which require some understanding of this concept. The last section of this part of the course was an introduction to the Abstract Windowing Toolkit (AWT), which enables students to start to create their own graphical user interfaces with buttons, text and drawing areas, etc. This is a large subject (there are something like 40 to 50 classes in the AWT), so we gave only an introduction to some simple concepts and practical examples in this area. The AWT is also a practical examples of inheritance, from classes such as "Frame" and "Canvas".

The fourth part is a selection of topics covering more advanced use of objects in Java. We started with a discussion of how to create linked data structures, using as an example a re-implementation of the priority queue considered at the end of the second part. This was followed by a discussion of recursion; of input and output, going behind the local i/o classes they had been using up till that time; and an example of an applet with some simple HTML, linking back to the first examples they saw of Java programs. At the end we briefly considered the Vector and other data structures provided by Java, and the concept of threads. We do not attempt to get our students to a position where they are able to write multi-threaded programs at this point, but the concept is so central to Java that we felt that they should be aware that this topic exists (they will also have seen error messages from their programs which mention threads).

The final part is on object-oriented design. This is still being developed, but we plan to illustrate it with the development and then implementation of a reasonable-sized, realistic real-world example such as an electronic diary system.

4. Support for the Course

Because of the current financial constraints on university spending, we had to provide a hardware platform for the course which would be relatively cheap. The Ada practical course was run with a laboratory equipped with 18 or 19 PCs running MSDos and the Meridian Ada compiler. We utilised this basic hardware, but arranged for the PCs to boot up as Linux machines, connected directly to a Unix server machine in the Information Systems Services building. On this Unix server we run the Java Development Kit (JDK) version 1.0.2. This has a fairly rudimentary command-line interface, but it was all that was readily available at the beginning of the course. We will be investigating alternative development software for the next academic year. Many students nowadays have their own machines, and the department wished to encourage this use, so copies of the JDK and locally-written classes were made available on CDRom in the University library for students to borrow.

In order to get the students started we implemented a number of local classes:

We provided on-line documentation for both the standard classes and those specially written at Lancaster, by providing links to a local copy of the Sun API and to a local API created with the "javadoc" program from the above classes. Students access this documentation with the browser, to which they were introduced in the first week of the course.

In the first term the students followed a series of graded exercises closely tied to the topics being covered in the lectures and tutorials. In the second term the students have a series of more general problems to implement, rather less closely tied to the topics being covered in the lectures, but covering inheritance, the AWT, the implementation of data structures, and so on. We plan that a similar series of problems will be set for the summer term, culminating in a group project (with three or four students to a group) to create a rather larger program, probably an applet of some sort.

As supporting material we are writing an introductory programming text for Java ("Java: First Contact" by Roger Garside and John Mariani: International Thomson Computer Press, due to appear Summer 1997), and have been giving out sections of this to the students every five weeks as the basic reference text. There are a number of other books on Java to which we have referred students for an alternative view, but they all tend to assume some background in programming.

5. Java as an Introductory Programming Language

We have found the Java language to be a good one to use as a first programming language, although it has a number of flaws. For example, the lack of enumerated types goes against the design principles we want to instil in the students, and Java inherits from C the flaws of the "switch" statement and the lack of a clear distinction between situations which call for use of the "for" statement and those which call for the use of the "while" statement. In later parts of the course there is a problem with lack of "genericity" in Java, so that, for example, elements extracted from a Vector have to be cast back to the appropriate class.

The second year of the course is being revised for the academic year 1997-98, and the opportunity is being taken to use Java as a unifying element, including for example:

We expect other language paradigms (Prolog, and perhaps a functional language) to be introduced during the second year to complement this use of Java.

We believe that the introduction of object-oriented programming from the beginning has been a success; students have perhaps taken longer to grasp the concepts than the equivalent structuring principles in languages taught in earlier years, because the concepts run right through the language, but have ultimately done so. The use of objects has allowed us to improve the examples of some of the early concepts, such as looping structures. The transition from considering only objects to considering the primitive data types as well has perhaps raised some difficulties, and will be reconsidered for the next offering of the course. We also expect to expand the number of different examples of objects and the concepts they model.

At the beginning of the course there were a number of teething troubles which are to be expected with the introduction of a new system. There is certainly greater student enthusiasm for the language, and a number of students have obtained copies of the JDK for their own machines.

We had to work to a number of tight deadlines for the introduction of Java as a new programming language for first year students, but we now feel that this has generally been a good experience and one which we can built on in later years.

The Java phenomenon of the last 18 months has affected every part of the IT industry including education. It is clear that Java is an excellent OO programming language designed to incorporate the best features of many other OO languages and do away with the worst. Yet for all this some sections of industry and academia appear to be adopting Java in haste and the fact that Java is an OBJECT ORIENTED language and should be approached in a pure object oriented manner appears to have been overlooked.

It is my opinion that this attitude - unless corrected - could lead to serious problems. In common with several colleagues at several other UK universities I have been teaching OO as an independent subject for several years. I have taught OO at the Stoke site of Staffordshire University since 1992 using the Smalltalk environment which is significant for its 'pure object' approach which has also been adopted for Java. This experience has been valuable and has lead to a number of publications at conferences such as ECOOP and OOPSLA. In common with my UK and international colleagues I have come to see the teaching of an Object Oriented approach of paramount importance - considerably more significant than the implementation technology adopted, and yet Java as a programming language is just that - an implementation technology.

As recently as last year, Chandler and Hand (1996) reported on the current uptake of OO in UK universities reporting that only 27 out of 100 computing departments had responded to a survey asking about such issues. It is to be expected that many more are now contemplating adopting Java in some form or other. At the time this article was originally submitted I did not know of a UK institution that has adopted Java as its main programming language but I believed that this may well soon be happening and as it turns out more than one University has already made the switch and some have even been teaching it in academic year 1996/97.

What then of the rest of the computing curriculum ? It would be disastrous to teach structured methods of analysis and design at the same time as an object oriented programming language and yet this appears to be a realistic (from the point of view that it is actually happening ) option. This is an issue which must be addressed urgently. It is my belief that several UK institutions will be teaching Java as an introductory programming language form 1997 onwards, but what about the concepts and principles of object technology ?

I have long been an advocate of OO curricula such as Carlton in Canada where Smalltalk is taught as an OO approach in the first level and structured methods are then taught afterwards as a specialisation of certain aspects of the OO approach. I have been attempting to migrate the curriculum of my own institution towards OO as far as I could.

One of the fears I have is that a great deal of experience in teaching OO gained the hard way will be lost or ignored as there will suddenly be a large number of Java programmers teaching Java ' and after all as Java is an OOPL we must be teaching OOP'. Re-use (in this case of OO teaching strategies), will be neglected in favour of experience of the most fashionable language in the marketplace. There is currently a great deal of courseware appearing on web pages all over the world but it is very difficult to determine the effectiveness or the quality of the teaching materials and contradiction appears likely.

It is my opinion that if Java is to be used as an introductory programming language then object technology must be taught as a core theme in order to provide a theoretical underpinning. Failure to do so will lead to the worst of all worlds - teaching a procedural approach with an OO language . The best that could be hoped for is that students would be able to develop cute, dancing web appletts but at the same time lack full understanding of either the procedural or OO approach (not to mention good principles of software engineering). Opinion is considerably divided on this issue. Some maintain that OO should not be taught until students have some mastery of structured techniques and programming. I suspect that this concern is less significant than the need to teach a set of core OO skills if the students are expected to become competent with an OO language used in the core computer science and software engineering subjects.

If Java becomes the core language then OO must be taught as the central theme of the development curriculum covering all of the traditional areas addressed by software engineering education. It is clear that this could be done, however how many staff in computing departments are themselves fully conversant with the OO approach ? who will train them ? when will they have time to learn ? more importantly will they believe that the change is required or will they resist ? What about accreditation from bodies such as the BCS ? What about all of the non OO and hybrid systems and vendors ? How will existing sponsors of computing departments react ? What tools should be used and how much will they cost ? These are but some of the issues involved. They seem numerous but adopting Java - an OO programming language - as the core theme of UK undergraduate software development education will require momentous changes.

The worst scenario I can personally think of is the institution that adopts Java on the basis of its so far good press (and free availability) , ignoring potential clouds on the horizon, in the hope that students will be attracted to their institution because they are offering the latest technology (regardless of all the other institutions doing the same thing). It may happen that Java is thus adopted but that structured methods are still taught in analysis and design leading to considerable difficulties for the students. A simple example of the type of problem to be addressed come in teaching texts. Most of the current books describe Java 1.02. There are significant changes for Java 1.1 and yet if a University commits resources to book purchases early on, how will they be affected by future releases of the JDK ? One of the reasons for adopting an OO approach is to increase re-use - not having to make major revisions to texts and other materials every three months or so.

Rushing to adopt Java is in my opinion a poor move. Deciding to adopt a fully OO curriculum would be a much better move. This would not be easy (see for example McLaughlin et al 1995) but would at least allow for integration with and re-use of the considerable experience in teaching a 'pure objects' approach built up by those UK Universities who have so far amassed it. Such an initiative would be far more 'future proof' than the current curriculum allows but this is opinion again and is not universally accepted.

This an open ended debate. I see it as significantly more than the typical 'language war' debates that plague our profession from time to time. My personal solution is to adopt OO as the central theme permeating the computing curriculum as the best solution (thus making choice of language much less significant and allowing co-operation between communities of complementary languages) but this is far from universally accepted even by staff in institutions where OO is taught. Truly we live in interesting times.

References

Related Publications

Lovegrove, G.L. McLaughlin, P.N., Hazards of Migration in Large UK Computing Departments, in proceedings OOPSLA' 95 (Object Oriented Programming Systems, Languages and Applications) ACM SIGPLAN notices, Vol. 30,. No 10, 1995, ISBN-89791-703-0

McLaughlin, P.N. Lovegrove, G.L., OO environments and design methods for use in undergraduate curricula, in Proceedings ECOOP '95 (AITO/ACM SIGPLAN European Conference on Object-Oriented Programming), Arhus, Denmark, August 1995

Lovegrove, G.L., McLaughlin, P.N. Chabik, J. Standen, P.,OO methods in teaching: current experience and future possibilities, 1994, in proceedings of ICSQP '94 (IFIP/SQI, Hong Kong, December 1994)

McLaughlin, P.N., Lovegrove, G.L., Issues in teaching object technology to joint honours undergraduates, 1994, in proceedings of Software Engineering in Higher Education (Wessex Institute of Technology, Southampton, November 1994)

Everyone who has taught programming has agonised over difficult curriculum design questions. Most prominent is the question of first language choice, a matter still undecided by the great and the good in computer science education these past 40 odd years. Fewer words have been expended on questions of curriculum structure: is a programming language to be learnt separate from or together with program design; should specification be introduced before/after/with implementation; what is the appropriate balance between programming in the large and programming in the small; teach one large language or many small languages? The position we each adopt on these questions depends on a range of contextual issues; on the ability and expectations of our students and staff; on what we believe good programming is ; on how the skills, knowledge and motivation of programmers is best acquired.

The report on the Open University Workshop on language choice held in September 1993 (Woodman 1996) makes salutary reading in this regard. It is noticeable that the exclusive focus of the bulk of the essays is on the languages themselves as artefacts: their syntax, semantics and the programming styles they enable. There is seldom a mention of the learner; her needs, her conceptual development, her motivation. Nor is there much evidence of reflection on the end-point of what constitutes expert performance in the programming task, seen not only as the process of constructing logically sound symbolic systems but also artefacts which satisfy human and economic needs. The attempts at 'scientific' treatment of the language choice question often, as a result, appeared to be window-dressing on a more complex set of ill-grounded beliefs and shared cultural prejudice.

2. Whether Java?

Reviewing the straightforward technical comparison, it appears to me that, had the conference been held now, Java would have been the choice of over half the authors. Many were forced reluctantly to adopt C++, despite its lack of garbage collection, mixture of value, pointer and reference semantics and general trickiness. Java has removed most of C++'s disadvantages, and Java 1.1 will remove more, albeit at the expense of a more complex language. Java syntax is close enough to C to help when students need to use C - particularly for interfacing to legacy systems. Unfortunately some poor syntax has been carried over in to Java too but nothing that cannot be lived with.

Other authors, such as Woodman at the Open University, chose Smalltalk. I was particularly struck by one sentence: 'If developments in the financial sector are anything to go by, then Smalltalk could be tomorrow's language' Sadly not. I myself hold Smalltalk in great affection, and am teaching it now to 130 second year computing students, perhaps for the last time. They love the environment at the present but the lack of code management (in Smalltalk Express) will annoy them in the end. Packages are essential, not just for project sanity but, by providing a tangible distinction between the student's work and Parcplace/Digitalks, for pride of accomplishment. Java's advantages of integration of concurrency and error handling, distinction between type and class via Interfaces and its widespread use in distributed systems would outweigh for most teachers the appeal of the uniform object model of Smalltalk.

3. If Java, then how?

Given both the difficulty of rational language choice, and the rough analysis that Java would now be a popular choice, based on the criteria suggested by various authors at the OU workshop, we should shift our attention from the whether Java question to the if Java, then how question.

One paper at the OU workshop (Petre, 1996) does attempt to broaden the question from technical considerations by reflecting on observations of expert programmer behaviour. While the whole paper warrants reading, I shall only quote her concluding implications for the teaching of programming and the training of programmers.

Academic leaders face other problems too in changing languages, such as staff development, material development, and choice of teaching environments, but I believe it would be helpful to keep these pedagogic issues in mind as we wrestle with the problem of curriculum design.

4. The UWE modular Programme.

The Faculty of Computer Studies and Mathematics runs an undergraduate modular programme of awards which range across the spectrum of Business Decision Analysis, Information Systems, Computer Science and Computing for Real Time systems. HND and Honours Degree awards are part of the programme which has an intake of some 400 students each year. Students take the equivalent of six full modules each year, but for computing students, the curriculum is divided into term length half-modules. Currently none of the awards require A-Level or OND computing although about two-thirds of the current cohort do have prior computing studies.

This programme is being reviewed after having been in operation for four years. In the revised scheme we want to strengthen the mainstream computing awards by requiring some basic computing practice prior to entry. Ab initio students may also take the same module but require to take an additional bridging module. Information systems courses such as the long-established degree in Systems and Analysis and a new course in Business Information Systems are moving away from teaching programming altogether. Mathematics awards have the same problem over first language choice for their students. Currently this is Fortran but they would like to move to a language which supports symbolic manipulation and Maple is currently preferred.

For the computing awards, we are taking the opportunity to revisit the choice of first programming language, which for the past six years has been Modula-2. Teaching of introductory programming is currently split into a number of half-modules totalling 2 full modules. Language teaching in Modula-2 is one half-module, the teaching of program design, currently functional decomposition with pseudo-code, another. The two are coupled by a common problem set, and solutions are expected to be designed in pseudo-code before implementation in Modular-2. Second term half-modules expand on the language development and on program design. Most students will also take a half-module in Formal Specification, using Z.

This fine-grained design is being replaced by two full modules in the revised programme. One in 'programming in the small' is a combined language and design course aimed at developing single -language systems. It is for this module that Java is being considered as the replacement for Modula- 2. Some aspects of formal specification are required to be included, particularly pre-conditions, post-conditions and invariants.

The other module adopts a 'programming in the large' approach which tackles the design of systems running on multiple platforms with multiple languages, reusing or customising existing software resources. Here we expect to introduce the students to Perl and develop intranet applications. The two modules come together when Java applets are incorporated in the intranet applications. In this module we also teach notations for, first describing and then prescribing the structure of complex software and communications systems.

The other first year modules are computer systems architecture, analytic modelling, a module specific to the award and an elective module from some other Faculty such as Business, Art Media and design or Modern Languages.

In the second year, there are further core modules in software engineering, software design, data structures and databases and operating systems and networks in addition to further award-specific modules. In the final year there is a wide range of optional modules in computing specialities alongside a 2-module individual design project.

5. Java at UWE

It is always with some reservation that the thorny question of first language choice is raised. It is however noticeable that, once Java was proposed, staff were more interested in questions of what this would mean for teaching than on debate about that choice. There is of course some anxiety about a new language, particularly in the face of increased pressure on our time through 'efficiency cuts' and increasing quality demands.

Our approach has been to prototype the delivery of a first year Java course by changing from Smalltalk to Java on one version of a second-year half-module on object oriented development. Our HND stream is, this term, based on Java whilst the degree students remain with Smalltalk.. The groups are of unequal size - 60 HND students and 140 degree students. Although the two groups are not closely matched, and there is inevitably a element of Hawthorne effect with this new initiative, it will nevertheless be interesting to see how the two groups compare in the understanding of object-oriented concepts by the end of the modules. The four Java practical sessions are tutored by the lecturers who currently teach Modula-2 in the first year. We hope that this approach will provide some staff development as well as experience in the practical difficulties of Java teaching before we have to tackle the problem of 200 first-year students. We will also provide an in-house course during our staff development week at Easter.

Although the problems encountered in a second level course covering object-oriented concepts are clearly different from those likely to be encountered in a first level course on introductory programming, there are a number of issues in common, and if, as is our present intention, object- orientation is to be introduced in the latter part of the new first-level course, the efficacy of Java

as a vehicle for the teaching of basic OO concepts remains important.

Experience gained so far, and we are only three weeks into the course, would suggest that Java is a more accessible language

for a first level course than either Smalltalk or C++. However, a number of issues have been raised and are discussed briefly below :-

Taking these points in order, the first problem encountered was that of finding a text book which adequately addressed the OO concepts and the use of Java in application development. Many of the extensive array of Java texts that have leapt onto the bookshelves are poorly written, contain numerous typographical errors, spend an undue amount of time illustrating the development of Applets and concentrate on images, sound and animation at the expense of object- orientation.

The major drawback of Java for student home use is the need for Windows-95, but our feeling on this is that the problem will go away quickly as the average student machine configuration improves.

Compile time performance is important when using a networked system with large practical groups and we are currently conducting some comparison trials between Modula-2 and Java. On the positive side, the compile time diagnostics, whilst not guaranteeing to catch all class usage errors, does produce helpful diagnostics. The existence of language sensitive editors which allow compilation within the editor also serve to shorten the edit-compile-correct cycle.

One of the most obvious shortcomings first encountered with Java is its lack of provision of simple numeric input and formatted output when used in a simple VT100 mode. Correcting this is simply a matter of providing the necessary sub-classes or extensions to existing classes and it does seem strange that this has not been done.

On the other hand, the support for GUI's is good, given the constraints imposed by the need for platform independence and windows based application development, even without the help of a GUI builder is not beyond the capabilities of first level students.

One motivation for using Java as a first language is the teaching possibilities it opens up, not just for programming in the large, but for supporting the study of other paradigms such as concurrent programming, networking and distributed programming, data bases and of course the more traditional procedural approach adopted in structured programming.

The syntactic similarity between C, C++ and Java is at once an advantage and the cause for some concern. The benefit of this similarity lies in the ease of moving between these languages given the need our students have to program in C and C++ in more specialised modules at level 2 and 3, such as Image processing, graphics, embedded systems development etc. The unfortunate consequence is that a number of unsatisfactory features of C have been inherited - such as the switch statement, the use of break and continue and the absence of an enumerated type. On balance however, the elimination of the more dangerous features from C and C++ and the adoption of a fully dynamic model for objects eases the understanding of OO concepts.

One problem encountered early-on in the current course was dealing with the often unreasonably high expectations that students have, due to the amount of hype currently attached to Java, of being able to develop GUI's with animation and sound easily. Although it is undeniable that such programs can be hacked-out quickly, they are not as simple as might be expected for novices and if adopting a disciplined and professional object-oriented approach to software development, do not reasonably appear until quite late in a course.

One aim of the current Java course was to make use of graphics at the earliest opportunity. But to do this in any context other than a paint program development, requires the use of an MVC approach if misconceptions are to be avoided. Luckily, Java supports MVC quite well but this is clearly in the realms of the more advanced topics covered.

6. Program design paradigms

Although there has been some debate about the syntax of Java, there is much more concern about what the change means for the teaching of program design approaches. In the current programme, students start with top-down functional decomposition using pseudo-code. Depending on the specific award and student choice, students will encounter formal specification with Z, JSP, object-orientation, concurrent programming, functional and logic programming. Each paradigm has its own group of adherents within the faculty. Given these competing paradigms, there is potential for tension in the change to Java. The choice of Java does not of itself solve the more fundamental problem of the scheduling of the teaching of program design paradigms. Java has the capability of reducing the number of languages which students encounter but will not eliminate the need for other languages.

7. Comparative examples

I have always taught object orientation by starting from problems which are biased towards the paradigm, believing that this provided the best way to convert mind-sets. This year, driven more by the programme review than any change of heart, I started from an existing problem set chosen as suitable for a functional decomposition approach. Students had already encountered these in year 1. So that the Smalltalk students should not feel left out of the Java revolution, model answers were also provided in Smalltalk, together with the Modula-2 specimens.

8. Armstrong numbers

The first problem is used as a worked example in the present program design module. The problem is to decide which integers have the property of being equal to the sum of their digits raised to the power of the units, called Armstrong numbers.

Appendix A explains the problem and provides solutions in Modula-2, Java and Smalltalk.

Both the Java and Modula-2 programs adopt the same paradigm of procedural abstraction. Curiously neither of these solutions follows directly from the pseudo-code of the worked example, since this does not use procedural abstraction, presumably because it is thought to be too early in the course for this concept to be introduced. Indeed the suggested monolithic solution, by intertwining the computation of the Armstrong property and the counting of the numbers, makes procedural abstraction less likely.

The Smalltalk solution shows the power of a pure object language in which existing base classes can be extended and expressions executed directly. The implementation of integers of unlimited size is ideal for exploratory programming. It shows too the power of collection classes and closures in closing the gap between problem and solution. This kind of solution is not possible in Java because integers are not objects, and even if they were, compiled classes can only be extended by subclassing. I shall miss it.

But beyond these differences lies much commonalty. Any solution to this problem must draw on the basic concepts of sequence, iteration and selection, arithmetic operations such as +, * , mod and div, the idiom of iterative modification , the algorithm for reduction of a number to its digits and the generalisation of a three-digit number to an n-digit number. A good solution should also include procedural abstraction and, despite syntactic differences, all the languages enable this solution. We must ensure that students have the opportunity to develop clear understanding of these basic concepts, idioms and design strategies, whatever programming language is chosen. We must not lose sight of these more general mental tools in our enthusiasm to tackle exciting problem-centred programming, be it interactive applets or symbolic mathematics.

9. Snakes and Ladders

The problem set for the first year course concludes with a choice of this problem, in which a game of snakes and ladders is to be simulated, or the computation of a calendar for any month. Appendix B shows solutions to this problem in Modula-2, Java and Smalltalk. The solutions differ in the user interface provided and in the granularity of objects.

Here the advantages of Smalltalk over Java have diminished. Java in providing a package structure (not used in this example) provides a better means of separating user code from reused code. Indeed the Smalltalk solution is incomplete since the Random class used is not a base class but one I had written and then forgotten. Code management tools ease this problem but are an extra layer of complexity for Smalltalk.

Smalltalk collection classes provide a advantage in ease of use of Vector and Enumeration and string handling is easier, but the

real problem for a programmer lies in the structuring of the objects and their interrelationships. However much more time is spent, even by an experienced OO programmer on such issues as:

granularity

What are the objects? are squares, snakes and ladders, moves objects? In the Smalltalk solution I have squares as elements of an array, snakes and ladders as integers. Moves are objects in the Smalltalk solution but not in Java, merely because I was further down the track of putting a GUI on the Smalltalk model. These decisions will always be hard, even in a pure object language and we must not trivialise the difficulty by subscribing to the notion that finding objects is easy.

visibility

which objects know about which other objects? Here I have been driven to an unnatural position - that the game exists as an object which can 'see' everything, that a player can see the board but not the other players etc. Not much help from the problem structure here either.

allocation of behaviour

who throws the die? I have the game throwing the die and telling the player what the result was. I could objectify the die and pass it to the player to throw. No obvious choices here either.

All too easily we have passed in to a world of undecidable issues. We might appeal to the ease with which the objects can be reused, but this merely introduces the need to envisage an imaginary world of future games builders to decide on how to divide the overall behaviour into fragments which can be individually overwritten whilst still making sense of the whole.

10. Conclusions

Both the procedural and object oriented paradigms are essential parts of a modern education in computer programming. We must not think that, in finding that Java can provide satisfactory solutions to the implementation of both styles, we have thereby avoided the need, on the one hand, to pay proper attention to basic concepts, programming idioms and algorithms, and on the other to recognise the real difficulty of applying these styles to even apparently simple problems.

I would propose that the object oriented features of Java be kept in check until the basics of procedural abstraction have been laid. Objects cannot be avoided entirely and careful choice of problem set will needed.

11. References

A.1. The problem

An Armstrong number is calculated by taking a number, raising each digit to the power of the final digit and summing the result. If the result of this computation is equal to the original number, the original number is an Armstrong number. For example, given the number 153:

Write a design for a program to list all the Armstrong numbers in the range 1 to 200 inclusive. In addition, the program should report on the number of Armstrong numbers that have been detected.

A.2. Modula- 2

written by Bob Lang

1.MODULE Armstrong;
2.FROM InOut IMPORT
3.WriteString, WriteCard, WriteLn;
4.CONST
5.MinTestNumber = 1;
6.MaxTestNumber = 200;
7.
8.PROCEDURE CardPower (Val, Exp: CARDINAL) : CARDINAL;
9.VAR
10.Result, (* The final result *)
11.i (* Loop counter *)
12.CARDINAL;
13.BEGIN (* CardPower *)
14.Result := 1;
15.FOR i := 1 TO Exp DO
16.Result := Result * Val;
17.END (* For *);
18.RETURN Result;
19.END CardPower;

20.PROCEDURE IsArmstrong (Number: CARDINAL) :

23.LastDigit, (* Last digit of number being

42.VAR
43.TestNumber, (* The number being tested for

A.3. Java

Written by Chris Wallace

1. public class Armstrong {

2.

9. public static boolean isArmstrong(int

25.

30.

39 > java Armstrong 200

A.4. Smalltalk

Written by Chris Wallace.

2. armstrongTotal
3.

15. isArmstrong
16. ^ self armstrongTotal = self

Execute in the Transcript Window:

17. (1 to: 200 ) select: [ :i | i

18. ( 1 to: 200) select: [:i | i factorial

1. The features table

The features table from the workshop is given in Table 1 below. For those who were present: a cross has been coded as 0, a bracketed cross as 1, a bracketed tick as 2, a tick as 3 and a tick plus as 4.

The IDE feature has been removed from the table as the outcome indicated that a relatively low cost environment was available for every language.

In the notes which follow I have largely resisted the temptation to add any comments which were not made by attendees. Where I have succumbed my comments are indicated in curly braces {}

Static type checking refers to the ability of the environment to determine that the actual parameter supplied is incompatible with the data type of the formal parameter.

Purity refers to the strength of the object model within the environment. Java obtained a 2 as although a main() action cannot exist outside a class (object) definition, the class definition need only be a token wrapper.

Multiple inheritance refers to the ability to define a new class as an extension of more than one parent class, inheriting data attributes and actions from all. {On reflection Ada 95 and Java should have got at least 1 as there are techniques by which the beneficial aspects of multiple inheritance can be implemented without the detrimental aspects. In Java this is syntactically light weight, in Ada 95 it is heavy weight}.

Language standard refers to the availability of a written definition of the language's syntax and semantics. Only Ada '95 has an ANSI/ ISO standard, {so it should have got a 4}.

Lexical complexity was operationally defined as the ease with which a non-trivial program, for example more complex than hello world, can be implemented.

Generics refers to the ability to separate an algorithm from the data type which it will operate upon. For example a generic sort algorithm can be instantiated to sort a list of integers, or floats, or strings or any other data type.

Operator overloading refers to the ability of the developer to provide additional meanings of common operators and to use them in infix notation. For example a developer declared data type called foo may have an addition operator defined for it, allowing the developer to write foo3 := foo1 + foo2.

Assertions refers to the ability of the language to make logical statements about the semantics of an action and to enforce them. For example an action to compute a square root may have a pre-assertion that the number whose square root is to be computed must be greater than or equal to zero, and that the computed value times itself must be approximately equal to the value whose square root is required.

Exceptions refers to the ability of the language to interrupt the expected flow of control in response to some occurrence. This may be an implicit occurrence (for example dividing by zero) or an explicit occurrence (for example two input values being incompatible). The interruption in the flow of control is indicated by the throwing of an exception which will propagate up the call stack looking for a suitable exception handler. The advantage of this facility is to separate the code which handles exceptional conditions from that which implements the routine processing.

2. The criteria tables

The analysis of the criteria table is given below. Table 2 indicates the number of people who expressed an opinion on each of the weighting criteria, the average weighting given to the criteria and the standard deviation of the distribution. For clarity the marks have been scaled from a 0 (unimportant) to 10 (overriding importance) scale to a 0.0 to 1.0 scale.

The standard deviation is included to give an indication of the degree of consensus on the weighting factor. Thus safety has a small standard deviation indicating the greatest degree of agreement between the attendees, GUI has the largest indicating the largest degree of disagreement.

Table 3 indicates the number of people who expressed an opinion on each language and the un-weighted average opinion for each criterion.

Table 4 is the weighted opinions for each language which had more than one response.

{I was surprised at the degree of consistency between the overall weighted and un-weighted averages. If I had been asked to predict the outcome before the workshop I would have thought that the disagreement would have been greater.}

de facto: This criterion was the existence of a de- facto or de-jure standard for the language.

use: This criterion was the extent and/or significance of the use of the language in 'the real world'.

GUI: This criterion was the suitability of the language for the construction of Graphical user Interfaces.

curve: This criterion was the steepness of the learning curve for the language.

cost: This criterion was the student cost of suitable development environment.

base: This criterion was the suitability of the language for use after the first software development course. The inverse of this criterion would have been the extent to which it is a throw away language.

cred: This criterion was the street credibility of the language with the students.

safe: This criterion was the safety of the language, defined as the extent to which it isolates the student from the underlying machine hardware.

debug: This criterion was the availability and ease of use of debugging tools for the language.

stab: This criterion was the stability of the language specification.

extend: This criterion was the ease by which a class could be extended.

book: This criterion was the availability and suitability of text books.

gpp: This criterion was the extent to which the language supports pedagogy by encouraging good programming practice.

3. Other Questions and Comments

Attendees were also asked to name the languages which they currently use for their first software development course and to name the language which they would favour. The results are shown in Table 5.

Attendees were also invited to express any other comments. These are collected below.

(Verbal) The real issue is not which language, but which paradigm and what pedology.

I don't care whether it is a standard as a 1st language I want to get basic concepts across which are transferable. If the students want to learn a specific language then given the basic concepts- they can pick it up themselves. I am into education not training. (But C is going to be forced upon me as the students want to get jobs!)

My first year students are pushed to do some basic stuff, never mind the OO concepts.

If teaching/learning OO is the objective we wish then a pure OO language is essential if students are not to bring old procedural ideas and confuse themselves.

For a first language system two interrelated factors are significant. Size - i.e. of the language, for students to grasp without getting lost or bumping into the unexpected. Environment quality in terms of how the system responds to them. Full Ada would be a counter example - the compiler may diagnose errors that mean nothing to them, even after weeks of trying.

What really worries me is the butterfly effect of flitting to the next new language.

Heavy Ceilidh user so we would need to get a Ceilidh interface for any change.

I favour a very simple language because any language will limit your thinking and because our students will have to learn new languages during their course. I want the students exposed to more than 3 languages during their university education.