Re: [Haskell-cafe] [ANN] Laborantin: experimentation framework

Hi Tom, Thanks for the pointers. It is interesting to see that Braincurry and Laborantin have similar designs although we come from very different application domains. You've picked paths that I was not sure to explore (e.g., have experiment parameters be a parameterizable datatype rather than a value in a pre-defined datatype). I didn't think about enabling algebraic composition of "experiments". It looks like I can incorporate this idea in Laborantin too as a way to "combine" setup/run/teardown hooks. I'll definitely have a second look at Braincurry but first I'll have to read the 2nd paper. One thing I really would like to support is a way to "inject experiments" into another system and run experiments "live". For instance, A/B testing web pages in a Warp application. BayesHive looks very nice! congrats. Enjoy a nice year 2014 and best wishes, --Lucas 2013/12/30 Tom Nielsen

Hi Lucas,

In connection with your work on Laborantin, you may be interested in our papers:

Braincurry: A domain-specific language for integrative neuroscience

http://www2.le.ac.uk/departments/biology/research/neuroscience/matheson-neur...

A formal mathematical framework for physiological observations, experiments and analyses. http://rsif.royalsocietypublishing.org/content/9/70/1040.long

I found it difficult to excite experimental biologists about the benefit of adopting experiment description languages. I am now concentrating on a functional language for statistical data analysis - see https://bayeshive.com

Tom

On 23 December 2013 09:27, lucas di cioccio wrote:

...

Dear all,

I am happy to announce Laborantin. Laborantin is a Haskell library and DSL for running and analyzing controlled experiments.

Repository: https://github.com/lucasdicioccio/laborantin-hs Hackage page: http://hackage.haskell.org/package/laborantin-hs

Laborantin's opinion is that running proper experiments is a non-trivial and often overlooked problem. Therefore, we should provide good tools to assist experimenters. The hope is that, with Laborantin, experimenters will spend more time on their core problem while racing through the menial tasks of editing scripts because one data point is missing in a plot. At the same time, Laborantin is also an effort within the broad open-science movement. Indeed, Laborantin's DSL separates boilerplate from the actual experiment implementation. Thus, Laborantin could reduce the friction for code and data-reuse.

One family of experiments that fit well Laborantin are benchmarks with tedious setup and teardown procedures (for instance starting, configuring, and stopping remote machines). Analyses that require measurements from a variety of data points in a multi-dimensional parameter space also fall in the scope of Laborantin.

When using Laborantin, the experimenter:

* Can express experimental scenarios using a readable and familiar DSL. This feature, albeit subjective, was confirmed by non-Haskeller colleagues. * Saves time on boilerplate such as writing command-line parsers or encoding dependencies between experiments and analysis results in a Makefile. * Benefits from auto-documentation and result introspection features when one comes back to a project, possibly months or weeks later. * Harnesses the power of Haskell type-system to catch common errors at compile time

If you had to read one story to understand the pain points that Laborantin tries to address, it should be Section 5 of "Strategies for Sound Internet Measurement" (V. Paxson, IMC 2004).

I'd be glad to take question and comments (or, even better, code reviews and pull requests).

Kind regards, --Lucas DiCioccio (@lucasdicioccio on GitHub/Twitter)

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe