[HN Gopher] Writing Small CLI Programs in Common Lisp
       ___________________________________________________________________
        
       Writing Small CLI Programs in Common Lisp
        
       Author : reikonomusha
       Score  : 109 points
       Date   : 2021-03-17 16:42 UTC (6 hours ago)
        
 (HTM) web link (stevelosh.com)
 (TXT) w3m dump (stevelosh.com)
        
       | cb321 wrote:
       | Nim [1] has cligen [2]. An output binary size for the trivial:
       | proc f = discard         import cligen         dispatch f
       | 
       | is about 708 KiB on Linux, 621 KiB stripped. And if you like
       | colors, hldiff [3] is not a terrible example.
       | 
       | [1] https://nim-lang.org/
       | 
       | [2] https://github.com/c-blake/cligen
       | 
       | [3] https://github.com/c-blake/hldiff
        
       | junke wrote:
       | I would say: don't do it. Nowadays I'd rather use Common Lisp as
       | a glue for other scripts rather than invoking it along with other
       | programs with shell scripts.
       | 
       | 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.
        
       | PuercoPop wrote:
       | Another alternative for shell scripting in CL there is
       | https://www.cliki.net/cl-launch
        
       | abhinav22 wrote:
       | Does this work on Windows? If i recall, there were issues with
       | lisp interfacing with windows (but uiop may have solved it
       | already - I have been to get my programs to work in Windows
       | without issue)
        
         | pjmlp wrote:
         | LispWorks and Allegro work just fine on Windows.
        
         | aidenn0 wrote:
         | You probably won't be using a Makefile and shell-scripts on
         | windows for doing the building, but yes it works fine.
         | 
         | 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).
        
           | abhinav22 wrote:
           | Thanks
        
       | Narishma wrote:
       | I wish they'd mention the size of the binaries produced this way,
       | and whether they are standalone.
        
         | aidenn0 wrote:
         | The following data is for standalone executables (modulo things
         | like libc and libm that most Linux executables depend on)
         | 
         | 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% .0071
        
           | nonameiguess wrote:
           | /bin/true will still forever irk me:
           | https://twitter.com/rob_pike/status/966896123548872705
        
         | frompdx wrote:
         | Janet is a good option if you are looking for small binaries.
         | Some people argue Janet is not really a lisp. Regardless, it
         | has many lisp features you would expect like macros, is cross
         | platform, and can produce statically linked binaries.
        
           | klibertp wrote:
           | > Some people argue Janet is not really a lisp.
           | 
           | Out of curiosity: on what basis?
           | 
           | Janet is definitely _a_ Lisp, although it 's not _the_
           | (Common) Lisp.
        
             | aidenn0 wrote:
             | Many people argue that Scheme is not a lisp, so the bar for
             | "some people argue that X is not really a lisp" is fairly
             | low.
        
               | frompdx wrote:
               | I mostly add that some people argue it is not a lisp
               | because frequently someone will comment saying Janet is
               | not a lisp whenever I mention it in the context of other
               | lisps.
        
             | frompdx wrote:
             | The arguments I have seen are based on Janet using
             | arrays/tuples rather than cons cells. Here is the author
             | addressing this on reddit a while back. https://old.reddit.
             | com/r/programming/comments/aqwedz/janet_i...
             | 
             | 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
        
               | klibertp wrote:
               | What a waste of time... It's like the "smug lisp weenies"
               | of ages past somehow slipped into the modern era.
               | 
               | 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?
        
         | 13415 wrote:
         | I was wondering about that, too. Last time I checked SBCL
         | binaries weren't exactly small, more around 40MB.
        
           | wglb wrote:
           | Typically; if you use the :compress feature, more like 14
           | meg.
        
       | verdverm wrote:
       | I've recently been using Python3 + argparse for small single file
       | utilities. Used to use bash but have probably converted now with
       | how easy calling external programs is (compared to something like
       | Go)
       | 
       | 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.
        
         | bitwize wrote:
         | Consider trying a Lisp-like scripting language such as Guile.
         | Back in the late 90s I found Perl reprehensible and avoided it
         | unless I had to use it. Guile became my Perl. I managed entire
         | web sites with it.
        
         | CraigJPerry wrote:
         | I read this entire thread thinking - this is neat and all but
         | it's a handful of lines of almost english language in a .py
         | file.
         | 
         | 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
        
           | verdverm wrote:
           | I try to avoid pip and dependencies for these python scripts.
           | This goal has it's limits.
           | 
           | 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
        
         | barbazoo wrote:
         | I recently switched to Click from argparse and like it better
         | so far.
        
           | verdverm wrote:
           | A lot of these are multi use local run, in CI, and at onsite
           | w/o internet, so we try hard to avoid dependencies and keep
           | them small and pointed.
           | 
           | Once we need deps we need a more complicated setup, so Docker
           | or Go usually prevail
        
       | lambdaba wrote:
       | For those unfamiliar with Common Lisp there is also Babashka
       | which allows for Clojure shell scripting without the JVM startup
       | time.
       | 
       | https://github.com/babashka/babashka
        
         | bmitc wrote:
         | A quote from that link:
         | 
         | > Life's too short to remember how to write Bash code.
         | 
         | Hard agree.
        
           | idolaspecus wrote:
           | Life's too short to not learn how to write bash code.
        
           | exdsq wrote:
           | I love writing bash!
        
             | [deleted]
        
           | fctorial wrote:
           | I'm astonished that we haven't moved past bash.
        
         | nerdponx wrote:
         | Common Lisp itself has Roswell, which I am disappointed to see
         | is not even mentioned in the article.
         | 
         | https://github.com/roswell/roswell
        
         | Kelamir wrote:
         | Judging from the logo, the name is derived from the Russian
         | word Babushka, which stands for a granny.
        
           | lambdaba wrote:
           | Indeed, it's a lovely name
        
       ___________________________________________________________________
       (page generated 2021-03-17 23:01 UTC)