Oh, very nice and chewy. I look forward to reading parts 2 and 3.
Before your puzzles, I had never noticed how in ‘A depends on B’ utterances, B rarely contains a verb — and therefore B rarely takes the form of a proposition you can check. ‘Does the task tunner depend on the tasks?’ Maybe.
‘The task runner — does it depend on tasks having function signature () -> TaskResult?’ Mmmaybe, but perhaps A needs a verb, too?
‘The task runner runs the tasks; this depends on the tasks having signature () -> TaskResult’. Proposition A’s truth depends on proposition B’s truth — now we’re getting somewhere?
Don’t mind me, just musing.
Very nice, I’m looking forward to the next parts. Please post them as individual stories here too so we can get notified when they’re out.
I think one problem is that we use a single overloaded term for different meanings. Saying an application depends on a library may mean it’s pulling it in, but it doesn’t necessarily mean the application absolutely needs it (sometimes called “optional dependency” - a good example would be using, say, memcached to optionally cache things for performance).
Or if the dependency isn’t optional, it may use one of several workalikes so it only “depends” on the more abstract interface being present but not on any particular implementation of it (though it wouldn’t function without such), like for example using a db abstraction so you can use either MySQL, PostgreSQL, Oracle or MS SQL. It depends on a database, but doesn’t care which. I don’t think we have a good term for this kind of “loose”cdependency.
The example of the scheduler is a bit off - I wouldn’t say it depends on its tasks - it just operates on them, I’d see it as input. Of course it does depend on a specific representation of such tasks. Same with the file format - it is output for one application and input for another, which means they both depend on the format, but not really on eachother. If the format is simple enough, it could be read by a human (removing the need for program B) or written by a human (removing the need for program A). The more complex the format is, the more “dependent” both programs become on eachother as they can’t be easily replaced.
So perhaps we should stop thinking of dependency as a binary state, but rather as the degree of “removability” or “replacability”. If a program’s source code can be trivially changed to use a different implementation of some “dependency” (perhaps there’s one invocation of a UNIX tool which can be changed to call another), I wouldn’t say it has a very hard dependency on that thing, even if it cannot be configured by an end user.