Also, what is an executable anyway? On my mac, applications are really directories with lots of stuff inside. Why insist on stuffing everything into a single file?
Also, what is an executable anyway? On my mac, applications are really directories with lots of stuff inside. Why insist on stuffing everything into a single file?
Lisp isn't really designed with either the standard interpreted language workflow, or the standard compiled language workflow, in mind. It's workflow is actually superior in a low of ways, but it's non-obvious to non-lispers how to make a deliverable.
Actually, it's a huge problem in some ways, as there is no standard way of delivering OSS Lisp software on Linux, or Unix systems. The few OSS Lisp projects there are usually really on the presence of a specific Lisp implementation and bundle any Lisp dependencies in themselves, which when you are familiar with how the rest of the Linux/Unix OSS community is usually packaged and delivered, feels really inefficient. One case in point is StumpWM, a Lisp based Linux window manager that gained some interest a while back. It was actually pretty neat, but there were at least three or four ways to install it and none meshed completely with whatever packaging system your distro was using. I can tell you with some certainty that that hurt its adoption compared to tiled window managers written in C.
I could go on, And deal with everything you said, but I'll stop here. It think it's suffice to say, Lisp is different and people haven't figured out how to reconcile Lisp with their expectations (right or wrong) or the rest of the world.
Actually, the executable is still a single file. The directory just contains things that would be shoved into /usr/share on Linux or into a DLL on Windows, such as the icon, metadata, any other assets (game levels, images, etc.) and runtime libraries.