28 ms·

I feel the need to be "that guy" cause this is hacker news, but the Unix philosophy isn't really about parsing text streams, it's about decomposability of a pro

I feel the need to be "that guy" cause this is hacker news, but the Unix philosophy isn't really about parsing text streams, it's about decomposability of a problem. It's way easier to test and debug 4 simple programs feeding into one another other like a flow chart than building a mega program with an insane internal state (the your problem can be decomposed into 4 subproblems). The basic core revelation that the Unix folks had was "gee wiz, I seem to need to sort data/open a socket/make a directory super often, and every time I personally try to code one of these operations up it's a huge headache that adds hours to dev time"

dale_glass 4y ago
Everything has good and bad cases where it can be applied of course. But I see this as a good example of a religious issue because you can often find people think that it's a principle worth rigidly adhering to, regardless of whether it actually does produce better results in a given case. For instance my experience is that such a model tends to get bad when things get sufficiently complex. Things like GPG and cdrecord are painful to interact with, and would arguably work much better if they were a library because a text stream is actually a pretty bad communication channel. And sure, I agree that back when Unix was created the model made sense, but it's increasingly less and less relevant.
- tmountain 4y ago
  As the previous poster said, it’s not about text streaming, it’s about composability. One “modern” paradigm that follows the Unix philosophy and has gained a lot of traction is micro services which are mostly viewed positively. You need to extract the idea from its original implementation to apply it today.
- yjftsjthsd-h 4y ago
  > Things like GPG I, for one, would very much prefer GPG to be decomposed to follow the unix philosophy - I think I would have a much easier time understanding and composing commands like `gpg-sign --keyfile ~/mykeyfile somefile | gpg-encrypt --to ~/someperson.pub | gpg-asciiarmor > somefile.gpg` than whatever the monolithic incantation is. This would make it much less painful to interact with, especially because GPG is doing a series of transformations on either streams of text or raw binary.
  - dale_glass 4y ago
    And that'd be awful for many use cases, because maximizing that would make it incredibly unwieldy and brittle. For instance if you want to deal with keyrings, and be fully philosophy compliant, then that might be a gpg-keyring tool, which means now we have a problem. A signature operates on both a key and a file, and a pipe only works on one stream. Then there's the issue with error handling, since any of those bits can go wrong, and then somebody has to figure out a good way of dealing with all of that. Or, we could have libgpg instead, in which case our mail client could avoid screwing around with text streams, signals and process management, and just have a nice API with features like callbacks and well defined datatypes that would be a lot more comfortable to use. EDIT: Even with just the 3 primitives you've outlined, we already can create a huge mess. Is it sign then encrypt, or encrypt then sign? We can combine signing, armoring and encrypting in any order and any amount, requiring the recipient of this insanity to somehow figure out what we did, and then somebody else will do it differently.
    - posix86 4y ago
      You're still on the text streams!!
makeitdouble 4y ago
On the 4 simple programs vs a complex one...I feel this a microcosm of the microservices vs monoliths discussion, which can also devolve into quasi-religious battles.

dale_glass 4y ago

Everything has good and bad cases where it can be applied of course. But I see this as a good example of a religious issue because you can often find people think that it's a principle worth rigidly adhering to, regardless of whether it actually does produce better results in a given case. For instance my experience is that such a model tends to get bad when things get sufficiently complex. Things like GPG and cdrecord are painful to interact with, and would arguably work much better if they were a library because a text stream is actually a pretty bad communication channel. And sure, I agree that back when Unix was created the model made sense, but it's increasingly less and less relevant.

tmountain 4y ago
As the previous poster said, it’s not about text streaming, it’s about composability. One “modern” paradigm that follows the Unix philosophy and has gained a lot of traction is micro services which are mostly viewed positively. You need to extract the idea from its original implementation to apply it today.
yjftsjthsd-h 4y ago
> Things like GPG I, for one, would very much prefer GPG to be decomposed to follow the unix philosophy - I think I would have a much easier time understanding and composing commands like `gpg-sign --keyfile ~/mykeyfile somefile | gpg-encrypt --to ~/someperson.pub | gpg-asciiarmor > somefile.gpg` than whatever the monolithic incantation is. This would make it much less painful to interact with, especially because GPG is doing a series of transformations on either streams of text or raw binary.
- dale_glass 4y ago
  And that'd be awful for many use cases, because maximizing that would make it incredibly unwieldy and brittle. For instance if you want to deal with keyrings, and be fully philosophy compliant, then that might be a gpg-keyring tool, which means now we have a problem. A signature operates on both a key and a file, and a pipe only works on one stream. Then there's the issue with error handling, since any of those bits can go wrong, and then somebody has to figure out a good way of dealing with all of that. Or, we could have libgpg instead, in which case our mail client could avoid screwing around with text streams, signals and process management, and just have a nice API with features like callbacks and well defined datatypes that would be a lot more comfortable to use. EDIT: Even with just the 3 primitives you've outlined, we already can create a huge mess. Is it sign then encrypt, or encrypt then sign? We can combine signing, armoring and encrypting in any order and any amount, requiring the recipient of this insanity to somehow figure out what we did, and then somebody else will do it differently.
  - posix86 4y ago
    You're still on the text streams!!

makeitdouble 4y ago

On the 4 simple programs vs a complex one...I feel this a microcosm of the microservices vs monoliths discussion, which can also devolve into quasi-religious battles.