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.

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.

> 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.