The creation of a little language might seed a minefield in your organization. If it is successful, it will grow into an unmanagable monster. If it fails, it is a waste of time. It is unlikely that you will create a little language that will be 'just right' for your users.

I have dealt with many proprietary languages, big and small. They are usually painful. Common problems include poor development environments, scant documentation, lack of support, and confusing error messages.

Little languages are fine for throw-away code, but they don't fare well when you try to use them in a workgroup. Worst case, they are successful and grow. The organization finds that it is difficult to hire and retain employees to write this type of code. The author of the system has a continuous four-deep line of people at his desk waiting for debugging help! Hundreds of commands get added to the system for each new requirement. None of them are documented, but if you change one of them, someone's critical code will break. I could go on and on with stories of pain and suffering. Don't go there!

When you are creating a system for novice programmers, ask yourself, "How am I going to get out of this?" In computer science terms the question is "What is the life cycle for the users' programs?"

You need an exit strategy!

I recently had the same problem of needing a little language. My tactic is to create an XML representation of the code. So a program in the 'little language' is actually an XML document. One advantage is that I don't have to write a parser. Also, the XML parser usually deals well with syntax errors. Typically it provides both the line number and the character position of an error.

The computer science guys are happy with my system because it will be reasonable for them to port the code in the future. Working with XML is acceptable on the resume. Maybe it will provide them with an excuse to learn .net!

The non-programmers that are using the system like it because it looks something like HTML, which they consider doable. Mostly they just imitate my examples.

The managers are happy with the program because it solves the immediate problem without creating obvious new problems. They can put "learn XML and .net" in some hotshot's software developer's development plan and everyone will be happy. XML is still a management-compliant buzzword this year. In my case, perl is just an implementation detail of a prototype.

If my little language starts to become successful, I can make a one-way translator to perl, port the code, and then just support that. Maybe someone else will port the XML to some other language.

It should work perfectly the first time! - toma
msg me with suggestions for this node. I am interested in improving readability and adding details.