Title: Francis' Scribbles

Author: Martin Moene

Date: 16 November 2006 09:00:00 +00:00 or Thu, 16 November 2006 09:00:00 +00:00

Summary:

Body:

Thoughts for a New Year

I am writing this on the first day of 2006. I started to think about how the world of computers and programming has changed over the years and the ways in which it has not.

The computer I am writing this article is more powerful than the most powerful machines of the mid 1970s. Since then I have become comfortable with using a keyboard to do my writing, and regularly turn out printed text that is better presented than much of the professionally laid out material of that time.

Computers have changed the way that most of us write, but how much have those teaching writing skills changed their teaching? I suspect the answer is 'not much.' I think that those changes that have happened are often for the worse. Word-processors should allow students to focus on the process of writing rather than the mechanics of doing so. Do our children's teachers require that change of focus or are they still ploughing along with the old ways dressed up in some superficial new clothes? For example, are they still focused on rules for presentation that were designed for hand-written or typed text?

Most people still consider that computers are mathematical tools; so why is it that much maths being taught today is essentially uninspiring and taught by uninspired teachers? Yes, there are many good teachers in the classrooms of the world but too many of them are having their work destroyed by curricula that offer the pupil nothing.

Computers are magnificent tools for both creative writing and mathematical investigation but it is much easier to teach routine material which can be assessed by some objective criteria. Teaching has not got better over the last fifty years, the apparent improvement in the examination results is, in my opinion, almost entirely due to the revamping of examinations so that it is possible to train pupils to get good grades. Teaching that way may produce excellent performance assessments for the teacher and the school, but such teaching is stultifying and brain numbing.

Most of us understand that giving others the tools and knowledge to feed themselves is much more effective in the end than giving them food. So why are we so poor at feeding young minds?

As is often the case when I sit down to write, I find myself writing something very different from what I had planned. I intended to write about how programming has failed to change with the hardware.

Many programmers are still locked into tools that are 25 or more years old in concept and design. For example, most programmers use mono-spaced fonts and text editors that use simple ASCII coding. Mono-spaced fonts were a combination of what teletypes produced and the need to keep track of the columns (for example a traditional punched card had 80 columns; in FORTRAN IV columns 1-6 were for labels and columns 7380 were for the card sequence number – useful when you dropped your card deck). I have heard a variety of arguments put forward for continuing with mono-spaced fonts. The strongest being that all the third party tools for processing source code require files that are in a simple format. With respect, even that is plain stupid. It is easy to make a word-processor that generates parallel files with text in one and format in the other. Human beings can then have the source code presented for easy reading, and the development tools can have the simple text that they need.

This reminds me of the struggle I first had with a keyboard. In my early days of programming, I wrote the first draft of my source code in long hand, and then keyed it in to some computer readable form. Eventually I found that I could dispense with the hand-written stage. (These days the problem is learning to use speech recognition methods. I may eventually learn to dictate my source code to my computer.)

If the only problem with programming was the use of unimaginative tools I suppose I could shrug my shoulders and put up with it, but the more fundamental problem is in the programming languages we are using. They are inherently designed to support software development for a machine with a single processor. There has been hardly any development of language features for computers that have more than one processor (or core in a multi-core CPU) running at a time (yes, I do know about languages such as OCCAM). I have listened with increasing dismay to the explanations of others about how clever compilers, instruction schedulers etc. mean that human beings do not need to worry their little minds with parallel execution of code.

Those responsible for languages like C and C++ are honest enough to admit that those languages are based on the assumption of sequential execution. The problem is that this assumption is buried very deep in computing. The tools for multi-threaded programs still assume that there is just one processor that switches between threads. In other words if one thing is being done, nothing else will be executed at the same time.

However the newer languages such as Java, C# and Python have the same assumption, it just has not been so clearly stated. The popular programming languages assume that things like multi-threading are done by a form of task switching. When that is not the case because different threads are running on different cores (and if they are not your program is not making effective use of the hardware) you have serious problems waiting to manifest at the worst possible time.

The assumption that only one instruction is executed at a time is not true any longer. I was recently talking with some of Symbian's (responsible for the Symbian OS used on many mobile phones) staff when the subject of the C++ abstract machine came up. What shocked me was to learn that the next generation of mobile phones will use multi-core processors. At least that company was aware that this change had fundamental impact on their programming methods.

Software is steadily taking over the world. That means that getting it wrong has an ever increasing potential for disaster. Your wireless, your TV, your MP3 player etc. are all essentially software supported by some hardware.

The world has changed in ways that many have not noticed. Most people see the outward changes but completely miss the changes in how the task is carried out. If programmers cannot adapt to the changing world of software and silicon what hope has the rest of the human race?

Global warming may create a disastrous climate change but I suspect that our inability to handle our changing technology is just as big a threat. We need to break away form our comfortable belief that it will all work out in the end. Only when we accept that we have a problem and do not know what we are doing will we be in a position to do something about it.

Commentary on Problem 23/24

I am republishing this problem because no one responded. I know that some readers have an idea as to what the problems are. I also have an SQL problem which I will publish next time.

Problems with initialisation have been of concern to those responsible for working on the next version of the C++ Standard. Have a look at the following code and comment on any possible surprises.

#include <iostream>
struct X {
   int i;
   X(){}
};
struct Y: struct X{
   int j;
   Y(): X(), j() {}
};
Y y = Y();
int main(){
   std::cout << y.i << std::endl;
   return 1;
}

Please focus on the interaction of an explicit constructor that does not initialise all the member data and the rules for global initialisation.

The second problem with the code is that while the Standard guarantees the result of returning zero from main(), it does not guarantee what will happen if you return any other integer value.

Cryptic clues for numbers

Last issue's clue

Help! Looks like a sailing dinghy. Hawaiian police series number 5. (3 digits) The answer is 505 (I have not had any entries, so that saved me finding a prize.)

This issue's clue

On reflection, this issue is still the same prime. (3 digits)

If you wish to take part in this competition, please remember that you have to supply an alternate question for the same answer before you can claim the prize!

Notes: