Clasp: Common Lisp Using LLVM and C++ for Molecular Metaprogramming [video] | Hacker News Reader

Clasp: Common Lisp Using LLVM and C++ for Molecular Metaprogramming [video]

youtube.com

137 pointslispm21 comments

Christian Schafmeister and Robert Strandh (creator of work-in-progress SICL, which Christian now uses in Clasp), both took on the multi-year project of creating a new CL implementation; Robert completely from scratch, Christian leveraging the high-level parts of an existing implementation, while completely rewriting the low-level ones.

I have a lot of respect for these guys; I had a few new ideas for ways of implementing Common Lisp, but decided not to when I realized with the amount of free-time I have, it would be about a decade of work.

I've spoken to Robert online, and he mentioned that a lot of people told him a from-scratch implementation was doomed to fail. The only reason those people were wrong was in that they underestimated his tenacity.

Hi, I'm Christian Schafmeister. Thank you so much for the nice comments! I just want to point out that this work was all done with your tax dollars. This work was made possible by support from the National Institute of Health (NIGMS), the National Science Foundation (NSF) and the Defense Threat Reduction Agency (DOD:DTRA).

The speaker also has some more info in his blogpost about the talk: https://drmeister.wordpress.com/2015/06/15/i-gave-a-talk-on-...

For anyone looking for the project: https://github.com/drmeister/clasp

I recently used the author's software (we went to grad school together); software he wrote ~20 years ago that is still useful.

Great talk. Both parts were interesting: tool building and the application of designing molecules.

Super interesting.

If you read the Feynman speech that he references at the beginning, he actually mentions that as you scale machines down, things like mechanical rigidity will degrade and you will need to change your design rules accordingly. I always assumed that when you reach the molecular level, thermal motion and the constant bombardment by water molecules would mean that the only viable option is to use proteins, just like nature does, so it's very interesting to see that this guy is aiming to use more rigid structures at the molecular level. I guess this is a way to reduce the complexity (degrees of freedom) compared to designing protein tertiary structure. I wonder if this is too constraining though, he admits he has yet to figure out how to build mechanical machines using this approach, and intuitively I'd expect that to be very difficult with this degree of rigidity. You might need the additional flexibility of peptide chains to do many of the interesting things that are possible.

He does point out the advantage of durability, but this raises the obvious issue that one of the questioners alluded to, namely toxicity/pollution risk. I'd think degredation by biological or other means would be a feature, not a bug, since as he points out, even conventional plastics are a huge pollution problem.

Fascinating stuff nonetheless.

Christian Schafmeister here - thanks! You make some very good points that I can address: (1) Things made with "Molecular Lego" still move, but they keep their shape just enough to organize atoms/groups to do things like speed up reactions and bind other molecules. We've explored dynamics in several of our papers. They aren't too constrained - they are constrained "just enough"; and we can build in flexibility and hinges where ever we want. (2) We don't know how to make mechanical molecular machines with them yet; we need to start making a lot of them and explore their properties to figure that out. The first folks who smelted iron didn't know how to build motors with it - it took a lot of people playing around with iron for a long time to figure that out. I think we can get there in less time but it will take work. (3) Re: toxicity/pollution - this is the first non-natural molecular technology that contains the solution to any problems that it generates. We need to learn how to make catalysts well and then we can build catalysts that break these molecules down. Conceivably, we could build materials that contain the catalysts that break them down and are activated by an external signal. Or we make materials out of bigger bricks (built from Molecular Lego) and we fish them out of the environment, tear them apart from each other, check them for defects and build new materials with the good ones and recycle the broken ones. We can also build catalysts that break down every other indestructable material that we've been dumping into the environment for 100 years. Regarding toxicity, these molecules are made out of carbon, nitrogen, oxygen and hydrogen - the same atoms you are made out of. They are inherently non-toxic (there are qualifiers on this).

Hi Christian, great to have you replying directly like this; I hope my criticism came across as constructive, since I'm super excited about and impressed with this work, as someone also chasing the dream of molecular nanotechnology.

Re: rigidity; I'm curious (apologies for not having read your papers) how you define "just enough" flexibility, and how your design tools take freely moving components into account. Would you agree with my intuitive feeling that there's a tradeoff between designability and functionality, and that your spiroligomer work sits between rationally designed protein structures (very hard problem) and Drexlerian molecular-scale gears and ratchets (similar, determinsitic design rules as in macroscopic systems)? Or, do you feel that anything protein "machines" can do, spiroligomer machines can do too?

I recently started a startup that has molecular nanotechnology as the end goal, and my thinking has been that the flexibility of proteins is an essential element in achieving the capability to design and manufacture with atomic precision, and that the concomitant complexity of the large numbers of degrees of freedom can be tamed with a data-driven approach leveraging machine learning algorithms. I'd love to hear if you have any thoughts on this, and how it relates to the spiroligomer approach.

This was the best tech talk I have seen for a long time. Thanks for sharing it.

This is one of the most fascinating talks I've seen in a while. Thanks lispm.

This is the best presentation I have seen in years.

Macros are truly the way up if we are to escape the gravity well of calculus for bio chemistry. How else to gain delta v?

Thanks again, Christian.

How does one person manage to be so productive?

Focus, dedication, specialization, experience, and superior choice of technology.

Outsource to libs. Look at the list of dependencies given on the github project's page:

https://github.com/drmeister/clasp

Do any of this from scratch and your productivity will plummet:

LLVM for compiling; Boehm for garbage collection; GMP for bignums; Readline for interactivity; C++11 for ... cough ... oh will you look at the time---lesson is over for today, grasshoppers!

Your point stands, but one nit-pick:

The Boehm GC is only so it doesn't run out of RAM while bootstrapping, it uses the Ravenbrook MPS precise garbage collector once it's bootstrapped.

Also note that Christian reported that Ravenbrook was very responsive when he discovered a few deficiencies in the MPS library.

Also he used clang to walk his C++ code to automatically generate information in order to enable precise GC of C++ objects.

Christian Schafmeister here with a shoutout to the Ravenbrook people who are awesome and very helpful. They have excellent documentation: https://www.ravenbrook.com/project/mps. I don't own stock or anything but now that I'm using MPS I'd like more people to know about it. If you are interested in developing a more generalized version of the static analyzer that I wrote to automate GC for C/C++/Objective-C - get in touch with me.

Cool, but if that makes things so straightforward, where's your performant Common Lisp implementation? (Where's mine?)

I did watch the lecture, I do know how many libraries he used...

Fascinating, fascinating talk.

brilliant

Reply on news.ycombinator.com