3 ms·

Hot take: the 'UNIX philosophy' is stuck in the 1970s. It was the only practical compromise when computers were constrained to kilobytes of memory (at best) and

Hot take: the 'UNIX philosophy' is stuck in the 1970s. It was the only practical compromise when computers were constrained to kilobytes of memory (at best) and a megabyte of storage (at best).

wakawaka28 2y ago
No, the UNIX philosophy persisted since the 70s because it is great default philosophy for building software. Not all kinds of software but most, I'd say. Doing one thing well plus all the other stuff (like preferring plain text output) means that users can easily assemble whatever they need. When applications are doing only one thing, you can thoroughly test them as well and enjoy a level of security that monolithic programs have to add via sketchy hacks. And when a monolithic system is compromised, it is a bigger threat than one with smaller scope.
- dale_glass 2y ago
  Yeah, that works best in the 70s. With modern software it's a pain in the butt. Remember CD burning software? That at least used to invoke cdrecord underneath, and whenever that went wrong it was awful, because text is an awful interface for a complex system. Today you'll find many things that actually "de-UNIX-philosophy" stuff, by making a library that wraps around an invocation to a complex tool and presents what 99% of users actually want -- a library style interface.
  - hulitu 2y ago
    Then why do we need binaries when we have ld.so ?
  - wakawaka28 2y ago
    A GUI program invoking a program not designed to be a GUI in the laziest fashion is fringe example. Such a GUI would have been a herculean feat to implement if the authors could not piggyback off of an existing, simple tool. If the GUI authors really wanted, they could have tried to parse the output of cdrecord and/or contribute to making the output of cdrecord suitable for easy processing. >Today you'll find many things that actually "de-UNIX-philosophy" stuff, by making a library that wraps around an invocation to a complex tool and presents what 99% of users actually want -- a library style interface. There are tradeoffs to this simplicity. Your "library" is most likely a pain in the ass to use even for people using the same language, much less other languages. The output and invocation of a simple program is less likely to add a breaking change than its code. Do you think libraries were just invented, or what? I like the idea of making the library first and then using that to build a tool. But that may not make sense in all cases, and it's extra work as well. For people using other languages, or trying to write simple shell scripts, a library alone is not going to work.

Hot take: the 'UNIX philosophy' is stuck in the 1970s. It was the only practical compromise when computers were constrained to kilobytes of memory (at best) and a megabyte of storage (at best).

wakawaka28 2y ago

No, the UNIX philosophy persisted since the 70s because it is great default philosophy for building software. Not all kinds of software but most, I'd say. Doing one thing well plus all the other stuff (like preferring plain text output) means that users can easily assemble whatever they need. When applications are doing only one thing, you can thoroughly test them as well and enjoy a level of security that monolithic programs have to add via sketchy hacks. And when a monolithic system is compromised, it is a bigger threat than one with smaller scope.

dale_glass 2y ago
Yeah, that works best in the 70s. With modern software it's a pain in the butt. Remember CD burning software? That at least used to invoke cdrecord underneath, and whenever that went wrong it was awful, because text is an awful interface for a complex system. Today you'll find many things that actually "de-UNIX-philosophy" stuff, by making a library that wraps around an invocation to a complex tool and presents what 99% of users actually want -- a library style interface.
- hulitu 2y ago
  Then why do we need binaries when we have ld.so ?
- wakawaka28 2y ago
  A GUI program invoking a program not designed to be a GUI in the laziest fashion is fringe example. Such a GUI would have been a herculean feat to implement if the authors could not piggyback off of an existing, simple tool. If the GUI authors really wanted, they could have tried to parse the output of cdrecord and/or contribute to making the output of cdrecord suitable for easy processing. >Today you'll find many things that actually "de-UNIX-philosophy" stuff, by making a library that wraps around an invocation to a complex tool and presents what 99% of users actually want -- a library style interface. There are tradeoffs to this simplicity. Your "library" is most likely a pain in the ass to use even for people using the same language, much less other languages. The output and invocation of a simple program is less likely to add a breaking change than its code. Do you think libraries were just invented, or what? I like the idea of making the library first and then using that to build a tool. But that may not make sense in all cases, and it's extra work as well. For people using other languages, or trying to write simple shell scripts, a library alone is not going to work.