Why Common Lisp for Scientific Programming?

What makes any language suitable for scientific computing?

The most important goal is translating ideas into fast code and building on other people’s work. We are working on improving Clasp’s ability to generate fast code based on the excellent LLVM library and Clasp can expose C++/C/Fortran libraries to build on the work of others. I’ve programmed in many languages and Common Lisp is the best at expressing ideas. Every language gets translated into an abstract syntax tree on its way to native code, Lisp code is an abstract syntax tree.  There is no programming concept that can’t be expressed compactly in Lisp, this is not true in other languages.  You cannot yet express multiple dispatch functions, dynamic variables or Common Lisp style macros (a few CL features) compactly in R, Fortran, C++, or Python.

Why are R, Fortran, C++, or Python considered suitable for scientific computing?

It is the wrong question – those languages are just the languages that people started using and so they keep using them.  It is not a choice most people make – it is inertia.

I choose Common Lisp.

Advertisements

14 thoughts on “Why Common Lisp for Scientific Programming?

  1. It should be interesting to interface with R and its libraries written in fortran and C++, like armadillo. Statistics and machine learning are a very useful library for a language. Julia is a big contender here. I should like to know what are the differences in the goal with Julia. Syntax is not a crucial point.

    • I’d like to spend some time interfacing a collection of libraries to Clasp – it would rapidly amplify Clasp’s capabilities without a lot of work. I’ll be doing that in the winter. There has been a trend that more and more scientific libraries are implemented in C++ and C++ is hostile to interoperation with other languages. One goal of Clasp is to lower the barrier to interoperation with C++ and to ultimately eliminate it by having Clasp use the Clang front-end and ASTMatcher library (already exposed in Clasp) to intelligently grovel C++ code to automatically build interfaces. Beyond that the goal is to have Clasp be a scientific programming environment that generates fast code based on an industrial strength language (Common Lisp). I don’t understand why anyone (like the Julia folks) would invent an entire new syntax for programming at this point. New languages have a terrible record of failure over the past decades.

  2. I love R and Lisp. I would love to try Clasp. But for now, it seems that I need to get a linux box. Windows support and prebuilt Clasp are really appreciated.

  3. As a Lisp novice, I am curious why the old FFI implementation is deficient compared to the Clasp & LLVM approach. I don’t know much about the underlying implementation details and their constraints.
    I wonder if you might comment or post on the why’s and wherefore’s of FFI obsolescence, please.

    • Mo,
      The FFI implementations of other Common Lisps are good solutions for interoperating with C. C++ has a lot of additional language features that are not supported by FFI. These features include classes, methods and exceptions. FFI isn’t obsolete because there is plenty of software that depends on it. Part of the Clasp approach uses the C++ compiler to build what are essentially FFI wrappers around C++ function/method calls.

  4. Another question that comes to my mind is if you plan to provide modern concurrency facilities into CLASP. Here, I am thinking of Erlang-like design for massive lightweight concurrency with per process heap for fast GC. This would be a HUGE selling point for many people (like me) to jump into CLASP — in fact, this is in my view the weakest aspect of current CL implementations, so it would be a great win for CLASP. What are your plans in this area?

  5. Common-Lisp and Erlang make dramatically different (and incompatible) trade-offs to provide the guarantees that they do. The really problematic bit is the way that CL allows you to globally re-define at runtime just about everything, but it also turns out that Erlang can’t meet its guarantees with regards to supervision trees when the platform uses native code generation.

    If you want lisp syntax for the Erlang platform you can try Lisp Flavored Erlang (http://lfe.io/)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s