4 ms·

I think the Unix philosophy would have you pipe those beeps to another program that does your calendar integration.

xyzzyz 9y ago
You'd still need to write the glue code that correctly maps one program's output to the other program's expected input. I don't see how this is materially different. If by "Unix philosophy" you mean creating modular software, then sure, we're already doing this. If you mean pushing unstructured ASCII data through actual pipe(2)s, then I'm sorry, but this is not a workable solution in 2017.
- Nullabillity 9y ago
  > You'd still need to write the glue code that correctly maps one program's output to the other program's expected input. I don't see how this is materially different. But you shouldn't need to be that person.
- zachrose 9y ago
  Unix philosophy also seems to assume that the users and developers of the beep software are different people with different priorities than the calendar app people. I think the crux of this discussion is whether you are in one of these camps or you're trying to sell a holistic solution to their beeping calendar needs. The latter will never be done because holism means being tenderly connected to a changing world. But in terms of pipes, it seems like the 2010s version would probably be JSON over HTTP.
- lgas 9y ago
  Well, part of the difference is that now the "beep" program can be considered finished and other people can use it piping it to whatever programs they want, and it will never (or at least rarely, compared to the monolithic approach) need to be updated because all it does it beep. If and when it does need to be updated it will be much easier to update because all it does is beep, so it doesn't include a calendar library and so on. It won't have to be recompiled when the calendar library is updated, etc. You have to do the same amount of work overall to get the same end results but the individual pieces can stabilize and be used independently.
tmaly 9y ago
it would be interesting if a protocol could be used in this case to serve the idea of a pipe

You'd still need to write the glue code that correctly maps one program's output to the other program's expected input. I don't see how this is materially different. If by "Unix philosophy" you mean creating modular software, then sure, we're already doing this. If you mean pushing unstructured ASCII data through actual pipe(2)s, then I'm sorry, but this is not a workable solution in 2017.

Nullabillity 9y ago
> You'd still need to write the glue code that correctly maps one program's output to the other program's expected input. I don't see how this is materially different. But you shouldn't need to be that person.
zachrose 9y ago
Unix philosophy also seems to assume that the users and developers of the beep software are different people with different priorities than the calendar app people. I think the crux of this discussion is whether you are in one of these camps or you're trying to sell a holistic solution to their beeping calendar needs. The latter will never be done because holism means being tenderly connected to a changing world. But in terms of pipes, it seems like the 2010s version would probably be JSON over HTTP.
lgas 9y ago
Well, part of the difference is that now the "beep" program can be considered finished and other people can use it piping it to whatever programs they want, and it will never (or at least rarely, compared to the monolithic approach) need to be updated because all it does it beep. If and when it does need to be updated it will be much easier to update because all it does is beep, so it doesn't include a calendar library and so on. It won't have to be recompiled when the calendar library is updated, etc. You have to do the same amount of work overall to get the same end results but the individual pieces can stabilize and be used independently.

tmaly 9y ago

it would be interesting if a protocol could be used in this case to serve the idea of a pipe