Last Thursday at the Lambda Lounge meeting, we had a language shootout where 8 different solutions to the same problem (spec) were presented. I must give a huge shout-out of thanks to Mario Aquino for being willing to install every sundry language, virtual machine, and OS under the sun onto his machine to make things run smoothly. And thanks to Bryan Venable for providing publicity.
Below you can find my comments on the presenters and their score, which I believe scientifically determines which language is the best, once and for all.
| Presenter | Language | Link | Comments | Score |
|---|---|---|---|---|
| Mario Aquino | Ruby | Link | Mario did his solution in his beloved Ruby and spent a chunk of his time talking about testing with Autotest and RSpec. We also saw a solution to splitting the code into a “vend” and “service” mode using modules and method_missing. | 12 parsecs |
| Tony Brummett | Perl 5 with UR | Link | Tony was presenting a solution based on a brand new Perl ORM framework called UR. UR has been in development for about 4 years at the Genome Center at Washington University. Tony had an ambitious presentation talking about UR and his database-backed ORM solution generated by UR in Perl. (UR is also written in Perl.) Tony’s task of explaining UR along with the solution was likely doomed from the start and unfortunately we just got a taste. Hopefully he’ll back in the future to tell us more. UR is being released soon (if not already) to CPAN. | 300 |
| Rich Seibel | Python | Link | Rich set out with the goal of showing off not the fancy features of Python but what is *not* fancy about it. Rich went through his entire presentation and had an astonishing 5 (of 12) minutes left for questions. The solution made some interesting design choices like refusing to give change. :) | e^(i*pi) |
| Ryan Senior | Squeak | Link | Ryan did our first presentation at Lambda Lounge on Squeak / Smalltalk and I hope not the last. It was very interesting to see both the similarities (and differences) between Squeak and other OO languages. | 30 Love |
| Aditya Siram | Haskell | Link | Aditya presented a distributed solution in Haskell. We had far too little time to look at the actual implementation. The most interesting design choice was that he chose to replace validation checking with the perfectly valid concurrency strategy of blocking until a problem (like lack of item or change) was resolved by some other client. Clients connected by telnet. Next month Alex Stangl, our local Haskell guru, will be doing a much longer presentation on his own Haskell solution. |
5 dining philosophers |
| Matt Taylor | Groovy | Link | Matt had a nice Groovy solution and even built a bare bones GUI with the Griffon Swing builder framework. He also introduced the new 13 cent “Taylor” coin. | 2 turntables and a microphone |
| Mark Volkmann | Clojure | Link | Mark was imminently prepared of course and brought handouts with the full Clojure solution. He showed off his very compact and readable tests and the rest of the code. The methods to make change were especially interesting. | 1 partridge in a pear tree |
| Tom Wheeler | Perl 5 | Link | Tom wrote what he called an “idiomatic” Perl solution (no documentation, no unit tests :). Interestingly, his solution was remarkably similar to Rich’s earlier Python solution. | 800 pound gorilla |
| Tim Dalton | Scala | Link | Finally, Tim presented a Scala solution which used the futures framework and some interesting asynchronous code to manage incoming requests. | 3 stooges |
All in all, we had a great time hacking our way through a bunch of languages. Realistically, trying to look at 8 solutions in one night is insane and bound to slight all of the presenters and languages. I think the next time we do this we should shoot for fewer presentations per meeting and more time per presentation. These kinds of shootouts are great fodder to drive more presentations. We’ve got a Haskell vending machine solution next month and a Fan presentation the month after.
My own personal favorite thing was seeing how a specification I wrote turned into almost a dozen implementations (some not presented) which in some cases made wildly different design decisions on how to interact with the machine, how to implement error conditions, how to test the solution, etc. It was a great demonstration on how ambiguous specs (in this case by design) can lead to a different vision for every reader and without feedback, you’re likely to produce some quite different than the original description.
Oh also, we did record the presentations on video. Hopefully sometime in the near future we will get those broken up and uploaded somewhere where you can peruse them.
Also, there was a photographer on hand to capture the intensely geeky gathering. Hopefully in the future, I’ll be able to share more of the pictures. For now, you can find one shot here at the photographer’s daily photo blog (not the piano part obviously).