In this section the results of the project will be reviewed to see how far they fulfil the initial aims of the work.
The overall goals of the project were:
In considering the way in which programming is taught to students at the beginning of their computing degree, it was noted that most important is that the students learn the fundamental principles of program design and think clearly about the techniques and algorithms that they are using to solve problems. They should not be hindered unnecessarily by having to contend with complicated syntax in the language they are using.
At the same time, it was recognised that students often become frustrated by being made to learn what they regard as "toy" languages with no real commercial application. In view of this, in designing an approach for teaching programming, it must be taken into consideration how easy it is to progress from the teaching language to other, more sophisticated and commericially oriented languages. The majority of students studying computing at Imperial College consider Java to be the language that they should be being taught in order for them to be employable software engineers on completion of their education.
This examination, along with consideration of the system currently being used to teach programming to first year students at Imperial College, revealed that there were definitely some improvements which could be made in order to increase the ease with which a "commercial" language might be learnt whilst maintaining a focus on allowing the fundamental principles of programming to be taught. These are essential if the student is to develop into a good programmer who can work with a number of different languages to express these underlying techniques and ideas.
The strengths and weaknesses of available teaching languages were examined in detail and the qualities which would be desirable in a new language defined. The Kenya language was designed trying to incorporate as many of these features as possible, and leaving out anything that seemed unduly complex or confusing for the novice programmer. The other main consideration in designing the language was to maintain a similarity with Java where the Java syntax seemed sufficiently clear and simple. When the student moves on to programming in Java at a later stage, they should not have to learn a completely new set of keywords and syntax.
Tests were carried out to determine whether it is possible to write programs in Kenya to solve the sorts of problems given to students in an introductory programming class. Although it was not easy to test how useful Kenya is in teaching first year programmers (or fourth year programmers impersonating first year programmers) to solve such problems, example programs demonstrate that it is possible to solve the problems using the language.
As well as a language design, an approach for teaching with this language was developed. This approach is to provide an automatic translation of the Kenya program written by the student into a Java program which performs the same function. The goals for the Java code generated by the system were that it should:
For all the cases tested, the translation of a valid Kenya program produced valid Java code which compiled and performed the intended function of the Kenya program. However, "proof by example" is not a rigorous proof that all valid Kenya programs will be translated to valid Kenya programs by the software.
To verify that this is indeed the case would require specifying the operational semantics of both Kenya and Java, and showing that both programs result in the same changes of state. Unfortunately I currently have neither the skills, knowledge nor time to undertake such an exercise.
Clarity and cleanliness of code is a somewhat subjective thing. There are varying opinions on what is considered to be good code. A very experienced programmer may prefer code that is concise, and therefore quicker for them to read and appreciate. Other programmers may prefer code which provides a more verbose description of what is going on.
All the Java code that is generated by the Kenya system is self contained (i.e. requires no extra
classes to be imported) apart from the code generated from input functions like readInt().
Novice programmers cannot be expected to work effectively with command line tools. Their learning experience will be greatly enhanced if they are provided with a development environment which helps them to write programs effectively. A development environment for Kenya was designed and implemented as part of this project. The main goals for the design of the environment were:
In terms of the basic key components of a development environment, the Kenya environment provides an editing area for writing code, and a facility to compile code (after Kenya code has been translated to Java) and execute it all inside the same environment.
The code editor currently lacks features such as syntax highlighting (automatically colouring keywords to distinguish them from variable and type names etc) and auto indenting. These would be nice features to have if the editor was going to be used for serious programming as they make it much easier to see the form and structure of the code which is being worked on. The environment developed in this project was intended to demonstrate that development with the Kenya language is possible. The fact that these features are missing at this stage is not a major failing, but they should be added if further work is done on the project.
Other features which might be seen as being missing are the ability to load and save Java code (rather than Kenya code) or to change the package name after it has been set. There will inevitably be extra features that people will want added to a development environment, and these could be worked on further in future.
The type checker works quite well, and will detect whether the type of the expression on the right hand side of an assignment matches the type of the variable to which the assignment is being made. It also reports the use of types which have not been defined, and the repeated use of type or variable names.
Currently any compiler messages generated by the GJ compiler are passed straight back to the user without being processed. If it were possible to add line number tags, then it would be much better if the line number reported in a compiler error could be matched to the line of Java which caused it, and then that line be mapped back to the line of Kenya which generated it. This would associate any compiler errors directly with the Kenya. This would be better than the current situation, as Kenya users should not have to concern themselves with the Java stage unless they wish to.
Overall this project has yielded some insights into various aspects of teaching and learning programming. A language and an initial version of a development environment have been designed and implemented. Some areas have been identified on which further work would need to be done before the language could be used in a laboratory environment. These are detailed in the next section.