Sorry if I came off as "excited" -- the main thing I'm not clear on is the framing of M x N with respect to parsing.
From my post:
I also claim that parsing is an O(M + N) problem, while types can create O(M × N) problems — and often do.
So the key point is that writing M + N amounts of code is tractable, but M x N is not. This was captured in the linked "Unix vs. Google" video as "coding the perimeter" vs. "coding the area".
This is not to say that SOME people won't be annoyed by writing M + N parsers! :) Or that writing parsers is easy. It's only claiming that it's tractable for global interoperability.
-----
Of course you could be referring to some different M x N issue, with respect to a specific application, but I don't really see it, and I'd claim it isn't the dominant issue with interoperability and POSIX.
To bring it back to the original subject, POSIX addresses the M applications x N hardware platforms issue (and again, the claim is that it's a compromise, not that it's optimal).
And of course POSIX APIs are text- / byte-oriented, unlike past and future operating systems.
It tames a code explosion and make systems feasible. But yes I definitely agree that we need more structure on top of text. My view is that we need a language with first-class support for serialized tables (TSV/CSV), records/objects (JSON), and documents (HTML/XML).
CSV in particular is very sloppy, and we should take at least as good care of our "languages for data" as we do languages for code (Go, Rust, Python, etc.)
From my post:
I also claim that parsing is an O(M + N) problem, while types can create O(M × N) problems — and often do.
So the key point is that writing M + N amounts of code is tractable, but M x N is not. This was captured in the linked "Unix vs. Google" video as "coding the perimeter" vs. "coding the area".
This is not to say that SOME people won't be annoyed by writing M + N parsers! :) Or that writing parsers is easy. It's only claiming that it's tractable for global interoperability.
-----
Of course you could be referring to some different M x N issue, with respect to a specific application, but I don't really see it, and I'd claim it isn't the dominant issue with interoperability and POSIX.
To bring it back to the original subject, POSIX addresses the M applications x N hardware platforms issue (and again, the claim is that it's a compromise, not that it's optimal).
Text addresses the M kinds of application data x N operations issue: https://www.oilshell.org/blog/2022/02/diagrams.html#bytes-fl...
And of course POSIX APIs are text- / byte-oriented, unlike past and future operating systems.
It tames a code explosion and make systems feasible. But yes I definitely agree that we need more structure on top of text. My view is that we need a language with first-class support for serialized tables (TSV/CSV), records/objects (JSON), and documents (HTML/XML).
CSV in particular is very sloppy, and we should take at least as good care of our "languages for data" as we do languages for code (Go, Rust, Python, etc.)
Tar is also very sloppy, just re-read this post today: https://www.cyphar.com/blog/post/20190121-ociv2-images-i-tar