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.
1 comment:
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!
Post a Comment