The why and how of triple scripts

Actually getting software built and/or being able to reliably run it is way too hard. At this point in humanity's trajectory, this is a problem that really should have been solved already.

Triple scripts aim to be the belated solution. It goes like this:

Although it can be a little more complicated, compilers are basically just pure functions. The general expectation is that a compiler will read in a bunch of source files, process them, and then output an executable program. This is how the Go compiler works, for example, it's how GCC works, it's how the Roslyn and Mono C# compilers work, and it's how tsc and even JS bundlers work, too. You name it; most compilers work this way, from Fortran or ALGOL to your favorite new fad language. They're usually designed so you can run them from a command-line shell inside a terminal emulator, or maybe there's a project configuration setting that allows a button in an editor like VSCode to kick things off. The thing is, though, they're just doing a classic batch data processing job—reading in files, and writing out another (or possibly multiple others).

Whether or not you're dealing with a language that is traditionally compiled, whether you're developing something written in Python or Ruby or Go or Java or C or C++ or Common Lisp or anything else that relies on a contemporary development toolchain, you'll need to make sure those tools are installed and set up. In practice, this setup can pose a slight problem. (Let's be honest here; the magnitude of the problem is often much more than "slight". Chris Granger behind Light Table and Eve is fond of pointing to the exercise of getting a developer machine set up as an example of how inaccessible programming is; on the Light Table blog, Jamie Brandon writes an excellent criticism of traditional development practices, dubbing the assumed competencies of setting up a development environment "pain we forgot. The triplescripts.org group refers to this problem as implicit step zero.) Can that problem be avoided?

First, an observation: Web browsers can, via drag-and-drop or a file input element, read files at the user's direction, too, and—being Turing programmable (via extremely fast, memory-safe runtimes)—Web browsers can also of course process those inputs and produce some output. It turns out that everyone already has one installed, too. What's the significance of this?

Suppose you were to write a program that does the same kind of work that conventional toolchains do, but you managed to implement and distribute it as a program that can run entirely in a web browser—entirely in the browser (without delegating to a server somewhere)—you will have created something that is almost certainly less hassle to get up and running than the setup associated with any of the conventional toolchains themselves. And if you found some way to implement and distribute that program as a single file, then the only setup that would be necessary for anyone to use your new compiler would be to get that file, and that's almost no hassle at all: if people are trying to get that file because they've just downloaded the source tree of your project and they want to build it, then you could just put that file in your project, so they get a copy at the same time they get your source code.

Criticisms aside, one should recognize at this point that achieving such a thing would put us at a place where every programmer in existence—and every prospective programmer—could eliminate for themselves and their collaborators a massive burden that plagues software development under the current regime. The status quo, a world without triple scripts, involves what is essentially a given that every programmer will spend some time struggling with their toolchains, pouring untold effort into the steps that are usually described as "setting up a development environment". (That is, if such steps are actually ever explicitly spoken of, and not left as an implicit step for others to figure out on their own when encountering a given project for the first time.) So a programmer truly seeking productivity gains—or, in the words of Engelbart, the acceleration of human effort—is a programmer who should be sufficiently motivated to bring about a way of working that resembles this experience wherever and however possible—even if those programmers have misgivings about the particulars of this vision—and there are certainly plenty of misgivings and downright enmity associated with our recommended runtime. It's essential, though, that we push past these trivial disputes.

See also

The ABCs of triple scripts