Hacker News Reader

Comment by zeveb | Hacker News Reader

Honestly, I don't know if the rule of silence is actually all that good of an idea. Unix already gives us stdout vs stderr; it's one thing not to write useless information to stdout, but it could be useful to have a stdinfo or stdlog or what-have-you.

Granted, with too many options it could quickly get confusing (should this message go to stdout or stdinfo; is that message more informational or more debugging?), but I think that it could be managed.

Similarly, I think that Unix fell down by relying too much on unstructured text (in the sense that the structure isn't enforced, not in the sense that it's altogether absent): because of this, every single tool rolls its own format, and even very similar formats may have subtle incompatibilities.

I'd love to see a successor OS which builds on the lessons of Unix, Plan 9 and other conceptually brilliant OSes, but I fear the world will never see another successful operating system.

View on HN

> Similarly, I think that Unix fell down by relying too much on unstructured text

This is what made Unix last. Text and keyboards are the universal computing interface that has survived since the 1970s.

Note that I'm not arguing for structured binary data. Structured text (e.g. s-expressions, JSON, even the-extensible-structured-text-format-which-shall-not-be-named) can last just as long. Indeed, S-expressions have existed since the 1950s.

There's no particular reason why /etc/passwd couldn't be:

    ((root nil 0 0 root /root /bin/bash)
     (daemon nil 1 1 daemon /usr/sbin /usr/sbin/nologin) …)

There are any number of similar dialects which could be used, of course, but the principle is obvious.

What would your example achieve? You're making the format more verbose and error-prone (someone might easily forget to match a paren), without imposting any additional structure over what is already implied by line breaks.

Though I do agree with your overarching point that some of the formats/outputs could do with a more consistent structure. Perhaps something like YAML would strike a good balance between structure and conciseness/readability...

The example is not really interesting, because as you said there is already a simple structure. But programming with text becomes really tiresome after a while. For example:

    git blame -L ${LINE},+1 --porcelain ${FILE} | sed -n '/^author / {s/^author //; p}'

I would rather:

    (name (author (first (git blame file :line line))))

... where git blame returns a sequence of "blame" data for which I can retrieve the author easily (if you prefer pipes over function composition syntax, use threading macros). Then I don't have to worry about strange characters crashing my scripts randomly. Suppose I forgot to add the "^" symbol in my regexp (I can assume this, since you assume people forget parentheses), there could be situations where I would match too many lines.

> You're making the format more verbose and error-prone (someone might easily forget to match a paren), without imposting any additional structure over what is already implied by line breaks.

It's already error-prone (as anyone who's ever incorrectly edited /etc/passwd knows).

Ultimately, structured data (which is pretty much all data) should be edited with structure editors. Good text formats make it easy to write such structure editors.

> What would your example achieve? You're making the format more verbose and error-prone (someone might easily forget to match a paren), without imposting any additional structure over what is already implied by line breaks.

That particular example is fairly straightforward (at a simple level, passwd files aren't complex), but being able to express arbitrary nested structure would make various things a lot more straightforward. Line breaks and some sort of tab/colon/what have you work fine if everything has at most two levels of hierarchy, but it starts being painful after that.

Missing matched parens are a bit of a specious argument, since many of the random formats for files are fairly strict about what they parse, and the ones that matter (e.g. passwd, sudoers, crontab) are conventionally edited through tools that check the syntax before committing.

Maybe you shouldn't use arbitrary nested structures where you can go without?

Beyond text, structured data can give you actual functions or object instances. You can inspect a path object without dealing with escaped slashes, etc. For example, that's how I understand the "capabilities" security model: once you authenticate, you get an object which allows you to perform some tasks (https://en.wikipedia.org/wiki/Capability-based_security).

But column-oriented output is still structured and tools like AWK are meant to be a "programmable filter" on it. Reading or outputting deeply nested structures like JSON or S-exps would make it less practical to pipe programs together and instead have big "monolithic filters" with lots of options.

Parsing columns of text with awk or any other text tools is vexingly problematic. How do you even define "column"? What if columns contain whitespace? How do you differentiate that from the whitespace between columns?

That just illustrates the limitations of the pipe abstraction, as something only able to send sequentially-read unstructured data.

Also, jq, jshon and similar tools are a thing.

> This is what made Unix last.

An unfortunate turn of phrase. It's ambiguous. Do you mean last as in "endure"? Or do you mean last as in "last place"?

both :-D.

Emphasis "are". Still.

There are tons of good things to be said about "the unix philosophy". The Philisophy itself is good (do one thing, play nice together) but the implementation is crap to be honest.

The worse thing about the unix philisophy implemented as a unix shell environment is that programs (often) have only one interface, and that's used both for interactive use and as a programming API. This means, for example, that when we realize git version N has terrible default behavior given some arugments, we can't fix the behavior of those arguments t in git version N+1 because we would break it's API.

And yes of course - structured in/out, sane encoding handling etc. is just missing.

If looking at the history of tech, but als the general history of humanity, has taught me anything, it's that assuming the current systems will never fall and be replaced will always end up making you look like a fool eventually.

To paraphrase Keynes, in the long run we are all fools. (Except for Alan Kay, apparently)

Reply on news.ycombinator.com