Writing Small CLI Programs in Common Lisp
stevelosh.com
stevelosh.com
https://github.com/CodyReichert/awesome-cl/
https://lispcookbook.github.io/cl-cookbook/editor-support.ht... (Atom, Sublime, VSCode, Jupyter…)
https://lisp-lang.org/success/ (and https://github.com/azzamsa/awesome-lisp-companies)
Like, I didn't even consider including "some ugly reader macros" to handle the shebang issue, since my approach has been to comment it out while developing and uncomment once I was ready to use it as a script. But I think this simple macro I put just now in my $HOME/.sbclrc file should suffice:
(set-dispatch-macro-character #\# #\! (lambda (stream subchar arg)
(declare (ignore subchar arg))
(read-line stream nil (values) t)
(values)))
> Life's too short to remember how to write Bash code.
Hard agree.
I used to think that there was "something wrong" with me for finding C++ verbose and C expressively dangerous, or to find myself reaching for multi-line awk, sed, and bash scripts that did _stupid_ things when I "knew" that a better solution existed but I didn't know how to _express_ that solution concisely.
Perhaps a more concrete example would be this: I don't use python often and some of its syntactical quirks get me every time -- like, for example, None as a method to insert a new axis by convention in numpy (so much so that numpy define np.newaxis as an alias to it). It makes total sense but at the same time, the fact that the language likes having what almost looks like a C NULL as a method to insert a dimension seems...wrong, like it should be a syntax error.
I've now just come to realise that hey: if you can't express this concept well in one language, and you _can_ in another, it's well worth prototyping the solution in the right domain and one could always write something in a "sensible" language later if it turns out to work.
The only way I found to learn it that was fun was too write a shell implementation myself. Just POSIX, though so I never learned ksh/bash features.
proc f = discard
import cligen
dispatch f
EDIT: in the last month or two, I have experimented with Babashka (mentioned in this thread) also.
Columns are:
- apparent size (I run FS compression so the actual on-disk size is nearly the same between the compressed and uncompressed)
- Executable name: $IMPLEMENTATION.{big|compress} implementation here is either SBCL or CCL. "Big" means I load the drakma library before saving the image (which pulls in things like unicode tables). "compress" means I attempt to enable image compression; the numbers make it looks my system's CCL does not support compression.
- Mean time to run a program that quits immediately as a startup time proxy; sbcl pays a big penalty for compression as without compression it just MMAPs the image in so doesn't ever load most of the image when you quit immediately.
/bin/true is included for a minimal "fast and tiny C program" as a comparison.
31K /bin/true 85% .0004
43M sbcl 99% .0036
29M ccl 93% .0053
58M sbcl.big 99% .0049
14M sbcl.compress 99% .2012
44M ccl.big 95% .0071
44M ccl.compress 95% .0071The start up time suffers though; on the order of half a second.
Out of curiosity: on what basis?
Janet is definitely a Lisp, although it's not the (Common) Lisp.
The debate continues in the thread. Either way, I think Janet is very useful for situations where you want something lisp like and also want/need small executables. I've experimented with it quite a bit and have found it really useful for putting together cli apps. The sh package is really useful for gluing together other shell programs. https://github.com/andrewchambers/janet-sh
Janet is a nice embeddable Lisp (that is: it belongs to the Lisp family of languages). I've been meaning to play with it, but concluded that the lack of (robust) stdlib would make it hard to use for standalone applications. Was it a problem for you in practice, or is the small stdlib enough for CLI apps?
I mostly stick to using it as a gluing tool for shell scripts for now. So for my purposes it was fine for CLI apps assuming you are gluing together other cli apps. I could have avoided some gluing if Janet had it's own http client. I spent a while trying to dig into some of the packages and to be honest they just aren't there yet. I really wanted to experiment with building a desktop GUI in Janet but I found that it was too much effort to get started. Cljfx (clojure) and racket/gui both work out of the box with minimal effort.
The stdlib is quite enough for basic CLI apps, especially when you use PEGs.
Janet's event loop also makes it very handy for issuing a lot of subprocess calls.
Janet has basic HTTP servers and clients, and there is an effort to shore it up there.
The polymorphic sequence abstraction in Clojure is the definitively modern way to manipulate data structures in a lisp family language nowadays. It retains `first` and `rest` as abstracted `car` and `cdr`, but in return all collections (vectors, lists, sets, and hashtables) work transparently with it.
Some languages that don't have CONS cells: Clojure, Janet, Julia, R.
Of course, that is only one attribute, and may not be the most important one, but it's an interesting separating line.
If you describe each language by a set of language feature attributes, you can perform some easy computations (e.g., Jaccard distance, or some clustering) to get more clue about how related these languages really are. I think Janet wouldn't fare so bad in relation to obvious Lisps, so I'm not strongly opposed to calling it a Lisp.
Erlang and Prolog also use cons cells... Prolog is also homoiconic. I don't think I ever heard anyone calling Prolog a Lisp though.
Also, Clojure has cons cells. '(3 . 4) is a valid expression in Clojure.
Basically, this is an arbitrary, and rather unhelpful, classification. I don't find it interesting, but to each their own, I guess.
user=> (rest '(3 . 4))
(. 4)
user=> (second '(3 . 4))
.
user=> (nth '(3 . 4) 2)
4True, just not a cons cell. It's a persistentList with three elements: 3, ., and 4.
Clojure has a higher-level basic data-structure than the usual Lisp. In those Lisps cons cells are are nothing more than a two-element record, a few basic operations (CONS, CONSP, CAR, CDR, RPLACA, RPLACD) and a special data syntax for them: ( a . b ). In a typical Lisp, the dot is not a list element, but divides the car from the cdr. Additional there is simpler notation for (a . (b . nil)) in the form of (a b) .
I guess we can agree that it's not a sufficient condition, but from my selection of languages you may consider that maybe I meant it as a necessary condition.
Another interesting separator is: does it include "Lisp" in its name? Scheme and Dylan don't. Maybe people don't use "Lisp" in the name to indicate that they intend the language to break away in some way from the Lisp tradition. In a similar way, Racket broke away from Scheme tradition, for example.
Kent Pitman, in his "Lambda the Ultimate Political Party" article, wrote that people have been writing programs to help transition code written in the older dialects to the new dialects. The fact that it's doable without expending too much energy also suggests close relationship. Some months ago I wrote some <100 lines of code, consisting mostly in a bunch of macros, to make a program using Flavors work on Common Lisp with CLOS. Are the people using Clojure, Janet, etc. doing this? Can they pick up an old program written in another Lisp dialect that's close to them and, with not too much fuss, make it run? Which dialect would that be?
I'd have a hard time selecting LISP for anything others would use (which is almost all the software I write) unless I worked in a company that was using LISP regularly.
Click is a neat upgrade from argparse if you’re ever tempted (assuming something like “pip install —-user” is viable in your situation which isn’t true for everyone).
I’ve seen, but haven’t used https://typer.tiangolo.com/ - i have used his FastAPI and thought that was nicely done (even if python async is a bit annoying to test).
Talking of python cli libs I haven’t tried but will do one day - rich: https://github.com/willmcgugan/rich
Click is nice if you want a command with multiple sub commands. I use Go + Cobra at that point via https://github.com/hofstadter-io/hofmod-cli
The human understanding is a big reason why python has gained my favor over bash
Once we need deps we need a more complicated setup, so Docker or Go usually prevail
Plus the need for scripts diminues when you can write a function on typed objects (all scripts are parsers).
I also try to seek other IPC mechanisms when possible, such as talking to daemons through DBus or JSON-RPC depending on what is available.
edit: this story is currently on the front page of HN too, https://news.ycombinator.com/item?id=26491858 (Do not use redirection characters in your shell prompt), the neverending examples of how shell scripting makes your life miserable (sure it's helpful, but can't we have nicer things?)
SBCL had scary "windows not supported" messages for a long time, but that was mainly because none of the core sbcl team had windows machines, so any bugs that didn't reproduce under wine weren't going to get support from them. LispWorks and Allegro both have had first-class support for windows for decades.
As far as UIOP: UIOP provides portability interfaces that make it less likely that something developed on linux will be DOA on windows, as well as smoothing out differences between implementations. If were developing on a single implementation for just windows nothing in UIOP is really necessary (but portability is always a "nice to have" feature that UIOP does provide).
#! /path/to/mlisp-or-alisp -#!
...lisp code...