Programming tasks: design principles

 Top  Previous  Next

This seems like a good point to summarize the three main ways of designing a multi-chamber control system.

 

1. General-purpose language with hardware-specific extensions

 

Example: Arachnid.

 

Pros:

•Programming experience (in the case of Arachnid, with BBC BASIC) applies to completely different applications

 

Cons:

•Independent control of multiple boxes is hard to achieve (with danger of programmer error)
•Very hard to run two different tasks simultaneously, as only a single user program runs at once
•Need to learn specific language

 

2. Custom language designed for operant chamber control; software runs user tasks 'inside' the server

 

Example: Med-PC®.

 

Pros:

•Safe, independent control of multiple operant chambers
•Simple programming language (or even graphical task design)

 

Cons:

•Programming language has restricted capabilities
•Programming experience not useful for completely different applications

 

3. Server and clients are independent programs

 

Example: Whisker.

 

Pros:

•Safe, independent control of multiple operant chambers
•User free to choose programming language for client task (unless a simplifying "super-client" is used)
•Programming experience generalizes to other applications (unless a simplifying "super-client" is used)

 

Cons:

•Need to learn at least one programming language (unless a simplifying "super-client" is used)
•Need to communicate with server (unless a simplifying "super-client" is used)

 

Comparison

 

Options 1 and 3 may entail a choice of programming language (though some examples, such as Arachnid, limit you to just one language). In this situation, there are three considerations: how easy the language is to learn, the merits of the language itself, (including whether it is interpreted or compiled), and how useful the language is applications outside operant chamber control.

 

One of the main dangers of using an interpreted language like BBC BASIC for operant chamber control is that typing and syntax errors may not be discovered until the task crashes with a rat in the box. Compiled languages find all those kinds of bugs before you ever run the program. I strongly recommend the use of compiled languages for all but the most trivial programming tasks when it is very important that the program does not crash.

 

(My [RNC] favourite is C++, the language the Whisker server was written in. C++ is one of the most popular languages world-wide, and for good reason. If you choose to learn and use C++, a fringe benefit is that you will become skilled in a general-purpose programming language, and computers everywhere will become your slave.)

 

The principle 'con' of Whisker's approach is that the user must develop some minimal programming ability in the chosen language. I have attempted to reduce the programming burden by providing libraries of code for different programming languages, so writing a task becomes a more a matter of filling in blanks.