>> Common Lisp applications are hard to deploy.

>No server or desktop or web-browser comes with common lisp pre-installed. Building common lisp is a pain, because packaging/ASDF is terrible and you don't easily get a nice and small statically linked executable out either. Compared to exactly what language is common lisp not hard to deploy?

I'm not here to defend all of the flaws in CL, but I really enjoy the SBCL feature that allows you to compile to a binary. Yes it may not be as small as a pure C/C++/Rust executable, but it's very useful and I've used in various projects with great success.

My heart still goes out to Python but I was I could just as easily create a Python executable as I can with SBCL.

Yeah, I agree save-lisp-and-die is cool. On the other hand you can just write a python script, copy it over and have it run on literally millions on computers out of the box (even accounting for the python3 debacle) – that's pretty handy, too.

Isn't Common Lisp's save-lisp-and-die roughly analogous Pyinstaller? I mean they both work but nobody seems to be using them. In my experience Common Lisp code is most commonly deployed with an interpreter.

Most Common Lisp is actually compiled, not interpreted.

If one compiles code or loads compiled code to something like SBCL and dumps an image, you can both run it directly from that image AND have still have the development tools included.

Some Common Lisp implementations also have delivery tools which create applications without development tools. Some applications though include the development tools, because they are thought to be extended by the user. For example a CL-based CAD system might exposed Common Lisp as the scripting language for CAD extensions.

Of course many implementations do compile to machine code but there are also a few that don't (clisp, ecl, abcl). It is really complicated to talk about languages that have multiple implementations. That is why I went with "interpreter". That was pretty lazy of me :).

But you didn't say anything about the original question. Have you seen Common Lisp code deployed as an executable or as source code?

Interpreted in Lisp usually means 'executing s-expressions by a Lisp interpreter'.

ECL and CLISP also use compilers. ECL usually compiles to C, which then is compiled to native code via a C compiler. CLISP has its own virtual machine, which is the target of its compiler. Don't know what ABCL does, would have to look it up - but in the end it usually would execute JVM code, which gets compiled by its JIT compiler.

Question of code deployment. I have seen deployment as an executable, deployment as an executable with also loads compiled code (for patches) and deployment as source code. Especially commercial applications and/or end-user applications tend to deploy as executable. For example ScoreCloud is a LispWorks application as an executable and can be bought on Apple's Mac app store.

My Lisp Machine at home boots into a Lisp image which contains a whole operating system as compiled Lisp code. That's exotic, but many other Lisp development environments already come as compiled Lisp executable. For example on the Mac and on ARM64/Linux I use LispWorks. On the Mac it is the usual Mac application bundle, where the executable already contains much of the IDE and then loads some code on demand from compile code files.

> ScoreCloud is a LispWorks application as an executable and can be bought on Apple's Mac app store.

Wow, super impressive. You didn't post this on reddit yet :)

The word "compiler" is so overloaded that every time someone mentions one it turns into an argument. This is the whole transpiler vs compiler vs interpreter vs JIT argument. The trouble is that sometimes some programmers implement all of them (myself included).

> CLISP has its own virtual machine, which is the target of its compiler

Then CPython is also a compiler? and Lua?

Yes, generally any source to byte-code translator is a compiler. The byte-code then can either be interpreted or compiled, too. Since the default CPython implementation interpreted the byte code, it was said it's an interpreter - but strictly speaking it is not.

Originally interpreters were implementations which execute source code - which in Lisp is widely available. For example SBCL for a long time only had a native code AOT compiler, but now also includes s-expressions.

Famous is also the Lisp interpreter in Lisp from McCarthy, where he defined the core language in itself. See the paper from Paul Graham about that: http://languagelog.ldc.upenn.edu/myl/llog/jmc.pdf That's a very primitive Lisp interpreter - many real ones are implemented in C, Assembler...

Just be aware, that in the Lisp world 'Interpreter' means something very specific: an interpreter of the source language.

Fair enough. My assumption was that you would consider a source to bytecode compiler an interpreter (to be fair most people do). The next time I say something about Common Lisp I will list all the implementations instead of saying something as simplistic as "compiler" or "interpreter".

It's also complicated because some implementations support several modes. ECL for example has a Lisp interpreter, a byte-code compiler&interpreter and a native compilation via C. All code variants can work together and call each other.

To be clear, ABCL (if I understand correctly) compiles to JVM bytecode, which is analogous to "machine code" in the context of its target platform (and hell, is sometimes even literally machine code if you lack any semblance of sanity: https://en.wikipedia.org/wiki/Java_processor).

And ECL does ultimately compile down to machine code if you include "compile the resulting C output" in the compilation process, though this is optional.

The binary dump feature is used by projects like StumpWM, Lem and Next.

Heliohost or Platform.sh come with CL pre-installed (https://github.com/CodyReichert/awesome-cl#deployment).

In my experience, deploying a CL app is muuuch less a pain than a Python one: you build a self-contained binary, you run it and voilà, you can access your web app from the internetz. The binary is ±20MB in size (compiler, debugger and all included). With Python, there are so many ways to fail (and even because a dependency of a library didn't pin its dependencies well enough. Gosh.).

Building a self-contained app is 1 line in the .asd project declaration.

https://lispcookbook.github.io/cl-cookbook/scripting.html#bu...

web development: kind of agree, but that didn't prevent me and two other colleagues to build a commercial website last year, for 1,5 month. It receives tens of thousands of visits a month and has a small admin panel for a three persons team. Job done, rent paid

CLI utils: it's simple to use cl-readline. There are a couple libraries for ncurses. The Lem editor is a good example.

mobile: nope. For the adventurous, see https://gitlab.com/eql/EQL5-Android and its REPL.

GUI: https://github.com/CodyReichert/awesome-cl#gui Qt4, Gtk3, IUP, Tk, Nuklear have good bindings. Qt5 is possible with gobject-introspection (for the adventurous). Proprietary: CAPI. Electron: Ceramic. Java GUI interop with ABCL?

ML: https://github.com/CodyReichert/awesome-cl#machine-learning MGL's author won the Higgs Boson Machine Learning Challenge, but yeah.

for the rest: IDK https://lisp-lang.org/success/

CLI utils: you're missing the point. Of course you can write some simple terminal apps with common lisp, but can you name a single one that anyone who is not a lisp fanatic uses? If not, ever wonder why?

GUI: would you develop a commercial app (to pay your rent) in any of these apart from CAPI?

ML: You are joking, right?

I can name one :) pgloader https://tapoueh.org/blog/2014/05/why-is-pgloader-so-much-fas...

I'd use Electron with Ceramic, not the GUI bindings. Or maybe Nuklear. But I would build personal projects with them.

ML: yeah, yeah. Just to show there have been work on it, that (of course) the platform is capable.

Yup, pgloader was also the one example I could think off; I was wondering if you'd name it :) Amusingly I have not been able to get the non-docker version to work due to some bogus openssl problem.

Anyway, I completely agree that Common Lisp is capable, my point also isn't that it's impossible to do things like GUIs, or write something cool and successful with it – just that the eco-system is not general-purpose language quality. If you want to make something that's successful commercially or as a well-adopted open-source project you have to be much more careful what problems you tackle than with a genuinely general purpose language.

Blog posts that claim otherwise really rub me the wrong way; I think it's possible to present CL in a favorable light without distorting reality and no one is gonna thank you later for joining the rank of people who missed out career-wise for making non-viable technology choices.

> not general-purpose language quality.

= not top-notch in all areas? Yeah, there's room for improvement. Buuut, given CL's features and stability, I will very much consider it for a commercial project in the future instead of, say, Python. I'd reject Python, for sure, for GUIs or web dev (except a small website maybe where admins would use the Django admin). Now I must find another language, and it's difficult. Many things drive me back to CL, including its state of libraries, actually pretty good compared to other languages, newer or older. No kidding.

> If you want to make something that's successful commercially or as a well-adopted open-source project

maybe. Reading you, it seems one should avoid using CL altogether. But there's a lot of room for a successful use of CL before falling into these categories: one-off scripts, quick GUIs at work, personal tools? Commercial websites (with adequate requirements), like I did? yes, it's possible to use CL for that. Yes, it is possible to do web development for a job with CL (what kind of sites? We have to ask the few redditors that do it). My point is that CL is general-purpose enough so that it could be more used in the wild (because it is used in the wild).

Anyways. Just trying to be positive :)

> Buuut, given CL's features and stability, I will very much consider it for a commercial project in the future instead of, say, Python[...]My point is that CL is general-purpose enough so that it could be more used in the wild

Yeah, I'm not arguing against that at all. I just hate articles which encourage people towards doomed efforts rather than building out existing areas of strengths or address things that are real obstacles towards using them. I'd like CL to be around for at least long enough till all it's important ideas have made it into other programming languages ;)

For example, one core strength of CL is that it's the about the only really interactive/malleable/live language that can generate pretty performant code, and for sbcl you can hook deeply into the machine code generation as well. Luajit is nicer in some ways (e.g. much smaller footprint in every possible way) but CL has a much more sophisticated interactive development experience (restarts, powerful debugging, pretty-printing etc. etc.). So tooling for automation of binary rewriting, refactoring and hardening like GrammarTech seems to be working on (see https://github.com/GrammaTech?utf8=&q=&type=&language=common...) seems like a much more promising area to work on with common lisp to me than e.g. generic web development.

addendum: for iOS, Android and mac: possible MOCL (proprietary) https://github.com/CodyReichert/awesome-cl#implementations

Thanks for the list! :)

> Common Lisp has no eco-system to speak of for machine learning,

https://www.cliki.net/Machine%20Learning

> web development,

https://www.cliki.net/Web

https://en.wikipedia.org/wiki/Viaweb

https://en.wikipedia.org/wiki/Reddit#Technology_and_design (though it admittedly got rewritten into Python)

> command-line utilities,

https://github.com/TeMPOraL/hju, among, like, hundreds of other examples

> games programming,

https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp

https://github.com/shirakumo/trial

http://xelf.me/

https://borodust.org/projects/trivial-gamekit/getting-starte...

> mobile development,

https://wukix.com/mocl

http://kriyative.github.io/2011/03/26/ecl-for-ios-updated/

https://common-lisp.net/project/ecl/posts/Lisp-ECL-and-QML-Q...

> GUI programming,

https://common-lisp.net/project/mcclim/

https://www.cliki.net/GUI

> embedded development

https://cliki.net/embedded

http://www.ulisp.com/ (not technically Common Lisp per se AFAICT, but seems to have very similar semantics)

> Building common lisp is a pain, because packaging/ASDF is terrible and you don't easily get a nice and small statically linked executable out either.

https://www.xach.com/lisp/buildapp/

http://www.sbcl.org/manual/#index-save_002dlisp_002dand_002d...

https://ccl.clozure.com/manual/chapter4.9.html

If you think spamming random links to old toy/dead/in-house projects you found on Cliki and that contained words like "machine learning", "Games" or "GUI" (mcclim – really?[]) constructs an effective rebuttal to "no ecosystem to speak of", I'm not sure I know what to say. But I'll go through your list in more detail if you want me to.

[] For the record CLIM had interesting ideas, but last I looked, calling McCLIM's implementation of them a toy would be charitable.

The claim was "no eco-system to speak of". There is clearly an ecosystem to speak of. It might not be a healthy ecosystem, and we might speak of it poorly, but it exists nonetheless, and in fact exists in a greater capacity across that whole range of categories than what a lot of other "popular" languages can claim.

"Machine learning" is a perfect example of how out-of-touch that claim is considering that Lisp was the language for AI research until very very recently.

> mcclim – really?

I guess you didn't see the link right below it with the dozens of other bindings to other popular GUI toolkits.