Lisp users try to make a simple program, part II

and 40 years have passed since. we should aspire to move forward and innovate instead of getting stuck in the past.
40 years until kernels written in javascript

I know, I used to do 1k intros for DOS complete with a limited s3m player. If you look at the text segment it'd be like 100 bytes most of which is 64 bit bloat (never test errors with == -1, by the way). The rest is one-time setup for various modern bullshit that is hard to remove via compiler options. Thread-local support, mmapped stringtable hash, etc..

I'm not a lispfag, but I feel like playing devil's advocate right now.
Due to its intrinsic dynamic properties, like dynamic typing, macros, symbolic evaluation and being able to treat code itself as data and vice versa, Lisp basically requires an highly capable runtime environment to actually do all of those things. The same can be said, to a lesser extent, for Python.

It's not about being "high level": Haskell and ML can be compiled without issues to native code that doesn't need an additional runtime to be executed, just like C can. Even Java can be easily compiled to native code that doesn't need the JVM to run if you use a compiler such as GCJ, although that kinda defeats the point of using Java. It's still quite interesting to do, though, and the performance is surprisingly good, although not on par with C++ or C.

Notice one thing all these languages have in common: they feature a *static* type system.
This is by far the most important kind of information to give to the compiler. By knowing what kind of data functions take in, what they return and having all operations among types unambiguously defined, the compiler can easily generate code that assumes some properties about the data it manipulates (Integers of a certain size? Strings? Lists?) without needing to check at runtime if those operations are permitted, since static analysis has guaranteed that function f will receive, say, an integer and a string every time it is invoked. You can't do the same with dynamic typing.
The often mentioned property about static typing catching compile-time type errors is really just a happy side effect, it's not, in my opinion, the most important thing about it.

Now, theoretically, even highly dynamic (not only with respect to typing) languages like the Lisps could theoretically be compiled down to a standalone binary, but it would pretty much require a massive amount of additional code you didn't write yourself to support its full functionality. And often, the easiest solution is to just bundle the interpreter with it.

Too late.

Probably because Lisp is a commie language.

Nobody cares about binary sizes in 2018 when the average hard drive has 500 gigs or more, user. This isn't the 70s anymore.

The problem is that the program isn't doing anything fundamentally different from what it did back in the 70s, but it has a way higher binary size for no good reason.

I've got over a thousand executables in my bin directories of a basic Debian install. After doing "raco distribute", the racket text editor is 27M. If everything was made this way with racket, you'd make a basic Debian install weigh in at 30 gigs. I don't think people would be pleased, especially the cloud guys who pay per gigabyte. That you see nothing wrong with bloat this extreme is why people make fun of lispfags and why no one writes anything in it.

protip: If you assume the Racket interpreter is installed as a prerequisite, then there is no need to statically link the interpreter into the program. If you remove that assumption away, then your Racket program will need to bundle the interpreter functions by default

Yeah sure so when I call eval in racket the whole thing just explodes? O wait it actual bundles all of fucking racket into the executable. When you run a c program it sure as fuck does not include gcc in the bundle.