More actions
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 toolchain, widely lauded for its batteries-included, low-friction experience, does its work, for example. It's also 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 to either be invoked from the command-line in a terminal emulator, or maybe there's a project configuration setting that allows a button in an editor like VSCode (or another heavyweight IDE) 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, one unavoidable thing that you'll have to make sure of is that those tools are installed and set up on some machine for your use. 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 presumptive attitude re competency to set up a development environment "pain we forgot". The triplescripts.org group refers to this problem as implicit step zero.) Can that problem be solved? Better yet, can it be avoided? The answer to both is yes.
After all a compiler is just a program that reads text and writes text or binary. Most general purpose programming languages are capable of doing that.
— from the Bayfront Technologies metacompilers tutorial
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 programmable—via extremely fast, memory-safe runtimes—Web browsers can also of course process those inputs and produce some output. And 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 compilers do, but you managed to implement and distribute it as a program that can run in the web browser—entirely in-browser (without delegating to some other networked machine, i.e. a remote server, to do the heavy lifting elsewhere)—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 somehow obtain that file. We know that the latter part is 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's source tree, so they get a copy at the same time they get your source code. And why not—most projects already do something like this, with their build scripts being checked into the source tree. Essentially, what we're talking about is not having a split between in-tree build scripts that are stored as source code and intended to drive out-of-tree binaries that convert your human readable source into machine executable but rather (a) putting (still human readable) "build scripts" in your source tree that output runnable programs directly—no delegating to fickle, ever-shifting (and ever-breaking), out-of-tree toolchains, and (b) that the script interpreter should be the web browser—the only truly universal platform that humans have actually managed to pull off.
Criticisms aside, one should recognize at this point that to achieve this would be to put us in a world 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 status quo. This is a status quo where, in a world without triple scripts, it is the norm for virtually every programmer to squander countless hours (days, even) 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 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 trivial disputes.