On Wed, Mar 9, 2011 at 17:18, Simon Peyton-Jones
could you contribute a little vignette or story about using Haskell in a *parallel/concurrent* application that I could use to illustrate my talk?
Combinatorrent is a BitTorrent client written in Haskell, based upon the same ideas as Etorrent, a BitTorrent client written in Haskell. Combinatorrent uses an aggressive forkIO-style on top of STM Transactional channels for communication. The client implements the official protocol and several extensions in far fewer lines than contemporary clients, usually a factor of 4-5 in souce code lines. Four advantages present in Haskell (There is some overlap with Erlang here): * Spawning a new lightweight thread is extremely cheap. It encourages a coding style where you just spawn another process to do work for you rather than a style where you try, emphasis try, to harness a few OS threads. * Immutability and Persistence of the data plays a big role in getting the program simple. You can just send off a large data structure to another thread without having to worry that the other thread destructively destroys invariants. This in effect yields an effective way to use persistence to give quick caching of data in other threads, fast responsibility handover and so on. * Protocol parsing is a special case of an Applicative Functor. This yields protocol parsers that reads like specifications in RFCs, and still they run extremely fast. * We do configuration of BitTorrent extensions by having each extension be an element in a Monoid and then use function composition as the monoid-operation to chain together extensions at hook-points. This yields a very simple and very effective way to dynamically configure each peer we communicate with with the peers supported extensions. It also decouples the extension-code neatly from the main code. All in all, I was quite happy with using Haskell, even though I am currently more focusing on my Erlang client. I have read code in C++, C and Java clients, and it is scary how much work they have to do in order to achieve just part of the work. (Performance could be better, but this is GHC612 without the new IO-manager measurements - and I expect it to have deep impact). -- J.