Actually I see a rational in his answer but I wonder how other scripting system address the issue.
(sorry if I take it from an historical perspective, but I think it's important to understand what Ashinn is saying)
He basically means you have (and should stick to) two ways of _distributing_ a piece of code:
- libraries
- programs
In a programming language that only supports statically linked binaries this appears quite obvious: you either distribute an executable or a library archive.
But if you distribute the executable, it's self-contained: it actually contains all the required code (except for the kernel, obviously, or any other program it invokes through `exec` which count as dependencies)
Dynamic linking complicates things. People can distribute a library that is linked _at_run_time_ to the executable, so that programs are not self-contained anymore. BUT at least all of the code from a certain team end in a single file (the binary executable) that can be installed in the system paths without name clashes.
Scripting languages further stretch this flexibility and let you distribute source files that can be executed actually.
BUT developers split code to ease development, not distribution.
So you might end with a `utils.smc` in your project, but I could have the same for my project: what if a user try to install both in /bin?
The name clashes cause the second installation to break the first.
So basically Ashinn says: do not distribute #Scheme programs split into different files.
If you want to build a library that people actually uses, distribute it separately. But each program (and script) should be distributed as a single-file.
I think this reasoning is quite correct (it's not by chance that #Jehanne only support statically linked binaries) but I wonder how other scripting languages solve the issues.
For example, #Python should have the same kind of issues.
Do they stick to this "one-file scripts" for programs that are going to be installed in /bin?
To be honest, I've never had to dwell into this issue as most of my python programs weren't distributed to run in a system path.
