The why and how of triple scripts: Difference between revisions
both solvable and avoidable
(reinforce that we're trying to contrast against the status quo) |
(both solvable and avoidable) |
||
(19 intermediate revisions by 3 users not shown) | |||
Line 3:
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 [https://golang.org/ Go] compiler works, for example, it's how [https://gcc.gnu.org/ GCC] works, it's how the [https://docs.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/ Roslyn] and [https://mono-project.com/ Mono] C# compilers work, and it's how [https://www.typescriptlang.org/ tsc] and even JS bundlers work, too.
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
<blockquote>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.</blockquote> — from [http://bayfronttechnologies.com/mc_tutorial.html the Bayfront Technologies metacompilers tutorial]
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.▼
First, an observation: Web browsers can, via drag-and-drop or a file <code>input</code> element, read files at the user's direction, too. 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?
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 [[implicit step zero|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.▼
▲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
▲
== See also ==
* [[The ABCs of triple scripts]]
* [http://bayfronttechnologies.com/mc_tutorial.html Tutorial: Metacompilers Part 1]
|