Interactive programming

Interactive programming is the procedure of writing parts of a program while it is already active. This focuses on the program text as the main interface for a running process, rather than an interactive application, where the program is designed in development cycles and used thereafter (usually by a so-called "user", in distinction to the "developer"). Consequently, here, the activity of writing a program becomes part of the program itself.

Interactive programming vs. standard programming

It thus forms a specific instance of interactive computation as an extreme opposite to batch processing, where neither writing the program nor its use happens in an interactive way. The principle of rapid feedback in extreme programming is radicalized and becomes more explicit.

Synonyms: on-the-fly-programming, just in time programming, conversational programming

Application fields

Interactive programming techniques are especially useful in cases where no clear specification of the problem that is to be solved can be given in advance. In such situations (which are not unusual in research), the formal language provides the necessary environment for the development of an appropriate question or problem formulation.

Interactive programming has also been used in applications that need to be rewritten without stopping them, a feature which the computer language Smalltalk is famous for. Generally, dynamic programming languages provide the environment for such an interaction, so that typically prototyping and iterative and incremental development is done while other parts of the program are running.

As this feature is an apparent need in sound design and algorithmic composition, it has evolved significantly there. More recently, researchers have been using this method to develop sonification algorithms.

Using dynamic programming languages for sound and graphics, interactive programming is also used as an improvisational performance style live coding, mainly in algorithmic music and video.

Example code

gollark: But you also want to be able to send data up efficiently, but you're probably using much of the limited space for user data which won't get munged by recursive DNS/proxies/whatever on the session token and whatever, so now you have to deal with *that*.
gollark: Possibly? You apply somewhere.
gollark: Basically, send one query to get a session token of some sort, and then repeatedly send queries involving that to get the remaining data. But DNS doesn't guarantee message ordering, obviously, so you need to have sequence numbers and reassemble somewhere and ask for retransmits and all that.
gollark: It would be *especially* annoying to get good performance, but I guess you could just not.
gollark: I know roughly how. It would just be annoying to implement.

See also

References

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.