8 ms·

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

by zeveb 10y ago

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.

cyborgx7 10y ago
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.
- stevedonovan 10y ago
  To paraphrase Keynes, in the long run we are all fools. (Except for Alan Kay, apparently)
bluetomcat 10y ago
> 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.
- zeveb 10y ago
  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.
  - setrofim_ 10y ago
    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...
    - junke 10y ago
      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.
    - pherq 10y ago
      > 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.
      - 10y ago
- fnj 10y ago
  > 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"?
  - qwertyuiop924 10y ago
    both :-D.
- ArkyBeagle 10y ago
  Emphasis "are". Still.
alkonaut 10y ago
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.

by zeveb 10y ago

cyborgx7 10y ago

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.

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

bluetomcat 10y ago

> 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.

zeveb 10y ago
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.
- setrofim_ 10y ago
  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...
  - junke 10y ago
    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.
  - pherq 10y ago
    > 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.
    - 10y ago
fnj 10y ago
> 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"?
- qwertyuiop924 10y ago
  both :-D.
ArkyBeagle 10y ago
Emphasis "are". Still.

alkonaut 10y ago

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.