Larch Motivation

The main motivation for this project is simple to state: We want a single, easy-to-use but powerful scientific programming language for two principle uses:

• data analysis
• data collection

Pretty broad, huh? Pretty ambitious?? Perhaps. If we have same language for both tasks and the associated tools to manipulate and visualize the data, we'll have a very powerful combination. While keeping that broad, grand vision in mind, we're also trying to get real work done now, so there are also concrete needs that are the initial goals for Larch:

1. Ifeffit2. The idea here is that the current Ifeffit "shell" and "language" is the main limiting factor for improving and expanding Ifeffit's capabilities.
2. data collection macros for the GSECARS beamline data collection. We know that if we do this right, others will want to use it.
3. data analysis macros for x-ray standing wave, CTR, and XRF data. We don't have the tools we'd like for this.

My initial motivation for writing Larch was Ifeffit2 (see Ifeffit, an EXAFS data analysis program and library). Despite have a very modest command-line interface and macro language (in part because it was written in Fortran77), Ifeffit was fairly successful, in large part of this success is due to it having a command-line interface which can be scripted for interactive, exploratory data analysis and which also gives a simple way for GUI programs such as Bruce Ravel's EXAFS Analysis Codes) to separate the Presentation and Calculation. As an improved version of Ifeffit's base command language, Larch will:

• remove the crustier parts of the Ifeffit "language", and greatly enhance the ability to write decent analysis scripts.
• remove the limitations of using Fortran77 -- especially hard-coded memory limitations.
• improve the graphics.
• make it easier to maintain
• make it easier to add new analysis and data handling features.

A key point is to have a small language for data processing that is not written in Fortran. Instead, Larch is written in Python, and make extensive use of Numpy and Scipy.

Why not use Python (or IPython)

First, I have no complaints about Python -- it is an amazing language and set of tools. I use it now and then myself....

But we don't actually want a complete programming language. In fact, we want something much more tailored for scientific computing and customization - a domain specific language. In fact, the original design wasn't all that close to Python. We ended up with a language very close to Python partly to simplify implementation. We want language features not available in Python (Ifeffit, for example, has a builtin type that appears to be somewhere between a variable and a function in most procedural languages) and we want to not have some features of Python.

Because we're expecting to have novices using this language (novices here being scientists, Graduate Students, Old Professors who may know a little programming -- perhaps some Matlab, perhaps some IDL, perhaps C, or perhaps none of these) but will want to write or modify existing scripts for some data collection or analysis. For this reason, we want to not impose Python's significant whitespace -- we don't want calls at 3am because of indentation problems.

We know Python and IPython are very powerful, and we use them ourselves. That's not the same as saying we want to hand it over to novices for scripting data collection.

Why not Something Else

We looked at a few other options (Octave, R), but were not completely happy with these.

Isn't a Macro Language too hard to write and maintain

The core of Larch is ~2500 lines of code. So, no, it is not too much work.