CUSEC started with a bang. Right off the bat we got a talk by Tim Bray, an inventor of XML and Atom who was CEO of Waterloo Maple for a while and now works for Sun. He talked about what we as a software engineering/computer science community do well and what we dont.

First, what we do well. We've managed to create a seamless platform that runs on any computer running any os with a very low barrier to entry. So if you want to do something fun and interesting, that's a good avenue to follow. More on this platform later.

There are some things however that we do extremely badly. Two of the worst are Integration and Concurrency.

When talking about integration, he mentioned how terrible we are at making programs communicate between each other. This was actually a very pervalent theme among keynotes this year since Dr. Grogono and Jon Udell also spoke about the communication and interoperability problem. Unlink most however, Tim Bray offers at least an avenue for a solution. We tried Corba and it failed. It's extremely hard to get working and once you do it's not at all flexible and very very brittle. We tried SOA and the jury is still out on that. Some people seem to get it working and some others fail miserably. So perhaps SOA holds at least some elements to a solution. The avenue that he claims has most promise however is the one platform that runs on all computers seemingly efforlessly, that everyone knows how to use and has been working well for a very long time. This platform isn't a virtual machine. While interesting small scale solutions to share between applications, you're stuck with a single stack. The JVM lets Ruby programs communicate to Java programs but not C# applications since they run on the .NET (or mono) VM. The platform in question is actually the internet. If we structure our programs to conform to the basic tenets of the internet, we can get them working together. He mentions REST from Roy Fielding's thesis as a useful structure for exposing your programs to others for access. I was going to write a little about REST but since a large part of Jon Udell's talk was based on REST style architecture and the social implications of it I'll leave that until then. For now, if you don't know what REST is you can check out the Wikipedia article on it.

So while a RESTful architecture for new programs would be a great help for the future, finding a solution that would let RESTful programs communication with legacy applications is a problem that still needs to be solved.

Another huge problem is concurrency. As Tim says, Moore's Law has gone sideways. We ran into some fundemental laws of physics and can't really increase clock speeds that much. At least not until we realize there's a way to go faster than light!

Image Source

As that chart shows, Moore's law is still holding. We still have more transistors. But the effects are no longer the same. Instead of increasing speeds we have an increase in the number of cores. While this is theoretically interesting, it won't be truly practical outside a few domains such as video encoding until the people who write software get much better at exploiting it. Tim mentioned the experiment he's been running to see how much a theoretically IO bound program can be sped up by exploiting more cores. The results are surprising. From the initial simple Ruby script that ran in 1 hour 43 minutes, the run time is now down to 1 minute and 51 seconds, quite surprisingly a Perl script.

But we still have a problem. The Ruby program is 13 lines of code. The Erlang programs clock in at over 300 and the Perl solutions, while smaller are still something like 5 times the amount of code. We know that more lines of code means more bugs. And not only is it more code, it's vastly more complex code. It's a breeding ground for problems. Which is why we have libraries to help us and language features for simple threading.

Again however, while we do need better solutions for writing future programs with massive concurrency in mind, we also need to take into account older programs. The Ruby program actually ran slower on the massive 8 core server than it did on Tim's laptop. If someone could find a way to take existing code and parallelize it automatically, that would be an incredibly huge advancement. But it's hard. Very hard.

Lots of very smart people have been butting their heads against these problems for quite a while so it isn't a space for the faint of heart. But with enough new ideas and enough work, we just might be able to solve them for good.

A small aside: Tim provided my only big dissapointment at this year's CUSEC. It wasn't his fault at all, it was entirely mine. When I saw the excellent Beautiful Code book on one of his slides I nearly kicked myself. I'd forgotten to bring it! I'd wanted him to sign it for me. I brought it the next day but since Sun bought Mysql, Tim couldn't stay. Hopefully one day I'll see him again. I would certainly enjoy attending another one of his talks.