Re:Ask HN: Production Lisp in 2020?
by dan-robertson on Tuesday May 19, 2020 @09:39AM
(#23234750)
Let’s say I have a big repo full of lisp. I want a program that uses some subset of this lisp. Similarly to if I had a big repo full of C programs and libraries and I wanted to build one of those programs (statically linking all the libraries it used). In CL, it is annoying and tricky to go from those files to an executable I can deploy. Typically you’d write some script to (use ASDF to) compile/load your various files and then dump the image specifying a binary. It’s a bit messy and not very portable.
[ Parent
| on HN ]
I will never understand how people have such a rosy view of C development. Is it just that today people think there is only GNU make, and only GCC or clang?
Autotools used m4 because it was the most portable Unix tool, not because it's a good language to write your build scripts in...
Re:Ask HN: Production Lisp in 2020?
by justinmeiners on Tuesday May 19, 2020 @11:05AM
(#23235626)
I have had problems with C, but building my code was never one of them. You are right that I have only used GCC, Clang, and Visual Studio.
I thought they use M4 because they were doing sophisticated preprocessing?
I misremembered; M4sh (which uses m4 to generate portable bourne-ish shell scripts) is what was the lowest-common-denominator for autoconf.
Re:Ask HN: Production Lisp in 2020?
by dan-robertson on Tuesday May 19, 2020 @07:04PM
(#23241360)
Perhaps C was a poor example. I just mean “statically compiled language where files become objects and objects get linked into executables/libraries and this is done by a build system”.
Perhaps rust would have been a better example as there is less variety in build systems.
Makes sense. I have noticed that deployment and compilation part of lisp isn't talked about often.
The method you described is the best one I have found (load everything and dump an image.)
>I have noticed that deployment and compilation part of lisp isn't talked about often.
Because it's trivial.
Compilation is almost implicit, when loading a file.
Creating an executable is only one line of code.