The why and how of triple scripts: Difference between revisions

From triplescripts.org wiki
Content added Content deleted
(tweak wording about all programmers benefitting)
(reword Engelbart allusion and other sentence structure)
Line 5: Line 5:
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.
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 [[implicit step zero|an implicit step for others to figure out]] on their own.) So programmers who truly seek productivity gains and the acceleration of human effort as Engelbart described should be 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.
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 [[implicit step zero|an implicit step for others to figure out]] on their own.) So a programmer who truly seek productivity gains—or, in the words of Engelbart, the acceleration of human effort—is a programmer who should be 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 web browsers.


== See also ==
== See also ==

Revision as of 02:23, 24 November 2020

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 reading and writing files.

Even for languages that are not 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, 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 who truly seek productivity gains—or, in the words of Engelbart, the acceleration of human effort—is a programmer who should be 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 web browsers.

See also

The ABCs of triple scripts

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