After two failed attempts, I finally made it to the Boston Lisp meeting on Tuesday. I enjoyed the two talks.
ACL2 is a theorem-proving system, and people have used Emacs to drive it for many years. To help people learn ACL2 without learning Emacs at the same time, Peter Dillinger worked on ACL2s, an Eclipse-based interface to ACL2. In his slides he compared the original Emacs interface to a racecar: fast, highly effective in the hands of experienced users, and unforgiving of errors. ACL2s is designed to be easier to learn and more forgiving, like a family sedan.
This reminds me of Cusp, though the original Emacs interface for ACL2 seems more primitive than SLIME. Most of the questions were about with the capabilities of ACL2 rather than the ACL2s interface. I was more interested in how easy it is to extend ACL2s than what was involved in proving theorems. Does it involve writing more Java, or more Lisp? Or something else? I didn't ask Peter about it, though.
Part of the Q&A drew a laugh:
Q: Why not add these advanced features to the Emacs ACL2 interface?
A: Well...um...Eclipse is designed to be extensible, for programming stuff...
Wag: Just say Eclipse can do multiple threads!
A: Multiple threads! ACL2s is using four threads in this demo!
Hans's talk about the BKNR data store was interesting. It's a simple, tested, documented system for object persistence. It was created to avoid the need to install, maintain, and tune a relational database system, and figure out some way to map relational tables to Lisp objects; instead, it's standard Common Lisp all the way down.
The design decisions have worked out well for Hans's applications:
- Use the MOP for transparent persistence of instances
- All objects are kept in memory
- Persistence is via a transaction log
- Only one writer may be active at a time
Hans was clear that this is not the perfect solution for all purposes. This setup can fit the needs of many applications, though. Hans demonstrated a website with over 400,000 objects; it took up about 50 megabytes on disk and about triple that in memory. Initializing the objects at startup took a minute or two, but, as Hans noted, "Lisp hackers are used to not restarting very often."
The timing for his talk was good for me. A few weeks ago I extended AutoMotivator to have a user and poster management system, and I wrote a simple persistence system from scratch. Although it was fun to make and was an educational first use of the MOP, challenges of storage, querying, and schema evolution have already cropped up. BKNR has the advantage of being small, mature, documented, and tested by real-world projects with hundreds of thousands of objects. I'd like to switch from my home-grown system to BKNR's storage system soon.
After the talks ITA provided pizza and Indian food, and I got to meet several Lisp hackers in person that I had only spoken with online. We wound up chatting for hours about various topics.
Though several people I know online were there, there wasn't much in the way of introductions and nobody wore much identifying material, e.g, name tags. A few people identified me by my Save Lisp and Die shirt, but I was a little too shy to go around asking people who they were.
Even though I didn't get home until 2AM Wednesday, I'd like to go to the next meeting on May 27th. You should go too!