The third and final day of QCon didn't kick off with a keynote, which meant that the conference hall felt pretty empty just before the talks. I wonder if there would have been more traffic had Dan Ingalls evening keynote on Wednesday had been moved to Friday morning.
- Message passing concurrency (perfect for agent-style behaviour)
- Purity and control of side effects (using types to preserve the state)
- Traditional languages (for those with a real job)
He noted that the wrong abstraction leads to issues with the representation (and therefore solution) of the problem; for example, XLVIII*XCIII = MMMMCDLXIV is a lot less open than 48*93 = 4464.
The key problem with shared memory and fault tolerance is that you have no idea why (or even if) one of the other components in the shared memory system has crashed. So Erlang's approach to parallelism is to simply forbid shared memory; after all, this works for systems connected across the internet where there is implicitly no shared memory.
Erlang's message passing semantics means that the caller and server are isolated, and that no data is shared. He even called up a quote from Alan Kay (father of Smalltalk) saying “I'm sorry I coined the term objects; It's all about messages”.
One great thing about conferences is that you can go up and meet the speakers afterwards, or indeed, during Friday's “meet the speaker” session. I was especially interested in Erlang's approach to distributed functions, and the ability to send functions remotely; if the remote server has all the definitions of dependent functions already, this approach is seamless. If not, the remote server has to load them; and apparently, the assumption is that the Erlang node has an up-to-date copy of the dependent functions which it can resolve locally if needed. Erlang is really a powerful language, and if you need to learn a new language this year to keep your grey matter ticking over, Erlang should be it.
The next standing-room-only presentation was Rod Johnson discussing Spring Roo. This is a productivity enhancing tool for writing Spring-based applications; and whilst Spring lets you configure anything you want in any way you want, Spring Roo is more constrained in that it follows convention over configuration. It allows you to put together JPA-backed persistent entities (like Ruby on Rails or Grails) using nothing more than a few annotations and some generated code. Unlike other approaches (EJB, DAO) the persistence functions are weaved into the data object itself; unlike other approaches, this is done at compile time using aspects and weaving.
Spring Roo seems to be very useful at prototyping persistence layers. In addition, a few clicks later saw the creation of a web-based interface for CRUD operations on the data set, with virtually no coding support needed to get it up and running. Hopefully the code sample will be available from the QCon website in the future (in which case, I'll link back here); in the meantime, more information can be found at the Spring Roo website.
As a follow up question, I asked what the generated code is like for interacting with OGSi. Fortunately, each Spring Roo project is its own OSGi bundle, and the JPA and Spring autowiring can take advantage of OSGi services, so it seems eminently possible that you'll be able to use Spring Roo as a way of generating OSGi-aware persistence layers. As I noted on Twitter, this may be the end of web-based CRUD outsourcing as we know it...
The penultimate talk was Ralph Johnson on Pattern languages for parallel programming. They are working on a wiki to catalogue parallel algorithms (available at ParLab) and cover the basic approaches to parallelism. There are a number of common concerns, like how to size the units of work such that the data overhead doesn't subsume the data itself; but most of the information you can find from the wiki.
The day (and conference) finished off with Alex Buckley, Kevin Seal and myself discussing the future of modular Java in front of a live studio audience. We got across the basics, but unfortunately Kevin's war stories (coupled with the fact that they rolled-their-own build tool, rather than using maven-bundle-plugin or bnd or bundlor) probably gave the wrong impression that modularisation is either difficult, unnecessary, or irrelevant. I'm not sure those that came who didn't know about JSR 294, OSGi or even Jigsaw left any better than they started. It didn't help that there was an event discussing the future of OSGi for the Enterprise at the same time, which meant that the number of people attending wasn't that high.
Conclusion: Bar minor timing clashes (which are always a possibility at such events), QCon was a resounding success. The main goal of such events is to round out thinking on subjects which may be slightly further afield, and QCon avoids the trap of being too vertically integrated to a tool/language. The diversity of the speakers and topics, coupled with technical and non-technical presentations, results in a well-rounded conference that was aimed squarely at the technical architect level instead of the developer. I'd highly recommend going to the San Francisco one; to get a feel of what they're like, you can browse the presentations or catch up on the pre-recorded videos from past conferences. Hopefully, the 2010 videos will come out over the remainder of this year.