Lambda Lounge Calculates Best Language

6

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).

Comments

6 Responses to “Lambda Lounge Calculates Best Language”
  1. rifraf says:

    So that makes Ruby light-years ahead?

    (39.1396351 lightyears according to Google)

  2. Thanks for my partridge! What do I feed it? I’m worried my dogs might eat it. I do like pears though.

  3. Gabriel C says:

    Actually, that means that Ruby is a bucket of bolts…

  4. Eric Danker says:

    Ryan wrote a bit about his Squeak impl at his blog: http://www.objectcommando.com/blog/

  5. Khalil says:

    You guys seem to have way too much fun, big thanks upfront for sharing it through video!

  6. Well, I love Scala but Im dubious about this implementation

    VendingMachine is a stateful mutable object. Not concurrency-friendly, but certainly a defensible choice given the that real-world machines are stateful too.

    But why add in the java util concurrent stuff to a design that uses a mutable, stateful backing object? That API seems like it wont work in concurrent scenario, and adds what…?