4 ms·

Many applications I've used that come as an exe are hardly that easy to install and configure. Inevitably, something breaks because of my machine's particular c

Many applications I've used that come as an exe are hardly that easy to install and configure. Inevitably, something breaks because of my machine's particular configuration. On the development side, building to that magical executable is an even bigger nightmare. Most packages in python or nodejs? Install and run through package managers just fine.

jjawssd 9y ago
> Many applications I've used that come as an exe are hardly that easy to install and configure. Python and Node interpreters are EXEs that are NOT easy to install and configure for 95+% of end-users > Inevitably, something breaks because of my machine's particular configuration. Indeed. Like a screwed up $PYTHONPATH > On the development side, building to that magical executable is an even bigger nightmare. I do not understand. > Most packages in python or nodejs? Install and run through package managers just fine. This implies you are familiar with WHICH interpreter you are calling and that you know where it is installed so you can call it. None of this is easy for end-users.
hasenj 9y ago
The more you depend on things to be right in the target environment, the more chances you have of breaking things. Having a statically linked binary will not always magically solve this, but it's a great step in that direction. The other step is not relying on any external servers or services, e.g. postgresql, redis, etc. The rest just boils down to programmer discipline. Never introduce something that can potentially cause a headache to the end user. If you're building on an interpreted language, you can't really do that. You will always at least require the user to have a specific version of python/node/whatever. This can get complicated if the user has a different version, so now you have to introduce a virtualization layer that can manage several different versions of the environment. These tools are always annoying to use. Not to mention that some packages could have native dependencies (e.g. a python library having a dependency on a c library) and this is almost always a source of headaches.
- sillysaurus3 9y ago
  I mean, have you tried running arc? You can fire up arc 3.1 via racket and it runs fine.
  - hasenj 9y ago
    I remember playing with it many years ago when I was still naive and at the time had bought into PG's promotion of lisp.
- spc476 9y ago
  It depends upon the interpreter. I wrote a program for use at work in Lua. The entire program, plus Lua modules it requires, are bundled into a single executable. Nothing to install but it, and a configuration file.

jjawssd 9y ago

> Many applications I've used that come as an exe are hardly that easy to install and configure. Python and Node interpreters are EXEs that are NOT easy to install and configure for 95+% of end-users > Inevitably, something breaks because of my machine's particular configuration. Indeed. Like a screwed up $PYTHONPATH > On the development side, building to that magical executable is an even bigger nightmare. I do not understand. > Most packages in python or nodejs? Install and run through package managers just fine. This implies you are familiar with WHICH interpreter you are calling and that you know where it is installed so you can call it. None of this is easy for end-users.

hasenj 9y ago

The more you depend on things to be right in the target environment, the more chances you have of breaking things. Having a statically linked binary will not always magically solve this, but it's a great step in that direction. The other step is not relying on any external servers or services, e.g. postgresql, redis, etc. The rest just boils down to programmer discipline. Never introduce something that can potentially cause a headache to the end user. If you're building on an interpreted language, you can't really do that. You will always at least require the user to have a specific version of python/node/whatever. This can get complicated if the user has a different version, so now you have to introduce a virtualization layer that can manage several different versions of the environment. These tools are always annoying to use. Not to mention that some packages could have native dependencies (e.g. a python library having a dependency on a c library) and this is almost always a source of headaches.

sillysaurus3 9y ago
I mean, have you tried running arc? You can fire up arc 3.1 via racket and it runs fine.
- hasenj 9y ago
  I remember playing with it many years ago when I was still naive and at the time had bought into PG's promotion of lisp.
spc476 9y ago
It depends upon the interpreter. I wrote a program for use at work in Lua. The entire program, plus Lua modules it requires, are bundled into a single executable. Nothing to install but it, and a configuration file.