During our May meeting, John Fremlin, the author of teepeedee2 which was recently slashdotted for being the world’s fastest web framework, discussed our beloved Garbage Collection. What was great about John’s presentation was that he discussed alternate ways to efficiently working around GC, and in the end improving the overall performance of your application.
John wrote, summarizing his talk:
Basically here’s a summary of my provocation (yes, I’m not entirely against GC but I think too many people overlook the alternatives):
At April’s TSAC meeting we watched an interesting video titled “Camel Trading”, Experiences with Functional Programming on Wall Street by Yaron Minsky. I’m not going to go into great detail about the video, I encourage you to watch it, but nearing the end of his presentation he mentioned some problems Jane Street has with OCaml, which I found interesting. They are:
Every year, the International Conference on Functional Programming sponsors a Programming Contest, which is basically a week-end of serious hacking in an attempt to prove how cool (or not) you are. (Actually, sometimes I think it’s more about the contest organizers trying to prove how cool they are–and succeeding.)
Last year, Starling and TSAC got together with a bunch of people, put together a team, and had a go at it. It was very, very enjoyable.
Well, I disagree with Bryan’s previous post post that the parsing was a “simple problem.” But I’ve finally implemented a Haskell solution, and have done quite the writeup about it (more than three times the length of the solution itself!).
Of course, after making sure that it was correct, I had to check its performance. While it’s not as good as I’d hoped (still more than five times slower than the C implementations we looked at), it’s respectable. Here’s the chart again, with my implementation’s peformance figures added:
Our February meeting had one presentation, by Travis, on parsing Roman Numerals. If you are not familiar with roman numerals, details can be found on Wikipedia 1. Luckily it was a simple problem, that kept everyone in the meeting involved.
The presenter, put together a couple versions of a parser, and later he compared the performance between them.
The January 29th meeting was more successful and fun than I’d thought it might be. We had a good turnout (about a dozen), and though there was no official presentation, we spent quite a lot of time with ghci up on the big screen, playing about.
I thought I’d haul out the Haskell programming problem we ask employment candidates to submit when they send in a resume. I’d talked about it earlier, and John had sent me a few different versions already, since I’d offered him some beer in exchange. As it turned out, his friend Adrien had also sent some samples in, but to Bryan’s address instead of mine, so I didn’t see them. The various styles of solving the problem turned out to be rather interesting, from some clever and terse list processing to using a StateT monad transformer on the IO monad. (I still have mixed opinions about that one.)
Those of us that are ACM members have access to a limited number of books from Safari and also a collection from Books24x7. The Safari collection doesn’t have much in the way of functional programming books, but Books24x7 has one of the better introductory Haskell books on-line: Graham Hutton’s Programming in Haskell. If you’ve got a membership, you can access it here.
The December 18th meeting, despite being near Christmas and a week earlier than the usual date, was surprisingly well-attended. We had close to a dozen people show up.
I had said that I would do a presentation on Haskell community resources, but ended up not having time to put that together (simple as you’d think it is) due to being plunged into a Haskell FFI project that I really needed to get finished. It turned out to be one of the more interesting things I’d done in Haskell, and it made interfacing with a Microsoft C API under Windows actually enjoyable, if you can believe that! (It’s an interface into the DDEML API, and we’ll be putting it up on Hackage at some point.)
So, since I’d been immersed in it for a solid week, anwyay, I thought perhaps it would be interesting for an impromptu presentation. It went over quite well, in large part I’m sure because the FFI is incredibly well designed.