49 lines
5.2 KiB
Org Mode
49 lines
5.2 KiB
Org Mode
:PROPERTIES:
|
|
:CREATED: [2026-05-24 Sun]
|
|
:ID: f4e5d6c7-b8a9-0c1d-2e3f-4a5b6c7d8e9f
|
|
:END:
|
|
#+title: Christian Schafmeister — Common Lisp in Computational Nanotechnology
|
|
#+filetags: :ideas:lisp:nanotechnology:
|
|
|
|
Christian Schafmeister is a chemistry professor at Temple University in Philadelphia. He created [[https://github.com/clasp-developers/clasp][Clasp]], a Common Lisp implementation that interoperates with C++ libraries using LLVM compilation, specifically to solve a problem most Lisp implementers never face: designing molecules at the nanoscale.
|
|
|
|
**The problem.**
|
|
|
|
Schafmeister's research focuses on spiroligomers — large, shape-programmable molecules built from synthetic monomers. These are programmable at the level of both shape and functional groups, meaning they can be designed to bind specific proteins as therapeutics or accelerate chemical reactions the way enzymes do. The goal is to create molecules that can do everything proteins do in nature, but that are designable and evolvable by human beings.
|
|
|
|
This is a computational problem of enormous complexity. Designing these molecules requires simulating their behavior, computing binding affinities, searching conformational space, and iterating designs rapidly based on experimental feedback. The compute pipelines involved typically live in the C++ ecosystem (a vast array of scientific computing libraries), but the workflow itself — rapid prototyping, interactive exploration, incremental development — demands the kind of environment that C++ alone cannot provide.
|
|
|
|
**Why Lisp won.**
|
|
|
|
Schafmeister's argument for Common Lisp in computational nanotechnology mirrors the same reasoning that drives Passepartout's architecture:
|
|
|
|
- **Interactivity.** Molecular design requires exploration. A researcher needs to load data, inspect it, try a transformation, undo it, try another — all within a live environment. Lisp's REPL-driven development provides this in a way that compile-link-run cycles cannot match.
|
|
- **Incremental development.** The design space for spiroligomers is too large to simulate exhaustively. You need to build up models piece by piece, testing each step. Lisp's incremental compilation and hot-reloading make this natural.
|
|
- **Unified representation.** In Lisp, the code that describes a molecule and the code that simulates it share the same structure. There is no translation barrier between the design language and the simulation language.
|
|
|
|
But the scientific computing ecosystem lives in C++. Schafmeister could not afford to rebuild every computational chemistry library from scratch. So he built Clasp: a Common Lisp implementation that compiles to native code via LLVM and interoperates seamlessly with C++. Clasp can call any C++ library natively, and C++ can call back into Lisp. The result is that the entire scientific computing ecosystem becomes available from within a Lisp environment — programmable, interactive, introspectable.
|
|
|
|
**The architecture.**
|
|
|
|
Clasp is not a wrapper or a bridge. It is a full Common Lisp implementation where the C++ interoperation is part of the language runtime itself. The clbind library provides declarative bindings — you describe how C++ classes and functions map to Lisp, and Clasp generates the glue code automatically. This is fundamentally different from CFFI-style foreign function interfaces, which require manual marshaling and are inherently fragile.
|
|
|
|
From the Lisp perspective, a C++ class appears as a CLOS class. You can subclass it, specialize methods on it, inspect its instances. The boundary between Lisp and C++ is transparent to the programmer.
|
|
|
|
**Funding and validation.**
|
|
|
|
Clasp has been funded by the Defense Threat Reduction Agency (DTRA), the National Institutes of Health (NIGMS), and the National Science Foundation. These are agencies that fund computational chemistry and materials design, not programming language research. They funded Clasp because it solved a real problem in molecular design that no other approach addressed: making C++-scale scientific computing work within an interactive Lisp environment.
|
|
|
|
**Relevance to Passepartout.**
|
|
|
|
Schafmeister's work is existence proof for two of Passepartout's core claims:
|
|
|
|
1. Lisp is not a niche language for academic AI research or Emacs configuration. It is being used today to design therapeutic molecules that bind proteins, in environments funded by the NIH and NSF. The interactivity and homoiconicity that Passepartout relies on are the same properties that make this work possible.
|
|
|
|
2. The single-address-space model is not a limitation but an enabling constraint. Clasp proves that you can run C++ libraries inside a Lisp image, not alongside it. The "Lisp machine" is not a retro fantasy — it is a practical architecture being used today for computationally demanding scientific work.
|
|
|
|
The main difference is direction: Schafmeister brought C++ into Lisp to access the scientific computing ecosystem. Passepartout replaces the C++ scientific computing ecosystem with verified Lisp-native alternatives. The architectural principle — one representation, one address space, no translation boundaries — is the same in both cases.
|
|
|
|
---
|
|
|
|
- [[id:1c3ec48b-446c-50d2-b53e-126a81f5143f][Passepartout Architecture]] — why Lisp is the choice for verified infrastructure
|