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. Most compilers work this way. 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. Well, let's be honest; the magnitude of the problem is often more than slight. But can that problem be avoided? First, an observation: Web browsers can read and write files (at the user's direction), too, and it turns out that everyone already has one installed. 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 started with than the setup involved 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.

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 status quo. Under the current regime, without triple scripts, it 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.) 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—and there are certainly plenty of misgivings and downright enmity associated with our recommended runtime.

See also

The ABCs of triple scripts