Title: Editorial

This month's C Vu welcomes Ewan Milne as our new chair. Alan Griffiths has served in this capacity for a number of years, and has done fine work, overseeing considerable progress in the life of ACCU. So, thanks to Alan for getting ACCU to where it is today, and good luck to Ewan with taking it forward from here. Ewan's first "From the Chair" piece can be found after this editorial.

An organisation such as ACCU (with its new, freestanding name acknowledging the evident fact that ACCU is about much more than just C and C++) needs to combine progress with continuity. C Vu, too, works best when it combines contributions from new authors with material from regular contributors. Without his permission, I would like to thank Pete Goodliffe for being one of those regular contributors, with his column on "Professionalism in Programming" being right at the heart of the spirit of this journal.

Pete's "Professionalism" column in this issue mentions Martin Fowler's "Refactoring" book. This also received my recommendation, mirrored in Paul Grenyer's article published in a previous C Vu. The same books come up time and again, for good reason, and I am unashamedly using this opportunity to recommend it again. Some will dismiss this book for writing about simple things, but its approach of breaking a change to a program down into the smallest possible almost mechanical steps is a powerful way to allow us to make code better. Many books are written on how to design code from scratch, but most of the time most of us are changing existing code - indeed, some people with sympathies for the Extreme Programming school of thought claim "you're always doing maintenance". For that reason, it is often easier to apply the advice found in texts which discuss how to change our code and designs rather than how to come up with designs on the well understood but relatively rare occasions when we are given a clean slate. "Refactoring" is one book that addresses this niche. Please do tell me about others you have found - I am always happy to receive mail to <cvu@accu.org>.

Pete Goodliffe also talks about the role of simplicity in software design, and its limitations. Simplicity is so important that it is tempting to advocate making it a cornerstone of any course on software construction - and yet so elusive that we really don't know how to teach the idea. What counts as the simplest code to an experienced developer might be intimidating to a fledgling software engineer fresh out of college. It takes time measured in years to become truly comfortable with all of the idiomatic uses of a complicated programming language like C or C++. (Fans of simpler languages such as Java or Python can instead note that it takes years to become familiar with idiomatic uses of the libraries from those languages.) There is a balance to be struck between writing "neat" code (which might require less experienced developers to learn a new idea) and writing "excessively clever" code that can confuse or even mislead other programmers. If too many of your colleagues think that your code is "too cute" or "complicated", remember that the most important function of code is to be comprehensible to other developers. Most of the work will go in maintenance after all, and code that meets the original specification but cannot be changed as requirements evolve will have to be rewritten. Simple code is more flexible as well as more readable. Clever code should be reserved for (i) situations in which advanced techniques are necessarily involved and (ii) developers who are insecure about their real skill, and need to seek job security by writing code nobody else can maintain.

For those who have read Pete's articles in the past, and nodded sagely at the hard-earned experience he distils, I'd recommend digging up the old ones and re-reading them from your current perspective. Think about how your current role can use the same knowledge from different angles. If you're finding that you take on an increasing amount of leadership or management responsibility, take note of the comments Pete has made on how developers interact with team leads and managers - and make sure you are not turning into the pointyhaired manager you once mocked. (And the other way too: if your "boss" is a battle hardened software developer, he or she will remember dealing with managers who "just didn't get it", and will probably appreciate a friendly word if he/she starts to forget where he/she came from.

An aside: how long is it before English adopts a gender-neutral form of he/she? I am no fan of excessive political correctness - those who know me will attest to that - but writing "he/she" tires quickly for writer and reader alike, attempting to use each gender equally often in an arbitrary way is a hack, and writing "the masculine pronoun he will mean either he or she" is an unbearable contradiction. Those wanting an interesting diversion from more common topics might like to investigate online, maybe starting with a look at the gender-neutral pronoun FAQ at http://www.aetherlumina.com/gnp/faq.html.

And now, if you will permit me, I'm going to talk a little about programming languages.

Recently I have been learning about C#. Previously I had understood it as a rip-off of Java, and read little more than that. Increasingly, though, I have been asked my opinions of C# from a technical point of view, and so it has been necessary for me to develop some more refined impressions. Previous conversations convinced me that C# might be a better programming language - considered as a programming language in isolation from its larger environment and commercial considerations - than Java, whilst still being similar in concept. So, I have dug a little deeper, and written some code, using the DotGNU implementation of the C# compiler and its associated runtime running on Mac OS X. (More of that another time.)

For those who are at least somewhat familiar with Java but haven't looked at C#, I would recommend taking the time to learn a little about the new kid on the block.

One very small point may be of interest. In C++, we learn that += is a more primitive operation than binary +, and so idiomatic code tends to implement the binary addition operation in terms of operator+=. In C#, += is a pure abbreviation, and hence if an operator+ is defined for a type (recall: C# has operator overloading, whereas Java does not except for its String class), operator+= will come "for free". For a class type, it just won't be as efficient as an operator+= in C++, because it needs to create a new object. For the C# gurus out there, I'd be interested to hear if a smart C# implementation could avoid the creation of a new object if certain constraints were satisfied - such as the lhs being the only reference to its referent.

The appearance of a competitor in C# appears to have given new speed to the evolution of Sun Microsystems' Java programming language. Features slated for Java 1.5 include templates (though in a less powerful form that the template system of C++), enums (Java dropped these from C, but C# reintroduced them and now Java seems set to do the same), a foreach construct, and automatic boxing and unboxing (similar to that seen in C#).

"The new language features all have one thing in common: they take some common idiom and provide linguistic support for it. In other words, they shift the responsibility for writing the boilerplate code from the programmer to the compiler." - Joshua Bloch, senior staff engineer, Sun Microsystems

C#, too, is acquiring templates. It is interesting to see in the evolution of the languages touted by some as C++-killers that contact with real programming problems causes them to trade off some of their initial simplicity for power. C++ is indeed far from perfect - but I'm reminded of an overused quote about people unable to remember the past. ("Condemned to misquote it," or something like that.)

All of this is of course for fun only; for programming projects in the commercial world it is rare to be able to choose based on the technical merits of a programming language only. Just among ourselves, though, it's sometimes fun to re-enact the great language wars, so long as we remember that it's no way to make the real decisions.

Remember to have fun programming.