Note: the following post may include controversial opinions, so please note that they are only my opinions, and not intended to offend anyone.

I'm being programming in some form or the other since around 1999. I initially used R, and then later, around 2004, mostly switched to Python.

For many scientific applications, for example, simulation, including such things as MCMC, both R and Python are too slow and need to be sped up. The usual way of doing so is by extending with C or C++. For both R and Python, this is what I did, using R's C API with C++, and the Boost Python library with Python.

However, for various reasons, this combination is not the ideal solution. What is important in programming, particularly algorithms? Expressiveness and speed, which are of course related. The more expressive a language, the faster one can write in it.

1) As far as expressiveness goes, neither R nor Python are really ideal for writing scientific algorithms in my opinion. They do not closely map to the underlying algorithm. However, they are both considerably better than C++.

2) I enjoy writing in Python, which is a pleasant language, though as noted above it is not ideal for algorithmic work. However, when one has to work with a Python/C++ combination because of speed issues, this mix becomes considerably less pleasant to work with. What usually happens is that I first write in Python, and once I have something that is working well, often discover that it is too slow (for some subjective value of too slow). I then face the decision of whether to spend some unreasonable amount of time rewriting it in C++, or put up with the slowness. In hindsight I often feel I might have been better off putting up with the slowness, especially as the speedups obtained are unpredictable. Also, the Boost Python interface between the two is a significant maintenance headache, and having code in two very different languages glued together like this is just distracting. No criticism of Boost Python intended, it is as powerful an interface as one could imagine, and pretty much just works most of the time.

Now, in an ideal world, with unlimited time and resources, neither of these problems would be a major deal. However, in scientific projects I have worked on, I've had the following experience.

Whether or not I have collaborators on the project, I always seem to wind up doing the vast majority of the computing. In a total of 5 significant projects, I only had substantial participation from one people on one project. That one person did more than pull his weight; he did as much as me or more. However, in all other cases, including projects with multiple collaborators, I've done (virtually) all the computational work. While I can say that I have not been blessed with the best collaborators (it seems to be a mixture of laziness and incompetence) it is not clear to me whether this state of affairs is likely to change in the future.

Computational scientific work is an enormous amount of effort, and if I can't change how my collaborators behave, I can change the way I work. The most important improvement would be to get things done more quickly. Which brings me to the main consideration here, which is that switching languages to something less orthodox may help. Based on past research, the most likely candidates in order of likelihood are Common Lisp and Ocaml. I've been thinking about this for years, but recently have been thinking about it more seriously.

As far I can tell, few people use either CL or Ocaml for scientific computation. On searching this site, I found two references to CL (one was mine) and one to Ocaml (mine). I've had a couple of encouraging contacts over the years with adventurous people working on the fringe. In 2008 I came across a book review of Peter Seibel's "Practical Common Lisp" (which I own), by Tamas K. Papp. This caught my attention, since it was one of the few mentions of scientific computing for Lisp that I had come across on the net. I wrote to Tamas, who immediately replied helpfully and encouragingly. To quote him

My programming productivity probably increased tenfold with Lisp, but that took about a year to happen and I am still learning (I was doing quite well after 2 months though). So if you are working on something time-critical, then postpone the switch.

You should consider asking folks on c.l.l, I am not the only one who knows about these things, others do scientific computing on Lisp.

He also has a blog and a GitHub page.

Another person I briefly corresponded with (in December 2006) was Ira Kalet, who has used Common Lisp in the context of radiation oncology.

Perhaps there are others who do scientific computing on Lisp, but I don't know of anyone.

The most common problem people cite with CL is the lack of libraries. This is a severe problem in general purpose computing, but may not be so much so in scientific computing, particularly from the ground up implementations of algorithms. Specifically, I can get by most of the time with a basic math library, including probability distribution functions, a multidimensional array library, and a basic set of containers e.g. map, set, list etc. as found in the C++ and Python standard libraries.

I know even less about Ocaml than I do about CL, but threw that in as an alternative. It is supposedly very fast, has one free implementation by French researchers, and seems like the most viable of the ML family of languages for scientific computing.

To conclude, I'm wondering if others have experience with this, and what thoughts they have, if any.

EDIT: I'm mostly interested in first hand experience, in the context of the issues I've discussed above. E.g. if you used to use Python and C++ (or R and C++) and moved to a more obscure language, I'd be most interested in hearing about your experiences.

  • 2
    $\begingroup$ Stack exchange is for asking questions, not for posting life stories! Your question seems to be "Are there any scientific computing projects using Common Lisp or OCaml", right? $\endgroup$
    – khinsen
    Feb 27, 2012 at 16:36
  • 4
    $\begingroup$ Agreed, this reads a little bit more like a blog post, but I do like the premise. Any chance you could try and reduce this to 2-3 paragraphs? $\endgroup$ Feb 27, 2012 at 17:37
  • 1
    $\begingroup$ Also agreed. Commentary and personal experience is good when it supports the main question; too much detail can swamp out the main points. If you can condense your question, I think it'd be easier to read and it would get more targeted, higher quality responses. $\endgroup$ Feb 27, 2012 at 18:33
  • 1
    $\begingroup$ @FaheemMitha: In the "ideal world" you mention mid-way through it would be all hand-optimized assembly... Sounds dismal to me! $\endgroup$
    – meawoppl
    Feb 27, 2012 at 20:16
  • 3
    $\begingroup$ @FaheemMitha: The best thing I think you could do to improve your question is to make the question you're asking clear. It seems like you're telling a story about your experiences (which is all right), and then at the end, you bury the question as a statement at the end of your story. ("To conclude, I'm wondering...") The best thing you can do is to make that part a question, so people skimming your question can readily identify what you're asking. I had to go back a couple times to figure it out. $\endgroup$ Feb 27, 2012 at 22:02

3 Answers 3


We developed Julia for exactly the reasons raised. There was just no good high level scientific computing language that also gave good enough performance, that you didn't have to keep rewriting parts of your code in C/Fortran. The design of julia has a fair bit of lisp influence, so you may find it to your liking, while your collaborators can just treat it like a matlab or R if they don't care about the functional parts. The downside is that the language is new, and does not yet have all the libraries one would need for day-to-day usage.

Mark, would love to add julia to your benchmark to see how we fare. Do hop on over to our mailing list and let us know what you'd like to see in julia so that it is more useful to you.

  • $\begingroup$ That looks beautiful! I will definitely check this out for my own work. Currently I use python for all my work in theoretical condensed matter, just because the time gained by having fast C++ code is negated by the time spent writing in C++ in the first place :) $\endgroup$
    – Lagerbaer
    Feb 29, 2012 at 4:06

The speed, size and dependability of programming languages does a really good job of wrapping up a lot of different concerns expressed in your "question." It compares the speed and codebase size of a bunch of implementations of the same benchmarks across 33 languages!

I have become a Python lover mainly because it is much more common to have excess computing time than excess time to program. I am more than willing to squander CPU cycles than sacrifice a wedge of time that could be devoted to something more interesting.

Also, +1 on Julia. I think I may switch to it when it becomes a bit more stable and widely supported i.e. when standard modules are wrapped for the work I like doing.


For scientific applications of OCaml, see for example

For Lisp in science, see for example

I am sure there are many more references. However, I cannot cite any major research project in which computational work was done in either OCaml or Lisp. Choosing either one means working in relative isolation.

You may also be interested in Julia, a new language for scientific computing currently under development, with clear Lisp influences.

  • 1
    $\begingroup$ I should perhaps have made it more clear that I'm mostly interested in first hand experience. I'll edit my question to reflect this. $\endgroup$ Feb 27, 2012 at 16:58

Not the answer you're looking for? Browse other questions tagged or ask your own question.