Title: Francis' Scribbles

Two things turned my thoughts to the problems of teaching programming. The first was a letter in the recent issue of C Vu in which the writer thought he had detected a radical change in editorial direction. The second was sitting talking with my editor about why Java would not work for the book I was writing.

It is very easy to confuse teaching programming with teaching a programming language. To some extent you cannot do one without the other, though it is possible to invent a programming language purely for the purpose of teaching programming. The outstanding example of that route is Donald Knuth's MIX language that he uses in The Art of Computer Programming. Indeed if you are going to focus on fundamental computing issues that is, in my opinion, about the only viable choice.

In general Computer Science/Engineering Departments want to focus on teaching programming and the language used for practical work is just that, the language used by students to provide practical experience of what they have learnt in theory. I think the objective of teaching good basic programming is very laudable, and is not, in intent, different to the way science and engineering disciplines are generally taught at that level. However, practical work is important and so students need to learn a computing language in which they can experiment.

The thing that concerns me is both the choice of language and the accuracy with which it is taught.

Suppose you were designing a course on human communication, what language would you choose for the practical side? For the sake of argument, suppose that you decided that it would benefit students to learn a new natural language so that they did not import their bad habits from the language they currently use.

Should those teaching this language be reasonably fluent in the language? Should they understand correct idiomatic usage?

Should they have a basic grasp of the syntax and semantics? Remember that their objective is not teaching the language but teaching communication skills. Nonetheless, I suspect most students would be disappointed to have invested a great deal of time learning a new language badly or inappropriately.

I am reminded of a friend of my parents who read a degree in Oriental Languages at Oxford. He then joined the British Diplomatic Corps and because of his degree was posted to Khartoum. He used to relate the story of his arrival at the rail station where he leapt out of the train bubbling with youthful enthusiasm and instructed the local railway porters in fluent classical Arabic. They just stood open mouthed and deeply puzzled by this weird Englishman who seemed to be spouting some curious language that vaguely related to their normal speech. There was very little communication, until he reverted to English (though later he became fluent in spoken Arabic, and was awarded the title of Sheik by the local population out of respect for his profound knowledge of the Koran and his ability to settle disputes).

Returning to the subject of teaching programming; whatever language is used for the practical side must not, in my opinion, control what is taught on the theoretical side. It needs to be a good general-purpose language and not one tied to a specific paradigm. If the course is substantially about computing then it will almost certainly be necessary to use more than one language because I do not know of any single language that enables the student to gain practical experience of such distinct paradigms as object orientation and functional programming.

My contention is that the specialist student should finish with a sound understanding of programming coupled with a practical knowledge of at least one programming language. They need to understand the broad range of programming techniques and how those are implemented in one or more languages.

They should also, in my opinion, understand that programming requires responsibility. Such simple misconceptions as using a compiler to attempt to determine what a piece of code should do should have been long eradicated from their thinking. They should not be the computing equivalent of the Oxford graduate chemist who, needing to know the boiling point of nitro-glycerine set up a standard experiment to determine it (he had never thought of looking up such information in a book; that would have been cheating!)

The computing specialist probably should learn most, if not all, about the languages they are using but that does not apply to the student for whom programming is either an adjunct to their main subject or for whom it is provided as a form of educational enrichment.

Such students should not be required to delve into fundamental theory nor should they be expected to master an entire language. Their course should be designed to meet their needs. To some extent academics from a Computer Science Department can be very bad news to such students because such people often find it hard to restrain themselves from teaching everything. If I want to mend a fuse, I do not need to know about the physics of blowing a fuse. I need to know a number of practical things such as checking what caused the fuse to blow in the first place (yes, it was a current surge but that is too low level to be practically useful). Basic programming is not that difficult, and definitely much easier than many programmers would have you believe. Using C++ to write simple programs is not that hard if you do not require that the student learn everything about the language.

I do not think Java is a good tool for this level of programming because the student has too many ways in which things can come unstuck, and too restricted a way in which code must be written. From the instructor's position, Java demands too much knowledge. Granted that those statements are my personal opinion but they are based on my experiences in writing my book and those of my test students. Object-orientation is a great way to write some types of program but it is far from a great way to learn to program. At the cutting code level most people think procedurally and the knowledge required to implement ideas as objects is unhelpful.

Quite a few of the current crop of books on C++ are based on articles that have either been published in magazines or on the Internet. When I look at books like C++ Ruminations by Andy Koenig & Barbara Moo I see work that has clearly been rewritten for the different medium. This is not always the case and in my opinion it matters.

When I write for a periodical I can afford to express my strongly held opinions without distinguishing them from facts because the readers, other columnists and even my own future writing can make it clear that there are alternative viewpoints. It is a mistake to water down one's opinions and ideas when writing for a periodical.

This also applies to books that are clearly about personal opinion, the reader is forewarned that my excellent ideas are just mine and others may have even better ones or just plain different ones.

When writing a technical book where the reader is led to believe that the author is writing factual material, the rules change. Taking a series of articles most of which are factual but some of which are opinion and wrapping them up in a book removes the context that validates such mixtures.

Over the last decade Stephen Dewhurst has written over 120 columns under the title C++ Gotchas. The readers of those columns had immediate access to alternative views from other columnists in the same publications (initially C++ Report, then CUJ) so they would have been immediately aware of the places where Stephen was in strong disagreement with others such as Dan Saks, Herb Sutter and Andy Koenig.

A couple of months ago I received a signed copy of his book, C++ Gotchas. I read it, and decided to leave the review process to someone else. The book is waiting for a review. But if you see a copy on the shelves of your local book supplier take it off the shelf and give serious consideration to buying it. I think the author has done himself a serious disservice by including several articles that are pure opinion and have little to do with what I consider a Gotcha. That only matters in so far as that those items are largely near the start and may lead the prospective purchaser into misjudging the book as a whole.

What is more serious is that some of the other articles include material that is also a matter of opinion, but in contexts that make that far from obvious.

My conclusion is that this is an example of writing that needed much closer consideration before being transferred from periodical to book.

As I have got further into the process of writing my own book I have become increasingly sensitive to the different objectives that a book must meet. Typos and small technical errors in magazine articles are warts that we could do without, those same mistakes moved to a book can be deeply damaging because few people buy a book and immediately download errata from the Web. Indeed they would expect that a well-written book would not contain errors.

Authors will defend themselves on the basis that books are always their personal opinions. I do not think that is true. Technical books should clearly distinguish between technical answers and issues of idiom, personal style and presentation. Expressing an opinion as fact is likely to detract from the authority with which the author's factual statements are taken.

Clubs, societies and the like come in many forms. The two extremes are clubs that are run entirely by members and for the benefit of members, and commercial clubs run for the financial benefits of the organisers.

ACCU is very close to the first extreme. Because certain work places a vast load on an individual we have recently moved to accepting the contracting of some work to members for their financial gain. However volunteers do the overwhelming majority of the work.

If you and a group of colleagues went down to the local place of refreshment you would soon notice the person who never contributed but always consumed. ACCU is different because many members never see the work that is quietly done by many individuals but it is still a community in which all should seek to contribute as well as consume.

Writers of articles need readers, but they also need appreciation or else they will stop writing. I know that many of you do appreciate all that is done because over the years you have told me and thanked me. But the people you should really be telling are all those who make a little contribution of time or skill.

Time is the most precious thing we have because it flows inexorably from the moment of our birth to the moment of our death. We can never go back, time once spent is gone. We should appreciate when others give us a gift of their time. We should also have the courage to speak out when someone is spending time on some well-intentioned pursuit that we think is unproductive.

Please take a few moments of your time to write down three good things about ACCU and three things that you think could be done better or differently. Now ask yourself how the ACCU Committee can know about those notes if you do not tell them.

When you pay your subscription to ACCU it is more like buying a ticket to a dance than to the theatre. The latter is just your entry to be allowed to watch but the former is your payment to be allowed to contribute. A dance in which no one danced would be pretty meaningless, and a play where the audience all wanted to be on stage would please no one.

Know the difference and act accordingly.