Title: Editorial

In a break from routine, I would like to start by saying thank you to all of those who continue to contribute. My greatest fear when I took the helm of C Vu was that I'd be begging for material days before a deadline. To date that has not happened, and indeed you, the readership, have been spared the horror of having me publish my own articles. (That day will come, and then you will know of what I speak!)

The first appearance of an article from ACCU's recently-formed Python SIG raised some concerns about the direction C Vu is taking, and which direction it ought to be taking. Some things are uncontroversial, I hope: C Vu is to be consistent with the goals of the ACCU, in particular advocacy of professionalism in programming at all levels, both when programming as a hobby and when employed to do so. So far, so good. The field of programming, however, is far too large to be covered by a single journal, or most likely even a single organisation. We must limit our attentions, or risk failing to do justice to any area we explore. The C and C++ programming languages remain the essence of ACCU, but professionalism dictates that we should not be so narrow minded as to neglect other tools. The question then becomes: how much effort should ACCU invest in things outside of the world of C and C++ and how much space should C Vu devote to them? If we cover Java, should we also cover C#? If we welcome a Python SIG, what about Perl? Tcl?

Sven Rosvall's letter is one opinion. In his column Francis Glassborow presents another. Surely there are more, and equally surely a solution will be found that is acceptable to the vast majority of ACCU's pragmatic membership. Please do consider what you want from ACCU, and make your voice heard. You can write on the mailing lists (such as accu-general), write to <cvu@accu.org>, or find you own forum. ACCU being the way it is, the decision will be made by the members who make the effort to influence it. Those who contribute material also have a large say - as editor, I only select from the material I receive and ask for volunteers to write about subjects that I know to be of interest to the readership.

A vital tool in every serious programmer's toolbox is (or should be) a version control system. Any company developing software without one should address that now. (If that's you, stop reading. Install version control before reading on.) Version control is the most basic level of the whole subject known as software configuration management (SCM), and companies such as Rational Software and Serena Software will be happy to buy their consultants expensive cars with the fees they will charge to make sure your SCM solution is working as it should. One remarkable thing, though, is how hard it is to find a version control tool that can support even a basic set of functionality with no fundamental flaws. Surely software designed to help development ought to allow effortless renaming of files - and yet most products fail to achieve even that. One major version control tool comes armed with tools to repair its database when it inevitably becomes corrupted. Even spending £1000 per developer does not guarantee that the basics work as they should; as is so common, the extra money seems to buy extra features, many of which you won't use, rather than buying better quality.

In a recent attempt to determine which SCM solution was appropriate for my company, one thing surprised me. It is remarkably hard to find good impartial information on the pros and cons of different version control systems when you get outside of the low-budget options such as Visual Source Safe and CVS. Various of my colleagues had experience of assorted other systems, but most of us happily just fall into place and use whichever system a company imposes without taking the time to learn about it in depth. SCM isn't what drives us, it's just a necessary thing (and sometimes feels like a necessary evil.)

Once again the punchline is too obvious: that ACCU members, between them, have a vast wealth of experience of version control and higher-end SCM systems, and with effort could collate that experience into a rich resource. Is there a willingness to do this? If so, how would it best be done? I would be happy to publish summaries of individual tools, or comparisons, or descriptions "from the trenches" of members' experiences in trying to get these tools to make development better, not harder.

Experience in a number of places suggests to me that much teaching of C++ in academic institutions (where commercial interests have not driven faculties to teach Java or C#) is still covering pre-standard C++. Given that the C++ Standard has not changed since it was officially published in 1998, there now seems to have been ample time for most people in a position to teach the language to have updated their knowledge, and tools which are able to compile at least the vast majority of modern C++ are widely available without paying an arm and a leg. Surely many college teachers are making the necessary effort, and still others while falling short of this ideal are still offering a valuable service to students who would otherwise have nobody from whom to learn C++. Nonetheless, there seems to be a gulf between academia and practice, and unusually in this case it is often the practitioners who are more formally correct. This is a very real problem, because today's students are tomorrow's professionals and bad habits die hard. It is understandable that most teachers are not experts - achieving and maintaining expertise in contemporary computing is a time-consuming commitment - but there should be steps we can take to help. Maybe our student members can tell us how C++ is taught, maybe we can provide online material aimed at quickly bringing a motivated but rusty teacher up to speed on standard C++. Your suggestions are welcome.