Clasp: Common Lisp using LLVM and C++ for Molecular Metaprogramming

The most inspiring talk a I have ever seen: Clasp: Common Lisp using LLVM and C++ for Molecular Metaprogramming. ABSTRACT This talk describes our unique approach to constructing large, atomically precise molecules (called "Molecular Lego" or "spiroligomers") that could act as new therapeutics, new catalysts (molecules that make new chemical reactions happen faster) and ultimately to construct atomically precise molecular devices. Then I describe Clasp and CANDO, a new implementation of the powerful language Common Lisp. Clasp is a Common Lisp compiler that uses LLVM to generate fast machine code and it interoperates with C++. CANDO is a molecular design tool that uses Clasp as its programming language. Together I believe that these are the hardware (molecules) and the software (the CANDO/Clasp compiler) that will enable the development of sophisticated molecular nanotechnology. [this video]

If you're asking yourself what kinds of problems is a Lisp good for you should probably watch this: [this video] (A computational chemist built himself his own Common Lisp implementation because no other language available was powerful enough for his needs...) It basically boils to: if you're solving a truly new and interesting problems for which the current libraries and ecosystems don't matter that much to you anyhow (because what you do is too bleeding-edge / ahead of everyone else, so you'll write your own better stuff anyhow), than you might want to choose a Lisp. And if your problem is so bleeding-edge and exotic that you also need to build your own programming-language for it, than you might just as well build yourself a Lisp (like the guy in the video did) and add your needed features to it, because this would be easier than any other approaches and allow you to spend more time on your problem and not on the language... EDIT+: another example is DWave using SBCL: [link] - if quantum (or analog... anyway...) computing is not "truly new and cutting edge", than I don't know what is

CLASP is a really interesting project. For one, it's created and written by a Chemistry PhD researcher (Christian Schafmeister), not someone with a traditional CS background. For another, it's one of the few languages that has ever attempted to interface with C++ at the template level - you can instantiate C++ template classes from CL, and catch C++ exceptions etc. For yet another, he does compacting garbage collection for the C++ objects used in the CL implementation, with pointer patching and everything else. There's a nice Google Tech Talk about it [0], that goes into both why he did this, and how he implemented this. [0] [this video]

" I rarely clip aneurysms now. All the skills that I slowly and painfully acquired to become an aneurysm surgeon have been rendered obsolete by technological change. Although neurosurgery is no longer what it once was, the neurosurgeon’s loss has been the patient’s gain. " so nice to read this many of the entrenched remain so through superstition at the loss of progress, but to read someone speak highly of a practice that rendered a section of their skill set obsolete is heartening i have family who work in trauma and they condescendingly balk at my excitement over new medical technology: [link] [this video] personally, i look forward to bones: [link]

Same here, I never understood Java interfaces, abstract classes, and a ton of other "features" but picking up Clojure was a breeze. I don't understand why complicating thing that supposed to be simple helps you by any mean. On the top of that, I have seen several cases when Java programmers tipped over in their own code because of the complexity that they thought they understand, except there was a particular case when it was doing something else then expected. Reasoning about Clojure (LISP) code is always easy because if you follow best practices you have small functions with very little context to understand. On the top of these, I see the ratio of LOC 50:1 (worst case even higher) for Java : Clojure code that does the same thing. Usually people get triggered and say why does it matter, but in reality less code is better for everybody. Easier to understand, less chance of errors, etc. Correctness was long time lost for majority of Java developers, just put out a survey and you can see it for yourself. It is also pretty common practice not to handle exceptions well and just let a DNS not found error explode as an IOexception and good luck tracking down what caused it (literary happened to me). I understand that the average Java dev does not see any value in LISP (Clojure) but it silly to expect that the average of any group is going to lead the scientific advancement of any field including computer science. One tendency that you can see if you are walking around with open ey

I'd argue that there are essentially two problems in computer science: 1. Math. 2. Dealing with the hardware. Virtually all the ugliness is a product of the interface between these two areas. Dealing with the hardware requires a fascination with minutiae and imperfection, while working in Math requires a fascination with generalities and perfection. The people on the math side create systems like Haskell, which let you express very abstract concepts, and reason very generally about your code, but make dealing with hardware issues difficult. The people on the hardware side use things like Forth, which is very powerful for building code that works closely with the hardware, but whose paradigms actively discourage the generality present in many other languages. And so, what's needed is someone who can develop a system that can fully express high level math concepts in such a way that there is a straightforward mapping to the messy world of hardware capabilities. However, I think the "killing blow" for pure programmers' motivations comes when they realize that mapping between the pure world of math and the messy world of hardware isn't enough. The focus on "end users" is the tacit admission that even if you do successfully build a beautiful system, most people don't want to work at a high level of mathematical abstraction. If you really want to revolutionize computer science, in order to accomplish the actual revolution, your system needs to be able to let people work in the term

Common Lisp traditionally favors other forms of interoperability: with Assembler, C, C++, Objective-C, UNIX/POSIX, etc... For example one prefers to directly call old-fashioned GTK+, Cocoa or Windows - instead of calling via a Java UI layer or a Javascript library. Common Lisp has interoperability with the JVM in various forms (from FFIs to ABCL, a Common Lisp on JVM implementation), but it's not a popular choice. There are several CL implementations with deep C integration, for example by compilation to C. CLASP has deep C++ and LLVM integration. Some implementation can create shared libraries which are being loaded from other programs. CLASP: [this video] It's possible to bring Common Lisp on top of runtimes like the JVM or Javascript - but there is some larger mismatch, because Common Lisp (different from Clojure) a platform independent full programming language. For example Common Lisp specifies a numeric tower with bignums, some float types, complex numbers and rational numbers. JavaScript internally does only offer floats. Common Lisp also specifies its own object system, which does not map well on top of the JVM (single inheritance, non-dynamic) or JavaScript.