Home
--- Introduction
--- Content Summary
--- Acknowledgements

Context
--- Teaching Philosophy
--- Institutional Context

Course Structure
--- Aims, Objectives, Content
--- Delivery Methods
--- Assessment

Reflection
--- Commenting on Content
--- Use of Voting Handsets
--- Laboratory Examination
--- Written Examination
--- Continuous Assessment
--- Overcoming Blocks

Outcomes
--- New course rationale
--- Personal learning

Summary of rationale

We hope to provide a course for all-comers, whether they have taken school courses, programmed in their own time, or are complete beginners. We even hope those few who have come in from programming jobs may learn something. One course fits all. We hope that we provide an education/training in computer programming that is transferable to another language quite easily. Principally, we aspire to embed foundational concepts deeply. Keep it simple, stu…

Lots of hope and aspiration in there.

Programming methodology

We are strictly imperative, using stepwise refinement as the principle problem decomposition technique. As I write, this seems dreadfully old-fashioned.

I have dallied with getting them to see patterns. But I do find this hard when they have done so little programming - not enough really to see the repeats. Still, I believe they should develop their own pattern library explicitly - any of us knows that we have one of these in our heads, no matter how we actually got it there.

The methodology is conveyed using numerous examples in lectures, and then by encouraging them to copy the style when working on their programming assignments. But they do seem to find planning extraordinarily difficult, always wanting to jump straight to code. I guess I can see why - the code level is concrete, bounded in some way. I get the impression that they must think that plans are somehow plucked from thin air - that the particular level of abstraction used to write the plan is hard to define exactly. Of course, jumping straight to code doesn't work either - but they do find the logical thinking necessary for successful planning/stepwise refining hard.

Language

Ha. We use Ada. Not very many of us left, and in fact, this is the last year that we will use it too.

Why did we choose Ada? It happened just before the Java bandwagon emerged. We were modularising, and we believed the 1st/2nd years needed to learn a language that could be assumed by any lecturer in the two later Honours years (4 in Scotland remember). A rather mono-language culture in fact. Ada fits the bill, because it can be all things to all men (well, it can't be terribly functional, but then Glasgow was heavily involved in the Haskell work, so we had our own language there - or at least that was the viewpoint I picked up).

This choice was made literally just before I arrived at the department. I had the view that one could teach programming through any language - although I was rather shocked that Ada was being chosen, having always thought it a committee-designed baroque monstrosity (having come from a school of elegant language design). I've tenaciously held this view ("can teach with any language") for a long time - but no longer hold it! The seeds of my own programming upbringing are showing through!

Almost immediately (10 years back), we realised that we needed to teach Java somewhere - and so this was introduced at the start of the Honours class (3rd year). And in fact this has worked remarkably well, from the employers' point of view. Our students learn two paradigms and two syntaxes thoroughly, and later learn C pretty much on their own - and the employers say they really can tell this from our students' ability to pick up new languages/systems very quickly. A crucial skill.

Concepts in

• Use of procedures/functions from libraries/packages
• Control structures: sequence, repetition (while, for loops), selection ( if then, if then else, case, if elsif etc)
• Simple types and expressions: integer, floating point, character, Boolean
• Complex types: arrays, strings (arrays of characters in Ada), records
• Developing procedure and functions, various parameter passing modes
• File I/O
• Exceptions
• Programming with modules/packages - bare introduction
• Simple sorting and searching algorithms, graphical animation algorithms, data processing algorithms

Concepts out

Early/late divide

• Sequences of procedure calls - calls into packages that do something interesting like flying a rocket around the screen. Initially parameterless procedures, then with parameters.
• Repetition and Selection, again with just sequences of procedure calls in the loop bodies/conditional arms. Boolean functions first without then with parameters are used to provide the necessary conditions in these control structures. This enables interesting programs - typically auto-landing the rocket, or directing a person through an arbitrarily-laid-out room.
• Variables and expressions, using the Integer type only
• Arrays
• Characters and then Strings
• Everything up to this point is conveyed using a graphical programming context - either pre-written graphical packages, or using a line-drawing package. At this point, we introduce textual I/O, a bit of a shock.
• Developing own procedures; a particular programming structure/parameter passing method
• Records
  

Vehicles for teaching/learning

I firmly believed (less sure whether I now do believe) that using the traditional textual I/O programming context was far from exciting for students.

So, both in order to make programming look a bit more exciting, and in order to introduce programming as simply as possible - as a sequence of commands - I use pre-written graphical environments. The principal pair involve a module/package that enable simple rocket-flying programs to be written, and another that does typical room-walking behaviour - a person in a room set up as a grid, with some grid squares being clear, some containing an obstacle.

From this we move onto a line drawing package enabling the students to write programs that produce both static and 'moving' images. Again, this is believed to be more stimulating and immediately rewarding - but I suppose I don't know if it is.

Finally, the students are subjected to textual I/O. To me this seems much less exciting - but it does provide endless ground for increasingly complex algorithms in order to process the data being input. We seem to have endless versions of "A file contains data in this format. Read it in and do X to it….".

Text books

We have never been happy with Ada text books. Well, we liked the first one, but the students hated it - so we tried a succession of others. The problem was that they didn't fit our style of teaching - in fact many were American and excessively wordy, many had a very poor index, or just that they used Ada in a different way - very easily done with such a large, option-full, language. Initially, we made a text book a required purchase, but we no longer do.

Since so much of programming is about experimentation, trying numerous exercises, trial and error - particularly getting it wrong a lot - I think our lax attitude towards a book is a serious problem.

Influences on our approach

Tradition!

Seeing other disciplines take out quantities of gumph at the early levels that were believed to be important, but which were in fact unnecessary until much later.

Learning about the hurdles to learning - and that if they are too large, students will founder. This lies behind the attempt to introduce the concepts one at a time - not so easy - but at least produce a long series of gentle steps.

Conviction that text based programs early are boring. Is this true?

Why would I change?

Well, in fact we are changing:

Language: to Python. Why? Because Ada, an industrial language, really is too complex for beginners. There are so many ways in which the students get tripped up. I'm now willing to stand beside my original prejudice that no industrial strength language should be taught to a beginner programmer. By industrial strength, I mean one that requires excessive attention to a mostly static type system, and all the irritating syntactic overload that this produces - the signal to noise ratio is alarming for very simple programs.

Also, of course, because Ada is completely un-sexy, and we need students.

We have never taught a so-called scripting language before. This language will be a useful arrow in the students' quiver, to be used often throughout the degree and after - alongside the general purpose Java and the systems C. This is counter to Ada, which they barely ever use again after the end of 2nd year.

My intention/expectation is that otherwise the course content will not change radically. I'm thinking that we will be adopting an objects-near approach - which to my way of thinking is that students may create objects from existing classes and call methods on those objects, but do not create any classes of their own. They will still then just be writing essentially imperative programs, and learning the fundamentals of expressions (functional stuff) and control structures (imperative stuff), just as they ever did. The full dive into O-O will come in 2nd year, when they will start Java.