Example Oriented Programming

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

Comments

Post a Comment

Popular posts from this blog

Don't Repeat Yourself... Really!

...And I hope that someday That you, you people will all have the chance To read The Helping Friendly Book And experience the wisdom Of the great, the great and knowledgeable Man who wrote The Helping Friendly Book  Because he is, the great and knowledgeable He is the one, the only author of The Helping Friendly Book He is the man The great man The only, the special His name is The author of The Helping Friendly Book He is the great The knowledgeable, the one and the only The great, the knowledgeable Person who wrote The Helping Friendly Book His name could only be The one, the only, the only, the special The author of The Helping Friendly Book... -Excerpt from Icculus by Phish There are few mantras that are as universally agreed upon by Software Engineers as Don't Repeat Yourself or DRY.  It rings deeply and globally true that any form of code duplication is at best a compromise, at worst, an abominable trap.  Writing and maintaining code is d
Read more

Issues raised by polymorphism in relation land

I continue to ponder how to merge the Relational Model (RM) and Object Oriented (OO) worlds in order produce a best-of language. The task is a challenge due to the deep and fundamental differences between OO and the RM. One approach I am exploring is to utilize the notion of multiple logical representations to allow both to co-exist without compromise. Doing this, though, means pinning down canonical isomorphisms between the two models. One important concept from the OO world is polymorphism. In OO land, we identify a useful abstract concept like "Contact" and build a class around it. We then build classes for more specific types of contacts such as Organization and Person. A challenge for me has been to identify a clearly obvious equivalent to this design in relation land. This has proven quite elusive because there are several relational designs that seem to qualify. The design that seems most commonly used involves a "type" table of some sort followed by tables c
Read more

Camtasia Studio Tips

Camtasia is great software for recording audio/screen presentations.  Here are some tips and standards we've used: Recording Change the recording options to record to ''AVI format'' (the CAMREC format can lose audio/video sync over a long recording) Recorded movies should be 800x600 or less unless there is a specific reason to record larger.  Using the smallest capture size possible improves the readability and reduces the file size. All videos should start with an announcement of what is being demonstrated (e.g. "This is a demonstration of the Device Capture System introduced in Cashwise 3.7) Don't record the application window; set one of your screens to 800x600 and record the screen.  This ensures that any popup windows or menus remain within the recorded region. If recording other than the primary screen, select 'region' and select then entire alternate screen Hide any toolbars or other desktop clutter. Run a short test to be sure that
Read more