Saturday, October 8, 2011
Talk about developing commercial software in Haskell
Yesterday, I gave a talk at the Haskell in Leizpig workshop about our experience in developing commercial software in Haskell. You can find the slides (in german) here. I was really surprised by the large number of attendees (about 50), given that the workshop's language was german (except the very interesting talk by Kevin Hammond).
Subscribe to:
Post Comments (Atom)
7 comments:
Any English version out there?
Unfortunately, there is no english version. The workshop was in german, so I wrote a set of slides in german. Sorry! Maybe I'll give a similar talk in english some day...
Interesting! You've had a lot of the same problems we've had at Silk (http://silkapp.com): laziness, performance monitoring, cabal-install/libraries.
We're running our own hackage based on hackage-server (hackage2), which is just a cabal install away. This has worked out very well. Have you tried this?
As far as laziness is concerned, we've found that a lot of problems go away if you use strict data structures for data stored across requests (i.e. stored in a TVar), and strict operations on TVars.
Regarding monitoring: have you tried Threadscope? We haven't yet, but I've heard good things about it.
Oh, and we've just joined the Industrial Haskell Group (IHG, http://industry.haskell.org/). The group aims to improve tools like cabal install and Threadscope given input from their members. They are looking for more associate members, and you seem to be a good candidate. Have you thought about joining?
Hi Erik,
yes, we are also using our own hackage repository. It's basically only a directory structure served by apache and a couple of scripts for importing packages from hackage.haskell.org
Strict datastructures and operations on TVars are good, as long as the operations evaluated inside STM aren't too expensive. Otherwise, transactions run too long and the risk of retries gets higher. For such cases, we use the pattern described in the code example on slide 10.
Threadscope looks good, but it's an offline tool, right? Andres Löh mentioned that they are thinking about adding support for switching event logging on and off at runtime. That would be really cool, but there are still many things beyond the scope of threadscope we would like to monitor.
Hi Stefan,
So your hackage is just a subset of hackage? We also have our own internal packages there, so having a 'real' hackage available to upload (and hopefully generate docs some day) is valuable.
Interesting note about the expensive computations. I missed that part in my first (quick) read of the slides.
And yes, ThreadScope is offline, as far as I know.
...what is meant by "Automatische Korrektheit"?
Hi "hvr",
Stefan probably means that we very often had the experience that code that compiles is also correct very often because the type system catches most of the stupid programming errors and makes you think about what you really want.
Post a Comment