Title: ACCU Conference 2005

"This was the most inclusive and interactive conference that I have been to. There were nightly group outings to dinner and the pub and everyone was welcome. Sometimes we overwhelmed the restaurant. I met many people who post on accu-general and it was good to put names with faces. The conference had two main benefits for me. The quality of the talks and the presenters, and the ability to mingle and talk to others. Some of the key points I took from the talks are:

• That bugs and security issues in software can be classified by mean time to bug - how long it takes to find a particular issue. The security talk on this subject brought me back to college since the professor used handwritten viewgraphs which were hard to see from the back of the room.

• There are significant differences between the implementations of generic programming in Java, C# and C++, and they have to do with specific design goals.

• Concurrency is hard; even the experts get it wrong sometimes.

• There is some cool stuff coming in the C++ 0x standard including concepts, move semantics, class extensions etc. Many of these new features are designed to help the beginner or part-time programmer and to remove the necessity to become an expert and learn the tricks. Unfortunately, we will have to wait for 2009 for the standard and 2011 for a compliant compiler.

• You too can extend the iostreams with a few simple rules.

• That symmetry is good except for when it is bad.

• That software development is learning. However it does matter how you define knowledge and learning especially if Coplien attends the talk.

• If you want to sit down in a talk, you must arrive early.

• That software is really about solving business problems not about applying object-oriented techniques. It is about writing specific software not general software."

"Kevlin first explained about the session name - apparently it's difficult to convince programmers (and their managers) that an 'Intermediate' C++ course is going to be useful, but he couldn't bring himself to contribute to a name inflation problem and go with 'Advanced'. He then lead us through a number of topics: Value-based programming, an Intro to Templates, Encapsulation and Cohesion, Generic Programming, and Class Hierarchies. Along the way, he was quick to show us just where things could be improved in the C, C++ and CORBA standards, and taught us never to feel embarrassed about pulling a door marked push.

The audience had varying levels of experience with C++, but I'm sure that everybody learned something new, and had to re-examine some of what they thought they understood. Down in the shallow end, I was thrown enough familiar material to feel safe about being stretched in the areas I had less experience with. 7 hours clearly wasn't long enough, with a whole section on exception handling having to be cut, but I still think it'll take me at least 6 months to absorb everything raised on the day and in the notes."

"Paul gave us a bottom-up introduction to Aeryn, his new lightweight testing framework, starting with test conditions and building up to named test sets. Not only did he explain the features, he took the time to explain why they'd turned out that way - going so far as to challenge us with, "Aeryn uses macros, anyone got a problem with that?" Thinking about it now, I'm sorry nobody spoke up (I think the accompanying glare put us off...) - Paul must've been ready to put us all straight, and I'd definitely have learned something. He showed us how customizing the result reporting format only requires plugging into a simple interface, and then explained how Mock Objects can help break dependencies in test code and speed up the feedback loop.

Aeryn has a feature that blew me away: if an object being tested is streamable, the test output streams it; otherwise we get a sensible default. Paul and Richard Harris helped show me how this magic worked after the session - giving me a first taste of SFINAE."

"To write software, we must learn the problem domain, and lots of technical skills, and lots of process skills. The act of writing software enables ourselves and our customer to learn more about the problem, and often leads to changes in requirements. Allan used this session to present his ideas on learning, and on how acknowledging the big role it plays allows us to improve the development process. He suggested that books and presentations etc. are mere information until they're acted upon, and that the action allows learning to take place, turning information into knowledge. This means that learning and change are closely connected, and that separating them can be unproductive. Allan's presentation resulted in a lively discussion with the audience (see www.allankelly.net), and revealed that lots of people seem to be worried about learning stuff that's just wrong."

"An excellent presentation by Herb comparing generic programming implementations comparing and contrasting Java, C#/.NET, C++ generics in .NET and C++ templates. This was in typical Sutter style switching between presentation slides, a code editor and the command line, and between Microsoft and Linux. This session provided two of the humorous moments of the conference: there was no obvious way that Herb was changing slides in the presentation so someone asked how - the answer was that he had a remote mouse in his trouser pocket, to which someone had to ask what he was operating it with. Later, after one of Herb's jibes at Microsoft, a mobile phone rang in the audience, and someone was quick to call out "It's Bill"."

"The sub-title for this partly interactive presentation was "Patterns for the end game". Although the presenters' intent was to cover the problems that occur at the end of projects and how to overcome them, much discussion ensued as to whether they were really end-of-project problems and solutions. If a problem occurs at the end due to mistakes earlier on, it is not really an end-game problem, this is just where is manifests itself. Likewise, problems that can occur anywhere, but are much more serious or obvious towards the end, are not end-games problems, just more visible then. The prepared conclusions backed up the discussions in that end-game planning is just part of the overall project management."

"Hubert started by explaining that concurrency problems are rarely found in the real world - you never see two skeletons locked in a deadly embrace - so they are a machine issue for which we have no natural ability to understand. Also, concurrency is rarely an explicit user requirement - it is an issue in solution space rather than the problem domain. Traditional and contemporary methods of writing correct software and proving it correct such as unit testing, invariants, pre- and post-conditions, and regression testing don't work for concurrency because the problem is temporal, rather than sequential, and a change in the timing can radically change the outcome. Hubert covered a number of real world examples to demonstrate there is no obvious solution, and maybe no solution at all. There was considerable discussion during and after the presentation indicating considerable interest and concern about the subject. This was a thought provoking presentation about a subject we are likely to hear much more about in the future."

"Detlef aimed to dispel any remaining thoughts that concurrency is anything but very difficult. First he recalled the number of experts who thought they had solved concurrency and then were proved wrong - often after publishing a "definitive" book! Then he showed how the atomic operations required by concurrency (e.g. popping off a stack) are opposite to the requirements of exception safety provided by the STL (top(), void pop()) - you cannot have both thread safely and exception safety in the same operation. He peppered his talk with practical demonstrations of a Mandlebrot graphics GUI window with concurrency "solutions" and either their failure to solve the initial problem or how the new problems they introduced were worse than the original problem. Discussion and questions at the end overran the time allocated suggesting that this is a subject of great interest and concern to a lot of developers."

"Kevlin hosted an interesting and lively finale to the conference in the form of a lively panel quiz with considerable audience participation. The last slot on Saturday is a difficult one to fill - many delegates need to leave early to catch transport links and those left are often flagging from long days and even longer evenings! Both an endnote and running normal slots have been tried in the past and some alternative was sorely needed. This was the right ending, and the right person to present it - Kevlin took no prisoners, even the conference chair was not spared as he tried to keep score to many decimal places as whole, fractional and sometimes decimal points were awarded, and sometimes taken away. Some of the subjects covered were literature (C++ standard to the Hitch Hikers' guide to the Galaxy), people (Dennis Ritchie's middle name), and guess how the audience will vote on a vague question. Fortunately the four panellists walked away with some decent prizes that Kevlin had managed to extract from the sponsors, so their humiliation was not totally in vain."