Lisp Hackers: Juan José García Ripoll

Juan José García Ripoll is a physicist and the principal developer of Embeddable Common Lisp (ECL), an implementation that compiles to C instead of native code and provides a shared library, so that Lisp programs can be distributed without the Lisp runtime and be embedded in other programs. He also actively contributes to the improvement of ASDF, the foundational system definition facility (one of his posts on the topic).




Juanjo is a representative of a large group of Lisp users - researchers and scientists, who are not professional programmers. Although Lisp is not generally considered on par with specialized research environments, like Matlab or R, it is quite useful in this field, because of its solid mathematical foundation, coupled with truly interactive and robust environment.

Tell us something interesting about yourself.

I do not consider myself to be an interesting character or have interesting hobbies, but my job is quite interesting and unconventional: I work on Quantum Computation, developing new ways of computing using, for instance, superconducting circuits, or arrays of atoms. Actually I find that the fact that human technology has progressed to the point that we can trap and harness individual atoms is pretty cool.

What's your job? Tell us about your organization.

I am a physicist and work as a scientist for CSIC, the Spanish Research Council. It is the largest research institution in Spain and my group works on all kind of exotic things related to the implementation of quantum computers.

Do you use Lisp at work? If yes, how you've made it happen? If not, why?

From my description above it might seem that it would be hard to use Lisp for anything, but quite the contrary: 50% of our time is spent doing simulations and programming. Quite interestingly, the programs that we develop are very short-lived. We have a question, write a simulation, get the data, move on. This is the reason why most people in our field use Matlab. I reached Lisp looking for an interactive programming language that was more powerful than Matlab in the fields of expressiveness, extensibility, optimization. That is how I started working on ECL, with the aim of empowering it for numerical simulations. Along the way I got distracted and more interested on the fields of language development.

Despite this I have found room for Lisp in my daily routine, from scripting all the way up to solving actual problems. For instance, in one of our research topics we had to solve huge instances of 3-SAT problems using a very basic algorithm. The fact that Common Lisp comes with bignums reduced the development time to one afternoon and the program we produced was faster than the C++ prototypes we had.

Among software projects you've participated in what's your favorite?

My favorite is ECL, but my second favorite was developing for an extinct operating system, OS/2. Back when I was at the university, OS/2 was still alive and I got some interesting projects finished, such as an X-Windows server and the port of Doom to it. It was pretty cool to learn multithreading and GUI development back then and OS/2 was pretty well thought out.

What brought you to Lisp? What holds you?

My job brought me to it, and what keeps me is the possibility of learning a lot about language implementations, compilers and making a tool that is useful for a larger community, including other projects such as Sage. It is a weak link though, and sometimes personal interactions make me question whether this is useful at all.

What's the most exciting use of Lisp you had?

ECL. Really. After one year of development it was awesome to see ECL being able to build and compile itself from scratch for the first time. Also, every time I finish yet another feature, it feels really good. And finally, developing a Common Lisp implementation is a great excuse to learn a lot of things, from the subtleties of the POSIX specification, to the Unicode collation algorithms.

What you dislike the most about Lisp?

The unspecified corners. Multithreading was not in the specification and implementations have evolved in somewhat random ways, with some common denominator and features (process-kill) which are not really well suited for existing operating systems and are nightmare to implement. I also miss a better specification of physical pathnames.

Describe your workflow, give some productivity tips to fellow programmers

Sorry, I am a terribly disorganized developer and ECL users suffer from it. No advice here, hehe.

You are a physicist by main occupation, yet you manage to almost single-handedly support ECL. Why? and How?

Everybody needs some projects in life other than work and this one is a lifelong companion that I would like to see to the end. I had a lot of help from freelance programmers at the beginning and users cooperate with patches and bug reports, and a lot of patience for my mistakes and absences. That helps.

That does not mean I consider the current status an optimal one. I consider it a personal failure the fact that ECL does not have a larger community and a better support base. It still persists the wrong impression that ECL is a lesser implementation, covering a niche (embeddability) and inferior to other implementations which are more lispy in nature. That is not the case: we have sufficiently proven that the underlying core, C, does not prevent any feature from being implemented, performance is improving and stability, well, this is not always optimal, but it has to be blamed to the small size of the developer team, which has scarce resources for testing the code.

submit