wiki The why and how of triple scripts

The why and how of triple scripts

From wiki

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

It can be a little more complicated, but compilers are basically 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. 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 could eliminate a massive burden for themselves and their prospective collaborators. It is a given that every programmer will spend some time struggling with their toolchains and 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[edit]

The ABCs of triple scripts

Cookies help us deliver our services. By using our services, you agree to our use of cookies.