I use CLOG these days; it's all so easy to get things done.
re: common lisp shines at low-level tasks like microcontroller programming
While I couldn't find an explicit declaration of this in the linked article, the tunnel system likely has something on the level of an SBC (think raspberry pi) rather than a microcontroller. Common Lisp makes it possible to do fun low-level assembly stuff but AFAIK none of the implementations can run on a microcontroller.
There's uLisp, which builds on Arduino's libraries but it isn't a Common Lisp implementation.
In terms of bare-metal CL implementations there is Movitz (stopped development) and Mezzano, but I don't think those can run on any microcontrollers.
There are also some libraries to convert CL to C, thinlisp and CLiCC, but these aren't actively maintained currently.
The possibility of porting Clozure CL to the RP2040 was discussed in the ccl mailing list last year, but I don't think anyone's working on it.
Thanks for the article! It's good to have more examples of this sort of stuff, especially if people decide to go the lack/clack route rather than using e.g. hunchentoot directly as I like to do. If you ever do a followup to go beyond the simple barebones, I'd like to see more on both development experience and production deployment. Some thoughts:
Better attention to error handling, as well as the difference in developer mode where you might want the error to show up in your REPL and/or shown on a page, but in production mode to just be logged and/or emailed somewhere while the server returns an appropriate error page without too much information on it.
>In a more complex application, I would add a way to invalidate the cache automatically if a template changes.
By default, Djula actually recompiles the template if the file does change. What the cache here is doing is caching the association of a path string -> template file object, not the compilation status, as the template object can recompile itself.
You have a lot of top-level forms (path / asdf references, add-template-directory, etc.) that don't fly if you wanted to compile a binary to push up to a server.
Speaking of deploying to a server via binary, it's also easy to compile in an active or toggle-able swank server, so that if you do need to debug or want to develop/test things further "in production", the server doesn't need to know anything about Lisp or Lisp editors, you just use SSH port forwarding on the swank connection and talk to the production Lisp binary with your local editor. (The server does need to have a matching or newer libc than your build system though, and potentially other things like libmysqlclient. I just build stuff in an old debian docker image but Shinmera's Deploy is a great solution with a lot of headaches taken care of.)
I like the @export macro when developing because I can be a bit lazier, but it's better form to just add the stuff to your defpackage :export list eventually. (I finally got around to making my own editor macro in vim to do that for me, so I don't think I'll use the cl-annot package much anymore.) That library is also LLGPL which might not be desirable for the trivial handful of lines of code you can write yourself if you don't need its slightly fancier support for class accessors.
With sqlite, you should probably be using PRAGMA journal_mode=WAL when you create the schema, as well as consider changing its auto vacuuming behavior and a few other features. There are some per-connection pragmas worth looking at as well for a production scenario.
Showing how to send headers like content security policy would be good, and also going beyond simple error pages to including support for live metrics (e.g. https://github.com/deadtrickster/prometheus.cl -- there might be a clack middleware even?)
I wrap my Lisp web stuff in apache but I think nginx and caddy are popular too. Showing the full end-to-end with a let's encrypt SSL cert would be helpful for people getting into web apps who haven't already done it in some other ecosystem before.
false premises, false conclusions, and bad good ideas in-between.
> I was surprised by the absence of a quickstart page to help me set up a simple server
what about https://lispcookbook.github.io/cl-cookbook/web.html ?
Also I think that the READMEs of Mito (ORM) and Djula (templating) and easy-routes (routing) are very good. Heck, Djula's documentation is excellent. Double heck, even Caveman's README, which the author uses, has a good and sufficient getting-started page.
Oh, I understand, the author uses Clack/Lack… where Hunchentoot is much better documented.
there are of course more blog posts, some videos. I invite any blogger to consolidate community resources.
More recent: https://web-apps-in-lisp.github.io/
ps:
> ;; If the template is not already compiled, it is compiled, and stored in TEMPLATE-REGISTRY.
won't that prevent the template to compile changes? I suggest to follow Djula's doc.
> I would add a way to invalidate the cache automatically if a template changes.
yeah. So don't do that ;)
(also +1 to Jach's remarks and explanations)
> I created a macro that ensure the table gets created correctly
hummm… I'd suggest to leave the migration step explicit.
> some database helpers to perform a few CRUD actions on the db.
I felt the need for CRUD helpers too when defining Mito classes. However those four ones are only similar functions with same parameters but another name :]
(defun db-add (instance)
"Inserts a model instance into the database."
(insert-dao instance))
> I would say that there are better languages for developing modern web apps.Burn this article with fire ;)
You don't need to need extraordinary clever needs to use CL. You benefit about it during development, deployment, and the application lifecycle.
time-saving error handling? You can use it 100x times a day. https://www.youtube.com/watch?v=jBBS4FeY7XM
simple "scripts", data-munging applications for B2B? You can do it easily in CL, and save yourself sanity during development, deployment, etc. https://lisp-journey.gitlab.io/blog/running-my-4th-lisp-scri...
One caveat: have some experience with the language.
> since hot reloading has already been implemented in all high-level languages
nope you can't compare hot reloading with image-based development.
Please just don't compare anything or induce "better languages for modern web apps" with Python…
> shout-out to Alive which is the only Common Lisp extension for VSCode that implements the REPL with features similar to what SLIME and SLY bring to Emacs.
please don't forget SLIMA for Atom/Pulsar which has even more features than Alive, or the Sublime one, or Vim, or the Intellij one, or… https://lispcookbook.github.io/cl-cookbook/editor-support.ht...
Man that seems like an awful lot of ceremony for a trivial web app. Surely the language known for macros and building your own DSLs has a more concise way to get a web app up and running?