Re:Ask HN: Production Lisp in 2020?
by justinmeiners on Tuesday May 19, 2020 @09:35AM
(#23234706)
> consistently go from source code to a binary
Can you talk more about this?
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.
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.
I don’t really care about libraries. I think generally it’s not very hard to write an ffi binding to a C library and most of the time you don’t need a library anyway. Most of the time you can just write your own library from scratch as you probably only need a few functions.
But maybe this is more a statement of the sort of programs I work on and if you worked on different systems you would want to use lots of external libraries that you don’t control.
I think the biggest issue with CL is how tightly attached it is to an outdated standard. It makes it harder to have things like good Unix support if your interface is through pathnames and streams.
Other thing which may be annoying about CL are the lack of a good way to consistently go from source code to a binary and that compiler optimisations can be unpredictable