Wow,

Having the code in Matlab seems like a disaster as far as ever making this or similar approaches modular and so usable-by-others goes. And I do know by miserable experience that Matlab indeed what biologists generally use but if biology is ever going to interface with larger scale software construction, it seems like it is going to have to change it's standard operations a bit.

Edit: And this isn't saying Matlab is generically "horrible". It is great at what it does but horrible from my perspective, as a programmer whose task usually is putting pieces of software together.

Agreed. MATLAB its set of downsides. On the plus side development is rapid and since 2008 it has good support for classes. We're starting to move toward python for future work.

I think MATLAB itself isn't so bad, so much as the way its typically used -- poorly commented, organized, and untested. We put a lot of effort into clearly commenting and organizing the code. We used matlab-xunit and hudson to manage testing, which worked quite well. http://www.mathworks.com/matlabcentral/fileexchange/22846-ma..., http://www.mathworks.com/matlabcentral/fileexchange/33971-xm....

  > We're starting to move toward python for future work.

Thanks a lot for commenting. As somebody who does a lot of scientific coding in Python and part-time contributor to a couple of projects, I'm of course curious -- what's your reasoning behind the move and where do you anticipate to see the most friction?

A variety of reasons really. In no particular order: - Still has good math support, rapid development - Better OOP support - More libraries -- everything from web development to scientific computing to GUIs to databasing - More reliable, less buggy - Better development tools -- code completion, testing, coverage, profiling, etc - Free. Therefore can more easily be run on clusters without licensing issues or using the MATLAB MCR

I don't see any friction, except if one needed to port old code. It seems that a lot of people are moving toward SciPy/NumPy these days.

  > the code in Matlab seems like a disaster as far as ever
  > making this or similar approaches modular and so usable-
  > by-others goes.

As always, it depends. I've seen very well maintained MATLAB code bases, and I've seen the opposite (with the latter greatly outweighing the former). We should give these guys the benefit of the doubt. Somewhere Karr mentions Hudson CI, so they don't seem fully removed from good practices. Interfacing with MATLAB from C is reasonable.

In an ideal world, this would be a NumPy/SciPy prestige project, but neither the community nor Python for that matter are quite there yet.

The thing is that Matlab is problematic for further extension even if the basic code is well done simply because of Matlab's weird function composition architecture and other weirdnesses.

Consider that if biological simulations are going to go to a larger scale, you won't want to simply call a bunch of Matlab simulations from a single C program but rather have a bunch of distinct programs that would be modified to call each other (with each of these programs running as they do now in their Matlab instance).

I'm confused. In what way is Python not there? If one specifies, e.g. Python 2.7, what do you consider to be the short-comings?

I'd also like to know how you think numpy/scipy are short compared to Matlab. I've not run into their limitations yet.

I think the main thing is libraries. I was looking for graphical model software that supported DBNs once, and could only find Matlab ones. There was a python wrapper for one of the Matlab libraries but was not widely supported.

I don't know much about biology or Matlab, but this seems to be a common refrain.

    *XXXXXists make huge breakthrough on YYYYY*

    "I can't believe they used programming language Z!"

Domain specialists generally have more market leverage than the random programmer geek that scoffs at their "primitive" tools, and the code they write is there to do a job, not satisfy the peculiar preferences of a specialist in some other domain (like programming).

Now, when programmers work to make domain specialists' job easier, that gets some attention; thus the tidal levels of interest in MDA, DSLs, and so on.

Absolutely agreed. If you're doing large-scale simulation, you need explicit parallel computing. You need C/C++. MPI, ScaLAPACK, the whole shebang. 128 nodes is great, but I suspect the simulation will run orders of magnitude faster if written in C/C++.

All of the source code is available at http://simtk.org/home/wholecell. http://wholecell.stanford.edu provides a searchable interface to our training set database.