How and Why We Teach What We Teach

The information below outlines some specific questions that we have been asked in the past.

How much of the course is theoretical?

Our courses are theoretical - but also cover practice. They include hardware - but proceed into the theory of the abstract representation of data and algorithms. Hardware has its theory. Software has its engineering context.
Our graduates have few worries about employability, due to the nature of our courses. As we teach theory as well as practice, you will be able to easily pick up any programming language or concept in the workplace.
If, in ten years' time, you want to be making decisions rather than being told what to do, make sure that you understand the theoretical basis of what you are doing. Theory makes for flexibility. Theory makes for an interesting and rewarding future. Theory is fun.

How are science/engineering, theory/practice and hardware/software related?

Most universities offer a variety of courses, called Computer Science/Engineering, Computer Systems/Software Engineering, Theoretical/Mathematical Computer Science, and so on. In some of these, 'engineering' implies a greater hardware component, in others it implies an engineering approach to software systems, and in others it implies both of these. But, generally, the science/engineering, hardware/software and theory/practice axes are at right angles to one another.
Here at York, our Computer Systems and Software Engineering, Computer Science with Embedded Systems, and Computer Science programmes lie near to one another, at particular points in this space.
Our Computer Science and Mathematics and Computer Science and Philosophy programmes are more towards the theoretical, software and scientific end, while still covering practical matters and looking at computer systems and their software in the context of the real world that needs things to work and work well.

Why is there a fixed programme (no options) in the first year?

We believe that you need enough breadth in the first year that you can choose freely what modules to follow in the second and later years. That is, not any breadth, but a range of courses designed to provide you with the essential pre-requisites for later studies.
In the second year, there is some optionality in some of our courses, but there is a great range of options in the third and fourth years. We try to ensure that you do not close off your options in later years by missing their pre-requisites in earlier years, at least up to the point where you are specialising in a well-informed way. We do not want you to say 'If only I had known ...'
The ultimate freedom comes in your third and fourth years, where you can choose your individual project topics. Also, you can undertake modules taught by other departments. By that stage of the programme, you should be following your own interests intensively in your projects and also, if you wish, by exploring ideas in other subjects.
As an overall guiding principle, we think that optionality should increase over the duration of the three- or four-year programme.

Why does the first year include hardware?

Why hardware? All Computer Science courses contain hardware to some extent. Partly, it is a matter of familiarisation: providing you with a piece of the cultural background of Computer Science. Even if you see yourself as a software person, you don't want to find yourself simply not understanding what is the topic of discussion during a design meeting.
You will find that Computer Systems and Software Engineering, Computer Science with Artificial Intelligence and Computer Science with Embedded Systems have a hardware strand (one quarter of your time) in the first year, and also a hardware/software 'hardware systems' course in the second year. Beyond that, it is up to you whether or not to choose hardware options and projects.
Our Computer Science course is similar to these programmes, except that the second-year hardware systems course is optional.
The hardware strand begins with un-assessed familiarisation. Most students find that they enjoy the practical work, even (or especially) those to whom it is largely new.

What programming languages would I learn, and why?

We aim to educate our students to be able to choose, learn, understand and exploit a new language in a matter of days. That calls for flexibility of mind, and deep knowledge of the concepts of programming and software engineering, rather than a list of languages that you 'know'.

We make available to you the information and facilities to learn about whatever programming languages you wish.
Computer Science is about more than programming. Many of our modules have nothing to do with programming. Nevertheless, it is certain that programming is an important part of Computer Science, and indeed is its distinctive activity.
Bear in mind that there are not just many programming languages, each with its own name, but that these languages fall into groups of various kinds: procedural, logical, functional, object-oriented (OO).

Of course, it is possible to use a procedural language (Ada, for example) functionally, and Ada has had object-oriented features incorporated in it, in its current version; but it remains true that the design of each language will have been thought out from a procedural, logical, functional or object-oriented starting point. And every programming language must have been designed by someone: perhaps an individual enthusiast, or perhaps a committee. It tends to show.

For some of our modules, it is necessary to use a programming language as a means of expression for the subject-matter of the module. For example, Real-time systems and languages involves the expression of real-time concepts in a particular programming language, and also the study of several languages (Ada, Java, ...) to compare their suitability and efficiency for that purpose.
When a programming language is necessary, you will be given enough information to get started, and then shown where information and tools are available.
In the first year of the programme - for example in the Principles of Programming module - you will get a lot of explicit help concerning the language being used. Later on, especially in the third and fourth years, you will be expected to learn in a much more independent way.
Examples of languages that are mentioned, either as a significant part of a module or just in passing, are: Scheme, Ada, Java, Z80 machine code, C++, Prolog.
The study of programming languages, their design and especially their implementation, is an important part of our programme. Choice of a type of language, and of a method of implementation, is an important engineering skill, with many intellectually challenging aspects. But please note that that is different from the serial teaching of specific languages as collectable items.

What do you regard as the 'core' topics of Computer Science, and when do you teach them?

The core topics are principally algorithms (ways of processing data), programming (ways of expressing algorithms) and architectures (ways of executing programs).
What about applications? Well, yes, in any Computer Science course you must study applications, because, without applications, Computer Science would be an interesting sideline of engineering but not at the forefront of social and economic life.

Applications are what computers are for. But different courses at different universities can properly stress different fields of application. Also, applications come in a wide variety, and fit most neatly as options later in the course. That is, it is not optional to study applications (they are core in that sense), but it is optional which applications you study.

But would it be possible, conversely, to regard applications, whichever they are, as the core topics, and to look only briefly at how they work? Yes, to some extent, and for some applications more than others: but then that would be IT rather than Computer Science (see Computer Science (CS) versus Information Technology (IT)).

Should core topics come in the first year? Should the first year consist solely of core topics?

Some core topics depend upon other core topics, and so, to that extent, they cannot all be taught in parallel.

Similarly, there are some core topics that need certain other topics to be taught and studied before they can begin, but then those preparatory ideas need not be taught or examined explicitly once that has been done. Such preparatory topics must occur at the beginning of the whole programme, in parallel with some core topics but before others.

That means that some of the first year must be preparatory, rather than core, material; and some core topics must run into the second year. Roughly speaking, core topics occupy half your time for the first half of your entire programme: that is, of the first and second year of your four (or perhaps three) years.

What are examples of preparatory topics?

Some of the first-year Computer Science mathematics is preparatory, and some of the first-year Computer Science electronics is preparatory.

The rest of these is core, since they flesh out the study of theoretical computer science, and of computer architectures, respectively.

When you say that the principal core topics are algorithms, programming and architectures, what other core topics are there? And when you say that these are 'fleshed out' how is that done?

To a large extent, the answer to these questions is provided directly by a comparison of our second-year with our first-year.

Algorithms must, first, be correct. So we study ways of constructing them to be correct, or proving them to be correct. Then, they ought to be efficient. Further, we might want to concentrate on the structure of the data involved; or perhaps, instead, concentrate on the methods of manipulation.

Programming does involve the study of languages for programming; but, to a much more important extent, it involves programming as a general activity. Also, some languages are tailored for special structures of data, or special methods of manipulation. Some place efficency in time, or in space, above all else (except correctness); while others, as their main goal, enable great flexibility of expression.

Architectures are designed to execute algorithms expressed in the form of programs. But of course they are constrained by having to be physically constructable. An algorithm might be re-classified from 'interesting but impractical' to 'a challenge but possible', through the invention of new hardware: perhaps actually prompted by that specific requirement.

One way in which the early principal topics are fleshed out is through the study of some 'tools', which increase the power of the basic ideas to the point where they can be used immediately and effectively to tackle applications. These tools include compilers, which allow high-level programming languages to be used; operating systems, which allow programs to exploit the architecture of the machine they are running on, fully, but without the programmer having to worry about the details; and so on. The second year of our core programme has a lot about tools.

A glance at the four strands of our second-year will show four activities each requiring a very different approach to programming, and a different style of programming language to do it in. Which of these are regarded as 'core' can be judged to some extent by seeing which are not optional for students of the combined-subject programmes.

Nevertheless, all theory/practice, software/hardware, science/engineering and technology/application problems are related. Knowing more about one helps you to learn about the others.

Department of Computer Science