(illustrate with more concrete examples: static site generators and release automation tooling) |
m (Colby Russell moved page Little shells to Toolbench pattern) |
||
(No difference)
| |||
Revision as of 09:49, 11 July 2020
If unhappy with a triple script, anyone has the opportunity to change it, but if they are unhappy with the restrictions of triple scripts in general (see invariants), they are encouraged to create their own "little shell" for the script.
Triple scripts can't make network requests, for example, so they're less capable in that regard than even an ordinary web page. But there's nothing stopping anyone from creating a small app that includes its own triple script runtime and which takes as input a given triple script and then cooperatively drives it in a way that is felt to be more "ergonomic".
Consider UNIX. If something bothers you about curl, you have the option of patching it to do what you want. But suppose there were an impedance mismatch that you feel when you use curl, but curl itself is doing the job it's supposed to do and following ordinary conventions. Consider whether the problem you're feeling is one of ergonomics—might it be possible to make special-purpose changes to your shell that would resolve the issue? Shells' scripting and configuration options notwithstanding, deep changes and integration at this level is not normally seen on UNIX, because the traditional implementation language (C) has subtle and not-so-subtle effects on the mealleability of the system.
Or more concretely, consider a static site generator in contrast to release automation tooling. The job of a static site generator—or any other type of compiler—is fairly straightforward. A static site generator, like Jekyll for example, does a batch read of a bunch of files and then spits out some files in the processed form. This a task that triple scripts are reasonably well-suited to handle. The next step that a person who has just used a static site generator next wants to accomplish, though, is usually to upload those files to a web host. This is not something that triple scripts are well-suited for, and there will never be a way to patch a given static site generator implemented as a triple script to get it to be able to sync the files for the user. Nor will it ever be possible to use the triple script to spin up a web server on localhost allowing the user to preview the generator's output in his or her browser.
On the other hand, it's entirely doable to implement a purpose-built shell for a given triple script. In our static site generator example, the shell might host a runtime for a given triple script and permit the user to interact with the triple script directly. Upon completion, when the static site generator has finished its job, the shell can then use its own privileges to dump the resulting pages onto a web host.
Similarly, a typical setup for release automation tooling includes syncing the resulting build artifacts to a server for wide release. A triple script in itself can handle the build, but the final act of uploading will have to be deferred—either to the user, or whatever agent the user assigns to handle the final artifacts that the script produces.