One Eco's book relevant, IMO, for programmers: "The search for the Perfect Language". In a way, it can be thought of as a prequel to the history of programming languages.
It's also quite relevant for anyone with a morbid interest in those "logical" conlangs that try to divide the world into some sort of rational categories (Lojban, Ithkuil etc.). Though perhaps demotivating for those who attempt to create/learn one ;-)
Also, be sure to read Borges' "The analytical language of John Wilkins" if you like this sort of thing :)
One thing I heard (not sure whether it's true) is that in Ottoman empire, when I child died, parents often used the his or her birth certificate for the next child. That way they could avoid all the associated paperwork.
But as written, the definition permits generating the weird output. Which ignores the other arm of Postel's principle.
You could have the format definition forbid these characters; and then in the section about Postel's principle have "If you choose to accept forbidden characters, you MUST treat them as '?'".
Currently it uses the alignment of the headers as the default. It's only when a field exceeds the size of the header when the output is misaligned. The next record returns to the default alignment though.
I was thinking about adding a 'trim' command that would trim long fields to fit into the default field size.
Tabs are a nightmare to deal with when you want to align the columns. Also, I don't consider tabs to be human readable: They are too easily confused with spaces. (Case in point: make)
Fair enough, I've experienced those pains myself. But what is the strategy with UXY? kind of a semi-fixed-width format that is only partially aligned, but still requires quoting/escaping? I'm not sure it's any better than CSV or PSV (pipe), and it also doesn't interoperate with existing tools.
I'm not attacking your overall idea, btw. I've just given this a bunch of thought myself, and the design space is very tricky. My current approach would be to use ASV (ascii codes 27-31) and abandon 'cat'-based readability in favor of a 'vcat' which gives you a better visual representation. Of course that has its issues too.. :)
The question of intrusive containers is kind of orthogonal. You can implement intrusive containers using generics. Aslo, kernel code would use intrusive containers even if there were easy-to-user non-intrusives available directly in C. The reason, of course, being that with intrusive containers you can avoid huge amount of memory allocations.
