Practical? Common Lisp on the JVM: A quick intro to ABCL for modern web apps | Hacker News Reader

Practical? Common Lisp on the JVM: A quick intro to ABCL for modern web apps

notes.eatonphil.com

69 pointseatonphil15 comments

This is interesting from a "look what we can do!" perspective, but practically speaking, there's not a good reason for doing it this way. It would be better all around to use one of the "native" Common Lisp libraries, such as Caveman: http://8arrow.org/caveman/

Even as a big Common Lisp fan, I would really question using it in a situation where the project has strict requirements to use a particular framework for another language.

JVM and CLR has the long tail of libraries that just doesn't exist for smaller languages. What happens when you want to integrate with Parquet files or some common but sort-of-obscure proprietary system like ClickHouse? I've done a bunch of FFI integrations with C libraries and I never enjoy it. You always have to make sure you're handling object lifetimes correctly and you just don't have that issue if you're able to use Java or CLR as your FFI target.

For small apps where you know you'll never have to leave the native ecosystem it can be fine to stay outside of JVM/CLR. But for business apps I think there's a lot of security to be had by being able to integrate with JVM/CLR.

Edit: I'm not saying it's a good idea to choose ABCL, I hope this article made that clear. SBCL is much more mature in most dimensions.

I feel like the "boring" part of the web app (setup, configuration, routing, etc.) could benefit from using a more strictly typed language like kotlin, and https://jooby.io/ explicitely supports it.

Once you have the skeleton, I can see how lisp and ABCL could be used to implement some interesting business logic or even template rendering. So kind of like using lisp a callable scripting language as opposed to doing everything in lisp that is a bit more tedious imho.

On further thought, what I meant to say was that in this specific example, I don't think it makes sense to use these particular libraries from Common Lisp because there are native CL libraries for doing basically the same thing.

On the other hand, I completely agree that it's useful to run a CL application on ABCL to access Java libraries that don't exist for CL.

EDIT: On a side note, I just noticed the abcl.org link immediately under "Picking a language, libraries" is pointing to "https://notes.eatonphil.com/abcl.org"

Fixed the link, thanks!

The point to me about blog posts like this are as a guide for others trying to do _anything_ with the same language.

The docs on how to use the Java FFI were pretty hard to read. I figured it out by grepping through the ABCL source code for a while and finding a single other project that also brought in 3rd-party deps.

On whether or not you should actually use Netty/some Java server rather than Caveman I have no opinion.

Why not just use Clojure? It has good frameworks for web programming, you can even use it for browser apps, etc. There are of course differences, but from my point of view the code will be less ugly.

P.S. I programmed in CL, and in Scheme (even commercial software), but for JVM-based stuff, Clojure is my language of choice

I have nothing against it but I'm not sure it needs any additional press. :)

My goal wasn't "use the JVM at all cost", more so "show these languages we know but benefiting from a mature ecosystem".

Seconded, if you're going to use the JVM, that is. Lisp on the JVM is a solved problem.

ABCL became available in 2005[+], about two years before the appearance of Clojure, and both continue to be developed/maintained to the present.

[+] https://abcl.org/svn/tags/0.00.10/j/README

I have used it, also as Kawa. from my point of view, the Clojure interface to JVM is more "natural". Plus the concurrency support, etc.

Lots of folks don't see Clojure as a Lisp.

How do they define a lisp that clojure doesn't qualify?

A Lisp runs Lisp code, code that could have been written anywhere from 50 years ago to today. The extent and degree of modifications required before that code runs, illustrates how far away one is from Lisp.

All Lisps (incl Scheme, Common Lisp, Emacs Lisp) sit fairly close together in this historical "Lisp" space. I can get Lisp code from the CMU AI repository and run it as is or with slight modifications in any of the aforementioned Lisps, but Clojure would require a complete rewrite, both syntax and logic/semantics. Ergo, I and lots of others don't see Clojure as a Lisp. I'd call it Lisp-inspired or a descendant of Lisp, but it's clear that it is a different language.

People still use Scheme and Common Lisp. That, to me, is a sign that details matters for people who use Lisp, and thus Clojure might not be what they like.

I find the construct using template files inelegant compared how to the PicoLisp system does it. Since the AST is already in memory and an interpreter running on it has access to in memory variables why not use that? You can in addition abstract over certain patterns and put them into functions.

Reference: https://software-lab.de/doc/app.html

Reply on news.ycombinator.com