My guess it's a proportionally low number. I looked into matlisp when I did my PhD in scientific computing - none of the other people I worked with had any interest in it. I couldn't pursue it since I would have to reimplement or interface each and every library myself, a workload I couldn't justify at the time.

So, although lisp might have been great, in the end I stayed with Python/C++. Guess I'm not the only one with similar experiences.

You'd be surprised by how much less elegant CL is, right off the bat.

Thankfully, however, one can tweak it in so astonishing a way - I still miss parameterized types though - that once you realize the nature of your problem, and put in lots of due work, things tend to become easy in the long run; I particularly adore being able to write iterate macros (adding new "for" clauses").

That said, Matlisp is still in a stage of infancy ("research grade"), and while I welcome contributions, it should be noted that it is not yet a replacement for R/Numpy/MATLAB, atleast not for the casual user.

I work in a research lab and we never touch anything like Lisp.

What we use: C/C++, Matlab, Python, R, Fortran, and the occasional Mathematica. I myself have been getting into Julia.

My favorite E&M simulator is MEEP, http://ab-initio.mit.edu/wiki/index.php/Meep.

Although written in C++, it uses MIT-Scheme/guile as the control language. This is a problem because the steep learning curve discourages undergraduate students.

I wrote an old (and verbose) blog [1] about why I think Lisp is very suitable for heavy science – in my case Operations Research. In fact, the algorithm powering routific.com is written in it.

The key point is that if you were to map out different languages along the abstraction level, Lisp sits right in between the realms of low-level programming (e.g. Java) and modelling (e.g. Matlab). [2]

EDIT: added link to the image of languages along the axis of abstraction level

[1] https://kuomarc.wordpress.com/2012/03/05/the-uncommon-lisp-a...

[2] https://kuomarc.files.wordpress.com/2012/03/level-of-or-appr...

In all my time working in scientific computing and talking with others, I only know of one case.

The huge amount of libraries for Python, C, C++, and Fortran make them the obvious choice.

Plus functional programming paradigms aren't always the best to do scientific programming. It can be done, but it's really not the right tool for the job, in most cases.

I guess you can count Yann LeCun, Leon Bottou and Richard Sutton among those. And those are the ones I can think of off the top of my head. Regarding the first two, see also my comment about Lush in this thread.

rcl (invoke R inside lisp), cl-num-utils, cl-mathstats, cl-variates, cl-randist, antik...