Why I haven't jumped ship from Common Lisp to Racket just yet

Post by aerique » Wed, Aug 23, 2017, 8:27 AM UTC

lottin wrote: post #30

> trivial utilities for interactive use from the shell command-line with an "instantaneous" feel Last time I checked CL images were huge though. Something like 24MB for a "hello world" executable, even bigger with some compilers.

    $ cat > hello-world.lisp
    (defun main () (format t "Hello, World!~%"))
    $ sbcl 
    * (load "hello-world.lisp")
    T
    * (save-lisp-and-die "hello-world" :toplevel #'main :executable t)
    [undoing binding stack and other enclosing state... done]
    [defragmenting immobile space... 1110+19908+28500+22601 objects... done]
    [saving current Lisp image into hello-world:
    writing 4816 bytes from the read-only space at 0x20000000
    writing 2320 bytes from the static space at 0x20100000
    writing 2383872 bytes from the immobile space at 0x20300000
    writing 15190112 bytes from the immobile space at 0x21b00000
    writing 39911424 bytes from the dynamic space at 0x1000000000
    done]
    $ ./hello-world 
    Hello, World!
    $ ls -lh hello-world
    -rwxr-xr-x 1 user user 56M Aug 23 10:23 hello-world

Post by juki » Wed, Aug 23, 2017, 9:06 AM UTC

lottin wrote: post #32

aerique wrote: post #31

Earlier quoted context omitted.

You are correct, but why is this a problem in the case mentioned by the author? $ cat > hello-world.lisp (defun main () (format t "Hello, World!~%")) $ sbcl * (load "hello-world.lisp") T * (save-lisp-and-die "hello-world" :toplevel #'main :executable t) [undoing binding stack and other enclosing state... done] [defragmenting immobile space... 1110+19908+28500+22601 objects... done] [saving current Lisp image into hel…

It's not necessarily a problem, but personally for small utilities I much prefer something that supports #!-style scripts, like Guile or Racket, or that can be compiled into small, efficient executables. Let's say it's a matter of personal preference.

Post by pjmlp » Wed, Aug 23, 2017, 9:30 AM UTC

flavio81 wrote: post #14

The author, a famous and well-liked lisper, is not consider ing portability features. CL is an ANSI standard and code often runs with no changes in many distinct CL implementations/compilers/interpreters. Also, related to that point: There are many different CL implementations out there that satisfy different use cases, like for example JVM deployment (ABCL), embedded systems (ECL), speed(SBCL), fast compile times (C…

Post by lottin » Wed, Aug 23, 2017, 9:49 AM UTC

IronBacon wrote: post #34

lottin wrote: post #30

> trivial utilities for interactive use from the shell command-line with an "instantaneous" feel Last time I checked CL images were huge though. Something like 24MB for a "hello world" executable, even bigger with some compilers.

With SBCL and Linux kernels with binfmt_misc support enabled (module or compiled) you can execute FASL file from command line, using the same SBCL core for all the executables and, I would add, with an "instantaneous" feel. ^__^ With Debian it should work out of the box, on other distributions it probably needs to register a wrapper/trampoline with the binfmt_misc infrastructure. FWIK running instances don't share th…

Post by pjmlp » Wed, Aug 23, 2017, 10:40 AM UTC

jackdaniel wrote: post #36

pjmlp wrote: post #35

Earlier quoted context omitted.

The biggest issue I see with Common Lisp is that the standard is stuck in time, lacking stuff like database providers, a common FFI or threading. It needs a review of the CL environments that survived to modern days and adopt the common extensions.

I think it is a pretty shallow view at standard. CL implementations grow and have agreed interfaces (or portability layers). A few examples: - sockets via usocket - threading via bordeaux-threads - metaobject protocol via closer-mop - foreign function interface via cffi all these are not mentioned in the standard at all, but are implemented and used in production environment. Having base standard and extensions which…