Hacker News new | ask | show | jobs
by jude- 4263 days ago
> But there is already a de facto data serialization in Unix

De facto is a far cry from "required by the OS". You'll notice that the programs we both mentioned (as well as programs that interpret whitespace this way) tend to operate on human-readable text, which uses whitespace to separate words. However, there are many other programs that do not operate on human-readable text, and do not rely on whitespace to delimit records in a pipe (or other file-like construct). Thus, the OS should not try to enforce a One True Record Delimiter, since there isn't one.

> ...and suggest that perhaps there are additional conventions, that if sufficiently simple, could be used to build composable programs that don't need to understand a format that is particular to just one program.

This really is the heart of the matter. There is a trade-off between the specificity of the conventions and the freedom of the program to interpret the data however it wants. UNIX is at (almost) the extreme right end of this spectrum--the only convention it imposes is that information must be represented as 8-bit bytes.

My question to those who feel that UNIX is too far to the right on this spectrum is, what are some conventions that can be adopted universally that won't break composability? I'm not convinced that there are any. Even simple things like requiring programs to communicate via a set of untyped key/value pairs (where each key and value is a string of bytes) would be risky, since it could easily lead to the creation of disjoint sets of programs which only work with members of their own sets (e.g. members of each set would require set-specific key/value pairs).

2 comments

The thing is we're already dealing with disjoint sets of programs and broken composability. Thats why so many shell one liners take the form

  produce-data | munge | invoke-seperate-programming-language | munge | do-something-with-data
I mean we have to do the C->Bash->Awk->Bash->C precisely because nothing actually works together and thats with just text. If we did mandate some IPC and ran across a program that couldn't speak it? Well as long as our smart program had a toString equivalent we wouldn't be any worse off than we are now. But between programs that spoke it we'd be better off.
> The thing is we're already dealing with disjoint sets of programs and broken composability. Thats why so many shell one liners take the form...I mean we have to do the C->Bash->Awk->Bash->C precisely because nothing actually works together and thats with just text.

You seem to contradict yourself :) Yes, you might have to munge some text to get the disparate programs to work together. But, at the end of the day, you get the result you want, because munging the data is possible. Contrast this to a world where munging the data is all but impossible, since each program speaks different objects. Then you'll have some real breakage on your hands, unless you can write O(N^2) inter-object mungers to replace the O(1) text-based mungers you were using before.

> If we did mandate some IPC and ran across a program that couldn't speak it? Well as long as our smart program had a toString equivalent we wouldn't be any worse off than we are now. But between programs that spoke it we'd be better off.

How would this be an improvement? Most programs (i.e. the ones that don't know your "smart" program's IPC object format) would fall back to using the toString() method. The comparatively small set of programs that can use your program's IPC objects would be tightly coupled to each other, meaning a change to the IPC object structure or semantics will require modifications to most/all of the programs. If anything, your proposal exacerbates the "disjoint sets of programs" problem, and has the effect of turning the legacy/compatibility option (toString()) into the ironically future-proof method for interacting with "smart" programs.

Oh, I totally agree that the byte stream should be only stream that the kernel itself is concerned with. I'm merely arguing that there's room, in addition to the current situation, for having more highly structured data streams between Unix CLI utilities. I've had great success with piping binary formats for very specialized use, both for IPC and across the network, and I'd like to see additions to the Unix toolset that take advantage of some of those greater capabilities, in a language- and OS-indpendent way.
> I'd like to see additions to the Unix toolset that take advantage of some of those greater capabilities, in a language- and OS-indpendent way.

Don't get me wrong, I won't turn down structured IPC just because it's structured :) However, I have yet to see an IPC system that (1) gives you more than a byte-stream, and (2) allows for universal composability. Every IPC system I have ever come across sacrifices one of these properties to make gains in the other. While I haven't ruled it out, I'm skeptical (but would love to be proven wrong) that there exists a form of IPC that can meet both requirements.

Dbus.

In the very near future, everything on Linux will be done with dbus.

I sincerely hope you are joking. Dbus-as-IPC doesn't make for composability at all, since each program must be aware of (1) the names and signatures of each other program's dbus-accessible methods, and (2) each other program's behavioral semantics with respect to the method invocation.