The Problem:
When I first tried to use Factor on Linux I couldn't seem to get it working. It kept giving missing library related error messages.
However, after some internet searching I found that the Concatenative.org site's page on installing Factor linked to a requirements page that finally described how to actually install the required dependencies to run Factor.
(Side-Note: The requirement page's mention of not including the libgl1-mesa-dev if you use proprietary drivers is out of date. The provided command already doesn't include that library. Thus, it should actually say that users should install libgl1-mesa-dev if they don't have proprietary drivers installed. I do have proprietary Nvidia drivers installed though, so I didn't test this though.)
None of this is mentioned on the main Factor site though, nor is any automated script provided in the package, which likely misleads many (most?) new users into thinking the Linux package might be broken in general and/or on their specific system and likely greatly reducing how many Linux users end up ever trying Factor or contributing to it.
Even slight friction in install processes are known to cause huge decreases in user adoption rates and this friction mentioned here is far worse than slight considering that the main site doesn't even mention the basic requirements.
The Solution:
Thus, I suggest doing both of the following:
- Mention the prerequisites and how to get them on the main site.
- Add a simple installer script for Linux users and put it in the root of the main package.
It could literally just be a copy of the one line command to install the prerequisites mentioned on the requirements page linked above:
apt --yes install libc6-dev libpango1.0-dev libx11-dev xorg-dev libgtk2.0-dev gtk2-engines-pixbuf libgtkglext1-dev wget git git-doc rlwrap gcc g++ make
apt doesn't redundantly install already installed packages, so this can just be run as is.
Some associated commentary in the script could inform users why it is there (i.e. for Linux users to make Factor usable).
The file could be named install_Linux_prerequisites.sh or whatever else. It would be obvious what the purpose is.
Additional Remarks:
Concatenative languages are very interesting and should be more widely experimented with, but friction in the process reduces user adoption rates which therefore also (like a domino effect) also ends up reducing the available contributors as well. Never underestimate the harm that having a poor install process or uncommunicative documentation or websites can cause. Even the best software in the world would still fail or lose to the competition if poorly communicated to users or needlessly tedious. This is also ironic given that the whole point of programming is arguably eliminating tedium and yet we have so many software systems that require tedious hunting down of information even for the most basic use cases. The more that is handled properly the better user adoption rates will be, as with all software.
As an extra: Perhaps informing the user that a launcher for the "start menu" can also be created and a general sense of how to do that on a few common desktop environments could also perhaps be provided in a provided readme document. It was easy to set up on Linux Mint Xfce for me. It could potentially even be automated by detecting the distro and/or desktop environment. This is not as important as adding the trivially simple installer script though.
The fact that (1) the Factor folder can be moved around wherever the user wishes and (2) that its root (where the factor executable/binary is) can be added to the path so that it can opened from the command line whenever desired could also be mentioned in the install script or elsewhere. That would even further improve the new user experience.
Debian is the most popular distro family, but similar install scripts could also be added for other distro if applicable or possible. I haven't tested others with that. Regardless, even just providing a script for Debian family distros (like Ubuntu and Mint, etc) is a big improvement in reducing user friction despite how "trivial" it may seem.
The Problem:
When I first tried to use Factor on Linux I couldn't seem to get it working. It kept giving missing library related error messages.
However, after some internet searching I found that the Concatenative.org site's page on installing Factor linked to a requirements page that finally described how to actually install the required dependencies to run Factor.
(Side-Note: The requirement page's mention of not including the
libgl1-mesa-devif you use proprietary drivers is out of date. The provided command already doesn't include that library. Thus, it should actually say that users should install libgl1-mesa-dev if they don't have proprietary drivers installed. I do have proprietary Nvidia drivers installed though, so I didn't test this though.)None of this is mentioned on the main Factor site though, nor is any automated script provided in the package, which likely misleads many (most?) new users into thinking the Linux package might be broken in general and/or on their specific system and likely greatly reducing how many Linux users end up ever trying Factor or contributing to it.
Even slight friction in install processes are known to cause huge decreases in user adoption rates and this friction mentioned here is far worse than slight considering that the main site doesn't even mention the basic requirements.
The Solution:
Thus, I suggest doing both of the following:
It could literally just be a copy of the one line command to install the prerequisites mentioned on the requirements page linked above:
aptdoesn't redundantly install already installed packages, so this can just be run as is.Some associated commentary in the script could inform users why it is there (i.e. for Linux users to make Factor usable).
The file could be named
install_Linux_prerequisites.shor whatever else. It would be obvious what the purpose is.Additional Remarks:
Concatenative languages are very interesting and should be more widely experimented with, but friction in the process reduces user adoption rates which therefore also (like a domino effect) also ends up reducing the available contributors as well. Never underestimate the harm that having a poor install process or uncommunicative documentation or websites can cause. Even the best software in the world would still fail or lose to the competition if poorly communicated to users or needlessly tedious. This is also ironic given that the whole point of programming is arguably eliminating tedium and yet we have so many software systems that require tedious hunting down of information even for the most basic use cases. The more that is handled properly the better user adoption rates will be, as with all software.
As an extra: Perhaps informing the user that a launcher for the "start menu" can also be created and a general sense of how to do that on a few common desktop environments could also perhaps be provided in a provided readme document. It was easy to set up on Linux Mint Xfce for me. It could potentially even be automated by detecting the distro and/or desktop environment. This is not as important as adding the trivially simple installer script though.
The fact that (1) the Factor folder can be moved around wherever the user wishes and (2) that its root (where the
factorexecutable/binary is) can be added to the path so that it can opened from the command line whenever desired could also be mentioned in the install script or elsewhere. That would even further improve the new user experience.Debian is the most popular distro family, but similar install scripts could also be added for other distro if applicable or possible. I haven't tested others with that. Regardless, even just providing a script for Debian family distros (like Ubuntu and Mint, etc) is a big improvement in reducing user friction despite how "trivial" it may seem.