I was letting my mind wonder a bit this evening about how far one could take the idea of example base programming in order to make the programming process more concrete. It seems natural to think of one or more concrete cases, then deduce abstractions from there, so why not allow the system to cooperate in the entire process. Let me try to explain what I mean.
Query By Example (QBE) is a heavily used and long established concept whereby the user provides an example of what data she seeks. One could argue that modern search engines are in fact a form of QBE. QBE was used successfully as a database query language in what used to be Borland's Paradox. In a database context QBE is usually done only in a user interface context through a set of fields with allow the user to "filter" the dataset. Paradox took this much further and defined a complete language in which to express even complex disjunctive queries. When working in Paradox and even afterwards, I would often build queries in QBE, then ask Paradox to translate them into SQL, as I found QBE to be easier and more natural in many cases.
Thinking about the analogue of QBE for programming, a common case comes to mind: test scripts. QA engineers often use software that allows them to record a series of actions against a piece of software, then go back to the resulting scripts and randomize or parameterize whatever aspects. This is a process of taking a concrete imperative process, and making it abstract and reusable.
The questions is: could there be value in this for "regular" programming? When we program, it seems we already undergo this exercise in our minds. It seems that we "play" algorithms in our minds, considering the various boundary conditions and possible variable states. If, rather than just thinking this way, we could state concrete "executions" to the system, then inform the system that we wish certain constants to be variable, then perhaps the system could enhance the process.
Still a "thought in progress" to be sure...