Comment by vindarel | Hacker News Reader

Comment by vindarel | Hacker News Reader

Parent Full thread

CL is very general purpose. Where it shines IMO is: the development experience (interactive, good compile-time type warnings with SBCL), the stability, the delivery of applications (compile to a self-contained binary), the overall feature set.

I use it for web back-ends and little scripts. Everything's stable, my Sentry dashboard is empty. [edit: sorry, just had a stupid production error in my Python app] Some friends love Elixir and do great things with it, but I'm in your reverse situation: I don't have enough incentives to switch. Elixir's REPL is good but it's only a REPL, not an image-based experience. Its Emacs modes are rudimentary. Phoenix looks great, but it's very opinionated (and very much code-generator oriented, strange). I can't copy-paste a binary to my servers (or other users). The Torch admin dashboard looks cool, but I just made my own in a week-end (and again, I'm afraid by code generation). LiveView looks awesome but it's its own little world and I might approach it with HTMX and HTMX websockets.

TLDR; I can do both web apps and CLI tools with CL and switching must be worth it too.

  and again, I'm afraid by code generation

Do you use macro and higher order function? If you do, you already use code generation, so why are you afraid ?

Because macros in common lisp are very easy to grok, which is not to say that common lisp programmers promote willy-nilly use of macros

Unlike Scheme, CL macro are glorified template based code generator. If your not careful to use facilities like gensym and packages it easy to accidentally capture already binded terms at call site.

If we look at macros in Scheme R7RS they are mostly transformers on patterns. -> https://standards.scheme.org/corrected-r7rs/r7rs-Z-H-6.html#...

> If your not careful to use facilities like gensym and packages it easy to accidentally capture already binded terms at call site.

Luckily CL programmers have heard about that and are usually careful about that.

I mean code generation that writes code to files. I'm afraid they bit rot fast and make upgrading harder. Macros generate code on the fly, not in my source files.

I tend to regard code generation as being something that should -feel- like a macro to use, just one that optionally materialises the results so you can ship the code without a dependency on the generation logic.

I am very conscious that most code generation in the wild is ... Not That.

Thank you! I read some time ago that compilation to binaries is not really a solved problem. Also the ecosystem was very lean. At the same time you need to include a dependency for everything because the standard library is also lean.

You’re mostly right about Elixir but Phoenix is not opinionated, at all. It’s code-generation oriented only if you want to use the generators. I don’t use them.

ack, thanks. I still want to see what I'm missing, so I'll keep trying.

Compilation to binaries works fine. A SBCL binary will weight ±35MB (compressed, 120MB uncompressed). This includes everything (compiler, debugger etc). A bigger app with dozens of deps doesn't grow too fast, like ±40MB for a web app. I think that's in the ballparks of a growing Go app. LispWorks allows to shrink the binary size to ±4MB (but then you can't connect to it remotely and live reload the running image). Start-up times are very fast.

A SBCL binary relies on GLIBC. There was a patch for truly static binaries, needs more care (https://www.timmons.dev/posts/static-executables-with-sbcl-v...)

It's true you need to choose and include a dependency for common tasks: HTTP client, JSON and CSV… As for "lean", well, it depends. See awesome-cl. CL's ecosystem is richer for some tasks than other emerging and trendy languages, poorer in some areas. Interfacing with Java or Python is possible (ABCL and LispWorks, py4cl2).

ANSI Common Lisp was criticized when it came out for having a bloated standard library and feature set.

It’s not extensive like python, but it’s not C.

In fact, some of the presently annoying warts can be derived from late decisions on the theme of "we already have a bloated standard, let's not add more".

Over time a lot of them became de facto extensions (MOP, gray streams), or there are de facto extensions that fill the same niches in different way (ASDF)

Reply on news.ycombinator.com