Sunday, February 14, 2010

Inaugural PEBL Blog Post

In an effort to promote the use of PEBL as a research and testing tool, I've committed myself to creating this blog about various aspect of PEBL (the Psychology Experiment Building Language) and the PEBL Test Battery.  My intent is to update roughly every two weeks for about six months, and after that I'll see.    Look for updates every other Sunday for about six months, and then maybe a slightly slower update schedule.  The blog will contain discussions about programming in PEBL, designing experiments, classic studies we have implemented, and other issues that emerge.

To give a little background into the history of this project, it was conceived during a restless night in Toronto, probably in 2002.  Several things bothered me about the current state of the art in experiment-authoring software.
 1. Nothing useful ran on linux
 2. Researchers seemed all-to-eager to be locked into payware, which to me seems anti-scientific.  Data is pretty useless if you can't reproduce the testing instruments.
 3. Many popular software tools used for experiment authoring violated fundamental aspects of the linear programming steps that experiments usually have.  While object-oriented tools are great for designing interfaces, it quickly made you lose the thread of what was going on, when the response to a click was buried in its own handler function.

I was not too interested in making a lowest-common-denominator visual programming tool that anyone could use, but rather a powerful and focused tool that a diligent grad student could use, and which would be relatively forgiving but attempt to impose some structure on their programs.  Several "innovations" and mimicry of other systems can be attributed to this goal, such as:
  • Case insensitivity after the first character.  How many times have you been bitten by trying to use myVar but instead using myvar?  These are the same in PEBL.
  • No explicit variable definition.  It isn't needed technically, and I saw no need to force people to predefine variables.
  • All-in-one variant data class.  There is no explicit type to need to define
  • Fairly transparent memory management.  Data structures clean themselves up when they are finished being used.
  • Function names and variables are distinguishable just by looking.  Function names start with a capital letter, variables start with a lower-case.  
  • '<-' assignment. It is too easy to confuse the equality test with the assignment character if you have '=' sign.  So in PEBL, the '=' sign does not exist as a legal operator.
  • Large built-in function library focused on experiment-writing.  This includes randomization and visual display functions.  
  • A large (and growing) library of off-the-shelf experiments and tests that can be simply modified.
  • Avoidance of non-linear data structures like 'Trial' 'Block', etc.  From an object-oriented perspective, having a first-class 'trial' and 'block' object that you can simply subclass seems like a great idea.  But from what I've seen, it usually makes the experiment definition MORE complex, and makes it difficult to actually identify what happens when.  Plus, psychology grad students do not necessarily grasp object-oriented metaphors like this.
The current state of PEBL reflects many of these concerns.  So keep watching here to learn more.

1 comment:

iceberg273 said...

We've started using this more seriously in our lab - it took only a few hours to get up to speed and design a functioning experiment (although I will confess a background in [perl] programming).

Looking forward to seeing more here on your blog. Thanks!