Perfect Storm

One of the most delightful things in bioinformatics is the possibility of working with people with really different mindsets. Surely CS geeks are amazing, and everyday I feel that my original background is really a comparative advantage, but, from where I look, nothing beats being in an environment with scientific and cultural diversity. But, lets talk some geekiness now:

A couple of years ago, I did a population genetics simulator in Caml. It was really flexible, allowing for many demographic and genomic scenarios, mating rules, selection… really flexible. I never got to try to publish it because there are many good simulators around (I suggest simuPOP, if you are looking for one) and it would take some time to make it robust and documented for public exposure. But, the interesting part is, when I went to my MSc supervisor (an “old-type” biologist) and after a very exuberant explanation on how flexible the simulator was, he added only one comment: That is all very well and good, but you did not show me the easy to use graphical interface!

Fast forward a couple of years… With regards to a DSL to model drug resistance in the context of infectious diseases that I am developing, I went to my PhD advisor (a population geneticist, malarialogist, biostatistician who knows how to program in C), showed him my rough prototype and he said: People will be able to read this, but, to interact they will want an easy to use graphical user interface. To be honest, this time, I was expecting the comment (I am living in the middle of experimentalists long enough to have learned something). I have no expectations, for my DSL, that domain specialists will write it (well, maybe a couple of them will, if things pick up). If I end up giving my system away to domain specialists, it will have to have a easy to use interface, there is no escaping from that.

Well, DSLs (at least in Scala and in Ruby) have an underlying OO model. Which, most of the times is neither complex nor big. I am starting to suspect that it won’t be too difficult to automatically generate an easy to use interface to input in a “nice” way what could be rendered as DSL programs (or object instances and relationships, if you prefer to look at it that way). For embedded DSLs, which have the whole expressive power of the host language available, that would be unfeasible to do completely. But, at least part of it could be automated. Obviously this idea is not new at all, this is just a rehash of what Lift or Rails do for databases.

I am aware that graphical programming languages never went too far (I actually dislike them), but the scope and context here are completely different, different premises apply. This might be one way of lowering the barrier to rigorous modeling to a wider crowd.

Through my whole career I was torn between what I like (Prolog and Caml) and what makes me marketable (Java, VB, Perl, C, Python, C#). Of course, the world is not black and white so, in the list of marketable languages there are some that more likeable to me than others.

Java is acceptable, but is too verbose and the libraries are grossly over engineered (with no apparent advantage), of course a DSL framework is nowhere to be seen. Python is also acceptable, but the lack of DSLs (and Guido explicitly stating that he is not going in that direction in Python 3000) makes it loose a lot of its sex appeal, also, less importantly, I have some bias towards strong typing.

Enter Ruby: DSLish, very pragmatic, a vibrant community, a fantastic JVM implementation, and one can $$$ on it… I am giving it a try.

Regarding platforms, a less important issue for me, I am quite happy working on top of the JVM: multi platform, stable, industry support, really open…

One of the many interesting features in Caml is strong typing that might be explicit or implicit, i.e., type declaration is optional (it is always inferred).

One (dumb) example, list reversal, which already exists in the core libs (and we will use it):

let invert lst =
  List.rev lst
;;

Which Caml infers it is of type

val invert : 'a list -> 'a list = <fun>

(i.e., a function which takes a list and returns a list of the same type).

Let us now imagine that we want our own invert to support only lists of integers, we do:

let invert (lst : int list) =
  List.rev lst
;;

Caml infers:

val invert : int list -> int list = <fun>

One can be “lazy” when coding (i.e., not explicitly declaring types) a la scripting languages, but when going through the debugging hell that sometimes can happen with weak typing (in the Caml case it is really inference of a more general type than the correct one, or because of a wrong call, a wrong inference), explicitly type and force the offending code to show up.

Of course, one should try to be consistent and maintain the same style over all code, but I sometimes find my code to use both implicit and explicit conventions. This is due to laziness coupled to the fact that probably nobody will read me Caml code .