QCon London: The Best One Yet

March 18th, 2009  |  Published in concurrency, conferences, erlang, functional, functional programming, RPC, standards  |  Bookmark on

QCon is always very, very good, but QCon London 2009 last week was the best one yet. Highlights:

  • Ola Bini‘s “Emerging Languages in the Enterprise” track on Wednesday had some great talks, especially Rich Hickey’s Clojure talk. Ola’s deep knowledge and love of programming languages made him the perfect host for this track, and he put together a brilliant lineup.
  • Speaking of Rich, I consider myself very lucky to have gotten to meet and spend a fair amount of time with him. He’s very bright, talented, knowledgeable, and experienced, and both of his talks were outstanding.
  • I introduced Rich to Joe Armstrong at the conference party Wednesday evening and they spent the next few hours talking at length about functional programming, their respective languages, VM implementation issues, concurrency issues, etc. Ola jumped in as well. They also continued the conversation the next day. I just sat back, listened, and learned.
  • Getting to spend time again with Joe was excellent. He always has incredibly useful analyses and opinions to express, and in general is fun to be around and easy to learn from.
  • I also finally got to meet Ulf Wiger, Erlang developer extraordinaire, in person. He’s a laid back guy, quite well-informed and a deep thinker who can cover a wide variety of topics in amazingly useful detail. His talk on multicore programming in Erlang covered cutting edge Erlang development and presented some very difficult concurrency issues.
  • Ulf’s talk, as well as Rich’s second talk, which was on persistent data structures and managed references, were part of Francesco Cesarini‘s “Functional and Concurrent Programming Languages Applied” track on Thursday. I met Francesco, who like Ulf is one of the world’s top Erlang developers, at QCon London last year. He assembled a great track for this conference, with Rich’s and Ulf’s back-to-back talks being way more than enough to sober up any developer who thinks that multicore is not an issue and that today’s methods for dealing with concurrency will continue to work just fine. Best of luck with that!
  • Sir Tony Hoare‘s talk about the null reference being his “billion dollar mistake” was great because of all the detail he recounted from some of the early days of computing. He was both informative and entertaining. I was also impressed with Ulf during this talk, whom Professor Sir Hoare invited to come up to the front and present what turned out to be a pretty convincing argument in favor of the null reference.
  • Paul Downey‘s talk on the downsides of standardization was by far the most humorous talk I heard, perfect to close out the track, but it also presented a number of hard-won useful lessons about the perils of standardization efforts.

As with all QCon conferences, there were a bunch of interesting tracks running in parallel, and unfortunately I still haven’t figured out how to be in multiple places at once. I had to miss Michael Nygard‘s talk, for example, because my own talk got moved to the same time slot as his.

My talk (PDF) covered the history of RPC, why it got to be the way it was, and why the forces that created it really aren’t all that viable anymore.

The final conference panel was by far the most inventive panel I’ve ever been on. Modeled after the British game show “It’s a Bullseye!” and hosted by none other than Jim Webber, it had contestants from the audience throwing darts to become eligible for a prize. Once a contestant became eligible, Jim would ask the panel — Michael Nygard, Ian Robinson, Martin Fowler, and me — to answer a question submitted by conference attendees either earlier during the conference or live via Twitter. Based on our answers, audience members held up either a green card if they liked the answers or a red one if they didn’t, and if the majority was green, the contestant would win a book. The questions were hard! We had only two minutes each to answer, which for some questions seemed like an eternity but for most was way too short. Anyway, it was great fun, and given how many there were in the audience after three grueling conference days and how much they seemed to be enjoying themselves, it worked very, very well.

If you have any interest at all in leading edge software and computing topics being presented by the world’s most knowledgeable speakers in a fun atmosphere, go to QCon. I guarantee you won’t be disappointed.

Damien Katz Criticizes Erlang

March 10th, 2008  |  Published in code, erlang, functional  |  Bookmark on

Damien Katz has been using Erlang for CouchDB, and has posted some criticisms of the language and runtime based on his experiences with them. Erlang, like any language, has its issues, and Damien’s criticisms are mostly reasonable and are worth reading. Well, except for this one:

Immutable variables in Erlang are hard to deal with when you have code that tends to change a lot, like user application code, where you are often performing a bunch of arbitrary steps that need to be changed as needs evolve.

In C, lets say you have some code:

int f(int x) {
x = foo(x);
x = bar(x);
return baz(x);

And you want to add a new step in the function:

int f(int x) {
x = foo(x);
x = fab(x);
x = bar(x);
return baz(x);

Only one line needs editing,

Consider the Erlang equivalent:

f(X) ->
X1 = foo(X),
X2 = bar(X1),

Now you want to add a new step, which requires editing every variable thereafter:
f(X) ->
X1 = foo(X),
X2 = fab(X1),
X3 = bar(X2),

If you had to write that code the way Damien did, then yes, that would suck. But here’s a better way to write it:

f(X) ->
    lists:foldl(fun(F, Last) -> F(Last) end,
        X, [fun foo/1, fun fab/1, fun bar/1, fun baz/1]).

This code applies the anonymous function passed as the first argument to lists:foldl for each element of the third argument — the list of funs, Erlang-speak for functions — starting with the value X as the value passed as Last and using the return value of F(Last) as the next value of Last. The overall return value of lists:foldl is the final value of Last. With this approach, modifying the functions applied to X also requires editing only a single line, specifically the list of funs.

In general, if you’re used to imperative languages and you find yourself writing step-by-step Erlang code like in the original example above, think functions and lists instead.

P.S. If you’ve never seen it, read Damien’s Signs You’re a Crappy Programmer (and don’t know it). One of my favorite blog postings, and I especially like the first two items in his list.