zachbeane

Common Lisp at its base is usually written in Common Lisp.

The class and instance evolution protocols for starters seem not all that easy.

If you mean the C compiled code, that's what a typical sbcl binary is already. On my system it's around 2.5MB. The compiled CL code image (and its related data) is around 50MB. save-lisp-and-die sticks the image into the runtime binary.

Also, some context from comp.lang.lisp is available at https://www.xach.com/naggum/articles/3250122499743574%40nagg...

Sweden had a similar idea. https://www.atlasobscura.com/places/visingso-oak-forest

It extends to Topsfield. At the intersection of Route 1 and Route 6 there's a model of Eris.

The Mark Zuckerberg profile is promoted heavily on "who to follow"-type interstitials. It also shows up when friends like or share things it posts. Blocking would be a simple way to avoid seeing those things, if it worked.

My video appeal is here: https://vimeo.com/194845103

I hope to improve the documentation and security of Quicklisp in the next few months. It will depend on funding.

The core of Quicklisp is in dist.lisp. Understanding the protocol of the generic functions at the start of that file will help clarify Quicklisp as a whole. Almost everything else Quicklisp does is in support of that protocol.

This is a not a good guide. Avoid Graham too.

PCL is much better. Keene too. Seek out Joe Marshall's Warp Speed intro too.

Postmodern is good. It works only on Postgres. It is fast, easy, and stable.

Elephant has been unmaintained for many years. I wouldn't recommend it.

Yes, unfortunately that's the case.

There are a handful of commands described on http://www.quicklisp.org/ but there is no end-to-end, comprehensive user or developer manual.

GNU CLISP does not get any resources, human or otherwise, from the GNU project. If Sam stops working on CLISP, he's not going to start working on GNU Emacs or gdb instead.

This is true in the same sense that the GIMP is the "GNU Image Manipulation Program". It's just a label, and a license choice, without much real meaning behind it. GCL is also called "GNU Common Lisp".

CMUCL is not popular any more.

SBCL is popular, and so is Clozure CL.

Starting from classes and describing generic functions as a way to send messages is pretty backwards for CLOS.

CLOS is best used primarily by defining a protocol with generic functions, then using methods and (optionally) classes to implement the protocol.

http://xach.com/lisp/jrm-clos-guide.html has a copy of Joe Marshall's "Warp Speed" CLOS guide.

Yes, with more than a trivial amount of work. When the syntax is more lisp-congruent, you don't have to jump through as many hoops.

Certain things are still hardwired into the Common Lisp reader. For example, because of how colons are treated in symbols, you can't trivially support something like JSON via reader macros. It still works best if the input bears a pretty good resemblance to lisp.

That's not such a big deal, because there are plenty of tools for conventional input parsing in Common Lisp.

I think anyone who wants to be able to stick with a system as they grow, get supportive help from an active user base, reuse the work of others in the form of useful libraries, and not worry about the viability and future of their development environment should use something like LispWorks, Allegro CL, Clozure CL, or SBCL. LispWorks and Allegro CL are just as easy to install and use on Windows as Corman Lisp.

Cool!

It would be interesting to see how far it gets on the ANSI test suite from http://www.cliki.net/GCL%20ANSI%20Test%20Suite

It might have been at some point in the past, but it doesn't run on modern systems, does not fully implement Common Lisp, and can't run much of the useful software written in the past 10 or so years.

It's still pretty cool, but not as a learning tool in 2015.

I think it's pretty unlikely that this will be made to work in a modern environment in a useful way. I think the primary benefit will be historical interest and possibly the reuse of some of the component parts.

http://lispblog.xach.com/post/107215169193/corman-lisp-sourc... has some more context. I'd have posted it myself directly, but xach.com is blacklisted from HN.

Meta: this company scraped my contact & project info from github and spammed me multiple times to add me to their stable of experts. It felt incredibly slimy.

I'm sure they're very excited about reaching the HN front page.

The code hasn't been released in five years. There have been a bunch of security fixes since then, and likely many other changes as well.

Reminds me a bit of a thrift shop book I picked up a while ago, "The Coming Exploration of Space" by Lester del Rey from 1959.

https://www.flickr.com/photos/xach/sets/72157601657100517/

If you want to compile it, you need a Common Lisp implementation. SBCL, CLISP, and Clozure CL can usually do it, though SBCL is the most reliable and well-tested.

There are binary versions available for download, too. They've been precompiled with an existing CL compiler.

It's true that you can't open a random REPL and change the features of another process.

It is the norm for a webapp in Common Lisp to have an accessible REPL or "remote console".

> running code in a REPL won't fix your web app since it's a separate process

Not in a Common Lisp web app.

http://pages.umpi.edu/~nmms/solar/ is another version of this idea.

https://groups.google.com/forum/#!topic/comp.lang.lisp/HQFMh... has some discussion between the author and others from 2009 regarding Clojure and Common Lisp.

I suspect it's more a lack of resources (time, energy, interest) than maturity. CLISP has bugs. Some bugs are fixed in version control. It would be nice to have a new release.