3 ms·

Yes, this is the thing that probably most annoys people coming from languages like C about Lisp. Producing a standalone executable is non-obvious, and different

by astine 16y ago

Yes, this is the thing that probably most annoys people coming from languages like C about Lisp. Producing a standalone executable is non-obvious, and different from implementation to implementation. Commercial implementations make this simple, but generally, folks learning the language aren't using commercial implementations. It's funny though when you realize that it's not any harder than Java or a scripting language.

jwr 16y ago
I've always wondered why this problem only seems to be raised wrt Lisp. I mean, do you get people wanting to create Python executables or Ruby executables? 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?
- astine 16y ago
  Well, not all of us run a Mac. Python and Ruby are both advertised as 'interpreted' languages and most programmers realize that what you do with them is write a script, which you then feed into a Python or Ruby interpreter. Many Lisp implementations are advertised as compiled and when people think of compiled languages, they think of C, C++, Paschal, or any one of dozens of languages where you write a program, feed it to a compiler (either through a build tool or straight) and you end up with an executable file that you can double click on or type in at the command line. When I first started with Lisp I expected something similar, and was surprised. 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.
- xorglorb 16y ago
  > On my mac, applications are really directories with lots of stuff inside. Why insist on stuffing everything into a single file? 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.

by astine 16y ago

jwr 16y ago

I've always wondered why this problem only seems to be raised wrt Lisp. I mean, do you get people wanting to create Python executables or Ruby executables? 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?

astine 16y ago
Well, not all of us run a Mac. Python and Ruby are both advertised as 'interpreted' languages and most programmers realize that what you do with them is write a script, which you then feed into a Python or Ruby interpreter. Many Lisp implementations are advertised as compiled and when people think of compiled languages, they think of C, C++, Paschal, or any one of dozens of languages where you write a program, feed it to a compiler (either through a build tool or straight) and you end up with an executable file that you can double click on or type in at the command line. When I first started with Lisp I expected something similar, and was surprised. 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.
xorglorb 16y ago
> On my mac, applications are really directories with lots of stuff inside. Why insist on stuffing everything into a single file? 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.