I once worked on a similar-sounding tool, to automate testing of a rather complex component in mobile phone systems. The initial goal was to create a commandline interface so that the testers could do their work. Each command would map back to a Perl function, which could then do whatever the heck it wanted.

However, the testers eventually wanted a way to batch up their commands, similar to how bash or sh does shell commands. So, we implemented a very simple, almost ASM-like scripting language for the application commands.

For most of the users, this was plenty. However, for the power users, we provide an "eval" command, which allowed them, if they wanted, to dig into the internals and do whatever they wanted from a Perl perspective. Of course, it was highly undocumented and required close cooperation from the developer(s).

We found that this was probably the best compromise. You give 100% of the users 90% of what they really end up needing and 90% of the users 100% of what they'll ever need. Then, you allow a safety valve for that 10% of what 10% of the users will want to do.

This is very similar to what Paul Graham describes in his essays on ViaWeb and the RTML language they created. The goal is to minimize the use of the safety valve by tracking what users do and, if they seem to use the safety valve for the same thing over and over, you make it so that they don't need the valve. It ends up being that the safety valve is a way for you to get enhancement requests. :-)

As for Perl itself being the interface ... Perl is a programming language. Unless your users are programmers, Perl is too complex and rich to be a good interface. That was the initial version of the tool I'm describing. A good set of commandline options will do 90% of what's needed. After that, it's just a matter of watching the power users and evolving over time.