3 ms·

You've heard of the Unix philosophy? Small programs that do one thing well. Composeability, so you can combine programs to make new functionality. Rather than

You've heard of the Unix philosophy? Small programs that do one thing well. Composeability, so you can combine programs to make new functionality. Rather than build one console app that has 50 features, you build 10 console apps with 10 features each. The complexity of each component stays small while your capabilities as a user grow and grow. This worked originally as the Unix designers were free to organize their code however made sense according to their philosophy. But Conway's Law comes into play in organizations, where there is always a hierarchy centred around one or two main products. Rather than one or two people making 10 different apps, it's multiple teams making a couple apps each. They don't communicate between each other well or understand the other components, and it all has to fit inside one program.

capableweb 5y ago
> You've heard of the Unix philosophy? Small programs that do one thing well. Composeability, so you can combine programs to make new functionality. That makes sense in terms of CLI utilities where text/files is the standard input/output, or APIs where json/xml/format-of-today is the standard input/output, but how would you do this with GUI tools? I'd love it if there was a solution, but I'm not aware of one. Many suites of software use a standard format for things (like .obj/.fbx for graphic object/animation, or .wav for music production), but there is usually not a pipeline as in "pipe this output from this software into that input to that software" like we do with CLI utilities, and if there is, that pipeline is not standarized nor open for extension. Will it ever be possible? I hope so, but I don't see how it can be right now.
- throwaway984393 5y ago
  Linux GUI apps use DBUS to communicate between each other. (I'm not a fan of it but it's better than nothing)
  - capableweb 5y ago
    As a comparison against traditional unix pipes (or even sockets), how does DBUS handle sending/receiving a lot of data? I always got the impression DBUS is more for notification style message passing, not actually for sending data, so you'd send a message saying "fetch the data from this socket" rather than "here's a bunch of data for you".
    - pas 5y ago
      You can use DBus to call a remote procedure and pass the path of a temp file where the real data is. (You can pass actual file descriptors too.) That said DBus is pretty fast. Basically somewhere around 25-30% of TCP. https://blogs.gnome.org/abustany/2010/05/20/ipc-performance-the-return-of-the-report/ https://blogs.gnome.org/abustany/2010/05/20/ipc-performance-...
- tech2 5y ago
  An option here might be things like COM and DCOM. Individual, possibly embedded, components and a well defined communications mechanism. Historically the Amiga was quite nice here with systems using AREXX to communicate (but not embed), and Linux/POSIX has things like DBUS for the same (but less flexibly since there's no middleware between the two for coordinating control between systems, the components need to know about one-another directly - kinda).

capableweb 5y ago

> You've heard of the Unix philosophy? Small programs that do one thing well. Composeability, so you can combine programs to make new functionality. That makes sense in terms of CLI utilities where text/files is the standard input/output, or APIs where json/xml/format-of-today is the standard input/output, but how would you do this with GUI tools? I'd love it if there was a solution, but I'm not aware of one. Many suites of software use a standard format for things (like .obj/.fbx for graphic object/animation, or .wav for music production), but there is usually not a pipeline as in "pipe this output from this software into that input to that software" like we do with CLI utilities, and if there is, that pipeline is not standarized nor open for extension. Will it ever be possible? I hope so, but I don't see how it can be right now.

throwaway984393 5y ago
Linux GUI apps use DBUS to communicate between each other. (I'm not a fan of it but it's better than nothing)
- capableweb 5y ago
  As a comparison against traditional unix pipes (or even sockets), how does DBUS handle sending/receiving a lot of data? I always got the impression DBUS is more for notification style message passing, not actually for sending data, so you'd send a message saying "fetch the data from this socket" rather than "here's a bunch of data for you".
  - pas 5y ago
    You can use DBus to call a remote procedure and pass the path of a temp file where the real data is. (You can pass actual file descriptors too.) That said DBus is pretty fast. Basically somewhere around 25-30% of TCP. https://blogs.gnome.org/abustany/2010/05/20/ipc-performance-the-return-of-the-report/ https://blogs.gnome.org/abustany/2010/05/20/ipc-performance-...
tech2 5y ago
An option here might be things like COM and DCOM. Individual, possibly embedded, components and a well defined communications mechanism. Historically the Amiga was quite nice here with systems using AREXX to communicate (but not embed), and Linux/POSIX has things like DBUS for the same (but less flexibly since there's no middleware between the two for coordinating control between systems, the components need to know about one-another directly - kinda).