Once again I have too many projects going on. Here's a summary of the current projects with a quick summary state, more or less in the order in which I would like to prioritize them:

• The Cleaner -- ongoing. Slowly put on pause after vacation, should go back to it.
• NovaScript v1 -- pending. Taking too much time to write tests, not clear of the direction; I had realized that v1 was not what I wanted; since it's still embryonic and experimental, modifying the concept to fit my needs is part of the project goals.
• Google Code cleanup -- not started. Got overall idea, need to follow through.
• Train stuff -- ongoing. Several things: exploring ideas right now, nothing concrete.
• Got the JMRI server part setup so I don't need to make my own.
• Next step is arduino control of one turnout + integrate in JMRI.
• Next step is front panel tablet / wooden console + expand to all layouts.
• This is a long term overall project with many small projects.

I also need to pipeline things better. E.g. for The Cleaner I can finish the widget part and a prototypal customizable UI, then it will be waiting on DK's side. During that time I can focus on train/arduino stuff.

For NS, I need to rethink the whole thing.

The initial design was for an experimental v1 that would not be too useful yet would give me some directions. That's good and the v1 implementation proved interesting and showed some issues, which I addressed as I went, but I need to speed this up if I want to see the rest of the unforeseen issues -- it just takes too much damn time to do it properly.

Since I don't think of v1 has being ultimately so useful, should I probably not focus on "doing it right" and instead cut corners and implement it faster? One issue with that is once I specify a v2 as addressing all the issues found in v1, it will also take forever to do it right unless I can make it an evolution. So whilst I need to speed up v1's implementation, I should not ruin it because I might want it for later.

Another approach: scratch v1 and specify v2 directly, then rework v1 as a subset of v2. Then implement v2, with the optional parts left out at first.

The problem is that the current implementation of v1 has focused on the parser, but that's only a minor part of it. No work has been done on the runtime and the text vs graphical editor and then there's the larger cat-in-the-bag issue of which underlying language to use.