Title: Francis' Scribbles

Author:

Date: 06 April 2003 13:15:56 +01:00 or Sun, 06 April 2003 13:15:56 +01:00

Summary:

Body:

Teaching Programming

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.

On Writing for Publication

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.

The Concept of Membership

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.

Problems

Problem 7 restated

Look at the following code that is designed to draw an approximate circle by drawing a polygon with a sufficiently large number of sides.

The function that draws a side is based on the same design principles as yline(). The supplied software uses the closest pixel to each vertex as the start/end point of a side.

The programmer has determined that a 100-sided polygon is indistinguishable from a circle when drawn at a resolution of 800 by 600. However he is very surprised when he draws a set of nested circles to create a filled in disc because the result is a doughnut shape with a central disk in background colour. Why? And how should he change the circle drawing function?

void drawcircle(double radius, 
                point2d centre) {
  drawpolygon(radius, 100, centre);
}

Commentary

This is another little problem that arose out the book I am writing. Writing a fill function for an arbitrary closed curve is a difficult programming task. The one algorithm I know that is theoretically guaranteed to work for all closed curves has a severe practical problem, it is deeply recursive and blows up most stack based machines.

Nesting ever-smaller versions of a polygon has a number of problems. One is that some polygons simply do not nest however much you try. But regular polygons do not suffer from that problem.

The problem with the above code is that when the circumference of the circle reduces to less than 100 units our line-drawing algorithm decides that there is nothing to draw because each side of the polygon is less than 1 unit in length. The error in the above code is in the concept that a 100-sided polygon is a good representation of a circle regardless of the radius of the circle. If we define a 'circle' something like this:

void drawcircle(double radius, 
                point2d centre) {
  drawpolygon(radius, 2*radius, centre);
}

We have a better chance of achieving what we want. Small circles are represented by polygons with few sides, large circles need far more sides for a good approximation.

Question

Does anyone know a good fill algorithm? Good in this context means one that a relative novice could understand even if the code lacks the efficiency you would want for your high-speed game.

Problem 8

Many of you know that C++ strings can contain embedded nulls. However how do you get them there? And what about C arrays of char?

Look at the following code and decide what happens in each case.

int main() {
  char const * mess = "One\0Two\0Three";
  cout << mess << '\n';
  cout << mess+4 << '\n';
  cout << mess+8 << '\n';
}

And now repeat the exercise for:

int main() {
  char mess[] = "One\0Two\0Three";
  cout << mess << '\n';
  cout << mess+4 << '\n';
  cout << mess+8 << '\n';
}

And for:

int main() {
  std::string mess("One\0Two\0Three");
  cout << mess << '\n';
  cout << mess[4] << '\n';
  cout << mess[8] << '\n';
}

And now correct that last program so that mess is initialised by the whole of the literal not just part of it.

For bonus credits decide whether the c_str() member of string behaves more like a pointer to literal or an array initialised with a literal.

Cryptic Clues for Prizes

In my days as a teacher I used to encourage my pupils to have fun with numbers. I found the kind of cross-number problem that got inserted into textbooks boring in the extreme. There was no great pleasure in solving them. Solving a clue should give you some kind of emotional kick.

Cryptic crossword clues can be great fun. Seeing into the mind of the setter can be a pleasure. Distorting your view of a clue till you see it clearly is both a challenge and the bringer of intellectual pleasure.

I tried the same thing with cross number problems and many of my pupils enjoyed both setting them and solving them. I think that some of my readers may enjoy them as well. I do not have time to work out an entire cross number puzzle but let me give you a clue to think about.

A tailless Roman mile.

The answer is a four-digit number. When you get the answer it will obviously be correct. Do not send me the answer but send me a clue to another number using the same general conventions. I will publish the answer to my clue in the next issue. I will also include all your clues with the names of those setting them.

I will choose one name at random for a small prize.

Notes:

More fields may be available via dynamicdata ..