Those of you that attended my talk will recognise this machine as the Manchester Small Scale Experimental Machine (The Baby). This system executed it's first program on June 21st, 1948. The program was designed to find the highest common factor of a number. Initially the program was run on small numbers, but within a few days, they were at the stage where they could try 218. On this value, the program took 52 minutes to execute, involving 2.5 million instructions and 3.5 million store accesses.
The point of this? Well when you consider the hardware that they had to work with, the program to find the HCF had to be very well optimised to allow it to execute at a reasonable speed. Such constraints on hardware do not exist these days (with entry-level currently a 200MHz Pentium), and as such there has been a general deterioration in the standard of code produced. It is no longer necessary to produce good code since the 'fast' hardware won't show this up (well that is the general attitude, leading to a requirement for ever faster systems).
The recent ADS coursework is a case in point, many people wrote reasonable code, however, as pointed out on the web site, some code was sloppy and contained huge memory leaks - a symptom of a cavalier attitude towards the hardware.
In my opinion, it is essential that good programming, such as neat code is strongly emphasised. It is of course important that the optimisation doesn't go too far, since this can result in bizarre optimisations that might make perfect sense to the developer at the time, but probably won't make sense to another programmer trying to maintain the code years later. So it is not only neat code, but all aspects of 'good programming' that need to be emphasised. One point that struck me concerning our course is the Ceilidh system, which is a generally very good system. However, the nature of the dynamic correctness checks where Ceilidh might only accept the output in a particular order (sometimes not actually specified in the task definition) sometimes lead to students 'fudging' their code. Such 'fudges' would generally be ad hoc modifications of code which can be hard to debug later on. Ad hoc code modifications have posed a severe problem for the industry already (i.e. the millennium problem), and should be strongly discouraged.
In addition to good programming style, Computer Science courses should emphasis section 18 of the British Computer Society's code of conduct, which is:
|"Members shall seek to upgrade their professional knowledge and skill and shall maintain awareness of technological developments, procedures and standards which are relevant to their field, and shall encourage their subordinates to do likewise."|
I think this a very good guideline, and could potentially solve a lot of problems. Of the two major issues affecting the industry - the millennium problem and the European single currency, the latter is probably due in part to this rule not being followed. The European single currency has been known about since 1993 when it was defined in the Maastricht treaty, yet many companies are only just waking up to this...
We all know the problems of the millennium bug, and there are a couple of useful links you can follow. I shall cover the European single currency issue under mistakes, since this really hasn't received that much coverage, and it's about time it did.
|This page was created by Anthony Jaroslav Truhlar.
Last modified on Wednesday, December 2nd at 06:54 GMT.