You are absolutely right. In C++ you could make this an inline member function and turn all those local variables into member variables. That would make it a clean function call with the struct as a single parameter. Hmm, in C you could possible package all those local variables into a local struct which could then be passed as a single argument to in inline function?

When trying to illustrate by example my super-duper library, I found that in addition to this being surprisingly difficult, also that (1) parts of my interface were illogical and (2) a huge chunk of functionality was missing. So, I had to go back to the workbench and code. Six months later I found it a lot easier to write the examples and instructions. It seems that test-first gives your code one kind of perfection, while explain-at-last will take your code to yet another level. Thus the two cycles, test-code and explain-code, seems to complement each other.

Oh, now I get it. You are right.

There are setwd(path) and getwd(path) functions for setting the working directory (i.e. the folder from which any relative path would be rooted) but there is no way of finding out from where a script was loaded. That makes it cumbersome to distribute R scripts as an assemblage (e.g. a zip file) of interconnected R scripts and data files. The user must be instructed to call setwd(path) in the beginning of the main script with the folder of her choice. The same goes for yourself when you move your assemblage of R files from one folder to another; you always need to update the setwd(path) statement as well.

In R: A function that returns the path to where the R script was loaded from.

This rather old book introduced me to DI: Dependency Injection in .NET[^]. Even though I don't program in .NET (or C#), I found it very inspirational. It offers a critical stance towards DI (on which I completely agree), while introducing and explaining the concepts.

(1) 44.74 s (!) (2) 5.30 s Accessed from a superfast, optical connection.

Since this is turning complex anyway, let the user benefit from it:

(1) Define all your functional bits as separate classes.

(2) Create a set-up form, which lets the user define his own forms.

(3) Set up the four standard forms yourself to get the user started.

(4) Consider creating a domain-specific language (DSL) to define your set-up. Easy now! This should just be a very simple declarational script with your own syntax. This will allow you (and superusers) to whip out customised forms. Your set-up page (2, above), of course, creates a DSL-script under the hood. The DSL, by the way, makes testing straightforward. The DSL is parsed to create an object tree representing your form.

The user gains flexibility, and you are relieved from hard-coding specific permutations of all the functional bits. -- And the time spent coding will be fun!

Qt Creator. It works across platforms and is open source (if your code is open-source). It supports many toolsets. I use it to build an app for Windows, Mac OS and Linux from the very same source code.

I note that code-signing has appeared as a side issue: I tried many different companies (I forgot their names, except the last failed attempt which was GoDaddy). Finally, GlobalSign let me have a functional license (based on a USB token, very simple to operate) without an endless discussion of my identity and with super hotline service too.

I am using Qt Creator as an IDE with gcc toolkit running underneath, both on Windows and Linux Ubuntu. Will continue with same tools on Mac OS soon. I use this for the UniSim open-source project http://www.ecolmod.org/[^] maintained at GitHub.

Niels Holst, Aarhus University, Denmark