4 ms·

I dont think unix was every truly about byte streams. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs

I dont think unix was every truly about byte streams. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". Is the core point. Later editions went on to specify text as the preferred language for these programs to communicate in but I don't think that's key to upholding the unix philosophy. It was just the easiest to work with at the time We just need to agree upon a common framework for these programs to communicate with. There will definitely be a lot of churn though

jbverschoor 5y ago
> Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". That's a quote from '78, by the Doug McIlroy, the inventor of Unix pipes. Pipes are exactly that... reading and writing bytestreams. Also him: - (ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. Later: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. (https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s...) I mean come one. "ls" grew from a simple tool with 11 parameters to 58 parameters. source: https://news.ycombinator.com/item?id=29568042 https://news.ycombinator.com/item?id=29568042 / https://danluu.com/cli-complexity/ https://danluu.com/cli-complexity/ This only happens because people are scripting in their ui. They shouldn't. "Unix admins" laugh at people who do the exact same things within office or other GUI solutions. Using "text streams".. yes, for performance, a stream is better. Same with SAX vs DOM. nobody likes SAX

jbverschoor 5y ago

> Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". That's a quote from '78, by the Doug McIlroy, the inventor of Unix pipes. Pipes are exactly that... reading and writing bytestreams. Also him: - (ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. Later: Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface. (https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s06.html https://homepage.cs.uri.edu/~thenry/resources/unix_art/ch01s...) I mean come one. "ls" grew from a simple tool with 11 parameters to 58 parameters. source: https://news.ycombinator.com/item?id=29568042 https://news.ycombinator.com/item?id=29568042 / https://danluu.com/cli-complexity/ https://danluu.com/cli-complexity/ This only happens because people are scripting in their ui. They shouldn't. "Unix admins" laugh at people who do the exact same things within office or other GUI solutions. Using "text streams".. yes, for performance, a stream is better. Same with SAX vs DOM. nobody likes SAX