POST /api/users
    |> validate: `
      name: string(3..50)
      email: email
      age?: number(18..120)
      team_id?: number
    `
    |> jq: `{ sqlParams: [.body.name, .body.email, .body.age] }`
    |> pg: `INSERT INTO users (name, email, age) VALUES ($1, $2, $3) RETURNING *`
    |> result
      ok(201):
        |> jq: `{ success: true, user: .data.rows[0] }`
      validationError(400):
        |> jq: `{
          error: "Validation failed",
          field: .errors[0].field,
          rule: .errors[0].rule,
          message: .errors[0].message
        }`

[0] https://github.com/williamcotton/webpipe

One likely place to stop is at "processes". But this must be motivated since ultimately processes are as synthetic a convention as a language thread - it's just that the runtime is called a "kernel" instead of a "runtime".

Ultimately I think what the author is getting at is a data problem, not a code problem. Or rather, it's yearning toward a world where data and code are strongly decoupled, conventions around data are standardized, so that processes written in disparate tooling can successfully interoperate locally. However I doubt there is much appetite for a "model of everything" registry (such things have been tried, and failed, in the past). That said we might take another stab at this, since LLMs make likely that software will become more dynamic in terms of translating data structures at runtime such that one program can examine a peer program and its data structures, and how to map them to local data structures, thus achieving interoperability without a centralized agreement on representation.

Unix shells (local), I'll add in HTTP (remote), and Email (remote and asynchronous) are the only forms that are ubiquitous, precisely because they enforce no structure for the payload. The structured alternatives are only popular in specific domains because they create their own ecosystem. As long as input can clearly be parsed, which goes hand in hand with being human-readable as long as you're not trying to be too efficient, you get schema implicitly transmitted out of band (by having output that you can visually inspect) and interoperability for anything that can read and write text.

I'd be interested in other directions this might go, but I remain skeptical of anything that will introduce and enforce a new paradigm that requires adding complexity to programs to accommodate it.

FWIW I wrote a post about this design issue:

Oils Is Exterior-First (Code, Text, and Structured Data) - https://www.oilshell.org/blog/2023/06/ysh-design.html#survey...

That is

- Powershell and nushell have an "interior" design (within a process/VM)

- while POSIX shell, bash, OSH, and YSH have an "exterior" design (between processes)

And I'll claim that the exterior design is the glue you need in large, heterogeneous systems. Making the shell "interior" and "easy to use" is at odds with the role as essential glue -- it creates pressure for something else to be used instead.

---

Maybe the more pithy statement is here:

A Sketch of the Biggest Idea in Software Architecture - https://www.oilshell.org/blog/2022/03/backlog-arch.html

The lowest common denominator between a PowerShell, Elvish, Rash, and nushell script is a Bourne shell script (and eventually a YSH script)

I also claim this isn't theoretical -- there are probably a non-trivial number of bash scripts gluing together PowerShell and other shells. IMO it's better to have 1 type of glue, than 2 or more types, which I call "Unix sludge / Cloud sludge".

---

And I disagree with this part, which references protocol buffers:

> how do you get a schema? well, you establish in-band communication. RPC is ...

Protocol buffers transmit schemas OUT of band, usually via a monorepo. The data sent over the wire can't be interpreted without the schema information compiled into the binary.

The monorepo works well enough within Google, but even there it failed to scale (probably around the time of "Alphabet", e.g. Waymo and other companies)

Also, protobufs are biased toward C++; users of other languages feel this friction to varying degrees. In general, they'd rather use .gob for Go, pickle for Python, JSON for JS, Java serialization, etc.