Post History

I'd like to move the frame out a little and use that as a discussion for how to make these decisions.

## Input models

You've listed two input models, but I think we need to add a third before we begin. I'm going to call them

1. Command line arguments
2. Interactive read at run-time
3. Non-interactive read at run-time (either from standard in or from a file)

The interactive form  of reading at run-time involves your program printing prompts and expecting answers that may change what prompts are coming, and seems to be your second. The non-interactive version may involve parsing some input language but does not involving prompting. 

## Multiple kinds of input

It is common for a program or script to manage two kinds of input:

1. Some data that is to be processed
2. Instructions about how to process the data or what output to produce

which means that we may want to use more than one class on input in a single tool.

## Unix model

I'm going to discuss how to make the decisions under the assumption that we're talking about a Unixish model of how tools (whether built-in, written in some compiled language, or scripted) work together. In other words we're assuming that your input may come from another program and your output may go to a third.

This implies that the data to be processed should be accessible through non-interactive reads because getting two programs to synchronize a ask-answer sequence is a pain.

You *may* also want to provide a way to specify the data on the command line or even an interactive front-end but those are optional flourishes: non-interactive reading is the core approach for the data you are processing.

Control of how the data should be processed and output produced should be distinct from the main data. This is a prime use-case for command-line arguments. You might also get it from a non-interactive read but if so it comes from different source than the data (perhaps data on standard in and switches in a a config file). Interactive management of the switches is fine, but should be optional because we still want to be able to use the tool in a chain of computations (which means without user intervention).