3 ms·

> “purity” is holding us back and closing our mind to new solutions. Maybe. But consider shebang. It means that any program (/script) written in any language k

> “purity” is holding us back and closing our mind to new solutions. Maybe. But consider shebang. It means that any program (/script) written in any language known by the system can call any other program written in any other language. That keeps open the option of which laguage should we use for our next module. Right?

coldtea 3y ago
That's an constrained example of the general concept of a file-association (having a file plus the info of what application executes that file). As such, it predates UNIX, exist in other OSes as well, and can be even more dynamic (as shebangs are hardcoded into the file, where file + executable associations could be external). Linux offers another way anyway: linux_binfmt If I'm not mistaken that's also how jar files can be executed by themselves without calling java on them.
- galaxyLogic 3y ago
  It is nifty and mind-blowing. It basically means there is a way to "call" a program-file and let it decide who should interpret the program. It is not too different from the way in which html-pages can declare what is the character-set that should be used to interpret the binary contents of the file. The deep thing to me is that programs can not only encode instructions for the computer, they can also encode how to do the decoding. Obviously you then need some common convention (like shebang) to say how you can interpret the part that tells how to interpret the content.
  - coldtea 3y ago
    There would be a step anyway between the user selecting even a regular binary executable (via pressing enter after writing its name on the shell, by double-clicking on it in a desktop file manager, by running a shell script which on some line invokes it, etc) and it starting to execute (the shell or GUI would have to interpret the action and tell the OS to execute the binary). So adding an intermediary to do a choice of executor and/or handover in between (whereas at the shell/file-manager level, or at the OS call level), but still before execution, is quite easy.

coldtea 3y ago

That's an constrained example of the general concept of a file-association (having a file plus the info of what application executes that file). As such, it predates UNIX, exist in other OSes as well, and can be even more dynamic (as shebangs are hardcoded into the file, where file + executable associations could be external). Linux offers another way anyway: linux_binfmt If I'm not mistaken that's also how jar files can be executed by themselves without calling java on them.

galaxyLogic 3y ago
It is nifty and mind-blowing. It basically means there is a way to "call" a program-file and let it decide who should interpret the program. It is not too different from the way in which html-pages can declare what is the character-set that should be used to interpret the binary contents of the file. The deep thing to me is that programs can not only encode instructions for the computer, they can also encode how to do the decoding. Obviously you then need some common convention (like shebang) to say how you can interpret the part that tells how to interpret the content.
- coldtea 3y ago
  There would be a step anyway between the user selecting even a regular binary executable (via pressing enter after writing its name on the shell, by double-clicking on it in a desktop file manager, by running a shell script which on some line invokes it, etc) and it starting to execute (the shell or GUI would have to interpret the action and tell the OS to execute the binary). So adding an intermediary to do a choice of executor and/or handover in between (whereas at the shell/file-manager level, or at the OS call level), but still before execution, is quite easy.