Toolbench pattern: Difference between revisions

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". Triple scripts' predictable module semantics and the [[object-capability model]] make this especially feasible. This pattern of creating a "shell" around the triple script allows for the existence of powerful toolbenches, where such things as networkability or arbitrary filesystem access belongs to the wrapping app itself and need not "taint" the triple script.

Consider UNIX. If something bothers you about [https://curl.haxx.se/ 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 curlcurl—something unintuitive or undesirable about its UI, 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, deepwithout changeshaving andto integrationpatch atcurl this level is not normally seen on UNIX, because the traditional implementation language (C) has subtle and not-so-subtle effects on the [https://malleable.systems/ mealleability] of the system.itself?

Or more concretely, consider two tools: 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 [https://jekyllrb.com 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, unlike the way that Jekyll allows.