A tiny self-remaking C program

  #if 0
  TMP=$(mktemp -d);
  c++ -std=c++11 -o ${TMP}/a.out ${0} && ${TMP}/a.out ${@:1}; RV=${?};
  rm -rf ${TMP};
  exit ${RV};
  #endif
    
  #include <iostream>
    
  int main()
  {
    std::cout << "Hello, world!\n";
  }

If you aren't familiar, quines are programs which produce their own source as their only output. They're quite interesting and worth a dive if you haven't explored them before.

My personal favorites are the radiation-hardened variety, which still produce the original pre-modified source even when any single character is removed before the program is run.

[1]: https://en.wikipedia.org/wiki/Quine_(computing)

I have long been thinking the same. And also: "Running tests is the first stage of deploying in production" etc.

In other words: There is often a whole dependency graph between various stages (install toolchain, install 3rd-party dependencies, do code generation, compile, link/bundle, test, run, …) and each of those stages should ideally be a pure function mapping inputs to outputs. In my experience, we often don't do a good job making this graph explicit, nor do we usually implement build steps as pure functions or think of build systems as another piece of software which needs to be subject to the same quality criteria that we apply to any other line of code we write. As a result, developer experience ends up suffering.

Large JavaScript projects are particularly bad in this regard. Dependencies, auto-generated code and build output live right alongside source code, essentially making them global state from the point of view of the build system. The package.json contains dozens of "run" commands which more often than not are an arcane mix of bash scripts invoking JS code. Even worse, those commands typically need to be run in juuust the right order because they all operate on the same global state. There is no notion of one command depending on another. No effort put into isolating build tasks from each other and making them pure. No caching of intermediate results. Pipelines take ages even though they wouldn't have to. Developers get confused because a coworker introduced a new npm command yesterday which now needs be to run before anything else. Ugghhh.

https://bellard.org/tcc/tcc-doc.html

It's an interesting exercise working out what is both a comment in the target language but is also an executable shell script. For C it's reasonably straightforward but for OCaml it's quite subtle:

https://libguestfs.org/nbdkit-cc-plugin.3.html#C-plugin-as-a... https://libguestfs.org/nbdkit-cc-plugin.3.html#Using-this-pl...

I'm guessing that this (IBM) example is setting the delimeter to '@@' to avoid problems with the comment - JCL also understands the '/*' sequence. I've not seen it used with other languages (Cobol etc.)

    //jobname    JOB   acctno,name...
    //COMPILE    EXEC  PGM=CCNDRVR,
    // PARM='/SEARCH(''CEE.SCEEH.+'') NOOPT SO OBJ'
    //STEPLIB    DD    DSNAME=CEE.SCEERUN,DISP=SHR
    //           DD    DSNAME=CEE.SCEERUN2,DISP=SHR
    //           DD    DSNAME=CBC.SCCNCMP,DISP=SHR
    //SYSLIN     DD    DSNAME=MYID.MYPROG.OBJ(MEMBER),DISP=SHR
    //SYSPRINT   DD    SYSOUT=*
    //SYSIN      DD    DATA,DLM=@@
      #include <stdio.h>
      ⋮
      int main(void)
      {
      /*  comment   */
      ⋮
      }
    @@
    //SYSUT1     DD    DSN=...
    ⋮
    //*

Debian is pretty far off from this vision (if we also want performant execution), but I wonder how do the Gentoo, ArchLinux and Nix fare in this regard? Is this something that could be viably built with their current packaging formats?

  /*usr/bin/env echo 'Hello World!' #*/

As for getting rid of the shebang - swapping the ! with a / means that the line and character counts don't change so you get meaningful error messages.

https://en.wikipedia.org/wiki/C_shell

It seems like you are on your way to making the C++ shell.

https://www.ioccc.org/years.html

    "$0".bin: -c: line 0: unexpected EOF while looking for matching `''
    "$0".bin: -c: line 1: syntax error: unexpected end of file

thats the one i've been using. feel free to adopt and change.