Not Just Function Composition, But Application Composition

When we were discussing the magical number seven, I mentioned that it made more sense to actually call the functions in sequence instead of each calling the next. That's basically a "function composition", one thing you can also do with your applications.

Unix came with the idea of "applications that do one thing and do it well". And then you could just pick the output of one application and plug it as input of another (and then plug the output of the second into a third, and so on).

Also, I mentioned that you could use configuration files to do the same processing over different source elements (based on a configuration, that is) instead of writing an application that would process both in a single shot.

One problem with that approach is that you may need both results to actually produce a usable result (for example, how would you build a list of common followings of two Twitter users if you don't have both lists?).

That problem can easily be solved if you write a different application that just receives both lists and compare them. That would greatly simplify your general codebase 'cause instead of one massive codebase with lots of moving pieces, you'd have two small codebases, with less moving pieces. One could still break the other -- say, if you or someone else changes the result of the first function -- but you will still get the results of the first without missing the whole 'cause the second is breaking.

PS: I reckon it's really hard to create application composition with graphical applications (why would you ask your user to have two applications open at the same time to make something work?) but you can extrapolate this for almost everything else.