POSIX is stuck in the days when UNIX software was plain CLI or daemons, with keyboards and teletype as devices.
On a more serious note, this is not happening because POSIX is bad or irrelevant but because people a) don't know about it and b) even if they did, reinventing the wheel is more fun.
For me the good old days were the time spend with Amiga 500, discovering the world of Smalltalk, Oberon and all Xerox PARC research and other pioneers.
I got into UNIX via Xenix, and used almost every commercial flavour of it, but don't consider it the good old days.
The fact that POSIX is stuck in a PDP-11 world, is a proof that no big in the industry, with power to drive POSIX forward, is seeing as a relevant OS API for anything besides writing daemons and CLI applications accessible via SSH.
Things started picking up around Linux time, though that age of goodness started getting stale around 2006 (maybe because linux started to get commercialized? Or maybe because everyone started getting interested in handheld devices for their 'fun' programming?)
Standards probably shouldn't sit still, especially if they hew more closely towards existing practice than ideal practice. I think POSIX is overdue for an update.
As an aside though, did people ever voluntarily use csh? Aside from committed masochists, that is.
POSIX is being updated constantly. It is just not as noticeable because POSIX is, as you say,
> an attempt to codify existing practice amongst Unix vendors, picking the best of the most widely supported features, as opposed to actually trying to come up with a good standard.
Yes, for an interactive shell, back when the choice was between csh that had command-line history and sh that didn't.
This is just one example of where the old ways aren't necessarily the best. I'm fairly confident we could come up with something better than POSIX if we were willing to make the effort.
please, no. OOP approach means that my process needs to know how to communicate with other processes via very specific protocols, which aren't very well defined (any process could describe its type of object). This is the exact opposite of flexibility. The usefullness of tools like grep or sed would drop drastically, and we would fall back to big blobs of software.
Since I'm just passing data, do I really need the behavior attached to it? How would state persistence be handled?
The text (bytes as ASCII until line ending) approach may seem ugly and dirty, but in fact you can pass list, tuples, maps, trees or just text and is up to the receiver the responsibility to make sense out of the data.
Need data from A but B can't understand it? Use C (which operate on text) to format A's output as B needs. With object how many "translator" (C in the example) would you need to acheive the same result?
In a world where things are "fixed" by just blowing away a VM and spinning up a new one, you might not care but in that case why bother to log anything at all...?
POSIX is not Unix.
Passing data around as text is a tenet of the Unix philosophy, while AFAIK POSIX doesn't mandate any of that.
The lowest hanging fruit gets picked. "Lets dump absolutely everything and NIH the whole thing for a single time 5% performance increase" doesn't sell well when that one time gain is expressed in the amount of time it takes hardware or network capacity to improve 5%, or fixing poorly scaling algos. Also insert the usual analogy of the ratio of the cost of microscopically faster hardware vs the labor cost of extremely expensive rockstar ninja programmers.
Also its assumed that change will lead to improvement because anecdote, or because change is always good. However, "the thing that won uses text, so naturally we gotta get rid of text" doesn't sound like a wise plan.
Here is our project site: https://columbia.github.io/libtrack/
and our repository github repo: https://github.com/columbia/libtrack
