ACCU 2012 was another great conference in the series. Lots of good sessions, occasional not so good one, lots of time for socializing (we'll ignore the euphemism networking, and call it what it is) and a lot learned.
There was more of an explicit emphasis on C++ this year, but this was due to the submissions offered to the conference committee rather than any direction on their part. Almost certainly the history of ACCU being a C and C++ focused organization, and the publishing of the C++11 standard, had much to do with this.
A great deal was made of the "death of C", but everyone was explicit that this is C being a dead language in the way that COBOL is a dead language: you don't use it but there is an awful lot of it about.
My contributions this year was, as ever, to do with concurrency and parallelism. I did a session "Go, D, C++ and the Multicore Revolution" which was asking whether the changes to C++ due to the C++11 standard was just too little too late. C++ now has a memory model, asynchronous function call and futures but this is still an abstraction level below that that applications programmers deserve. Go is trying to replace C and incorporates Communicating Sequential Processes (CSP) as its model of concurrency and parallelism. Go is considerably simpler than C++ and yet achieves most of the tools for abstraction and programming that most programmers need most of the time. D is trying to replace C++ and has far better facilities for generic programming and uses actors as its model of concurrency and parallelism. It could be said that D is already that which C++ is evolving to become.
I introduced the C++ actor system that Anthony Williams' Just::Thread Pro will have - I have a preview version - to show that C++ could catch up with Go and D if there was a recognition in the C++ community and standards committee that C++ needs to make use of the goodwill generated by the C++11 standard. C++ has the potential to be an interesting programming language. In the mean time Go and D are already very interesting languages, they make native code working feasible. Unlike C, but then that is now a dead language.
The slides for the session are here but they probably don't mean that much out of context. The codes shown are in the Bazaar branch to be found here. We didn't do any of the Sleeping Barber material, interactions during the session meant we only looked at the Π by Quadrature material.
I did a second session in collaboration with Schalk Cronje. The core technical content was to show actors, dataflow, and CSP in action. The subplot was to some some comedy. We had sketched out the plan a few weeks before, but had to leave final planning to the very last moment. So we had a structure and a rough plan, but hadn't done a full script; we had to do a lot of ad libbing. I am not sure it worked completely, but the audience got involved and didn't leave. The problem we tackled was generating signatures for files in a directory hierarchy. This is a real problem from Schalk's work, not a toy problem. If people were enthused that Groovy already has, via GPars, everything that all the other languages desire in the way of actors, dataflow and CSP support, and that the future of applications programming is to use these models, then the session was a win.
The slides for this session are here. The code used is in a Git repository: the bare repository for cloning is http://www.russel.org.uk/Git/ParalysedByParallelism.git, if you just want to browse without cloning then you want to go here.