in reply to Perl Script Engine

Don't do it. Keep a loadable Perl module and keep the coding in baby Perl, and there will be few problems.

I once tried, foolishly, to do exactly what you said for writing an automatic test system. It even had while loops and for loops! I spent over half my time writing the parsing system (it ended up being rather cool), but guess what? Everyone was still afraid of the meta-language I invented, and when I had to write test cases, I missed the ability to use real Perl. Might as well just left everything in Perl and it would have been tons easier to maintain.

My other mistake was farming out some of the development to an intern, who tried to add OO-style functions to everything, and he really didn't grasp nested data structures. Between that and the ugly meta-language code he wrote, it was a total mess. And because it wasn't all Perl, it was hard for me to remember how to refactor that meta language code he wrote and clean it up.

My advice is to keep things simple, provide a lot of well documented utility functions, and do this in baby-Perl. Baby-perl is just as readable as shell script, if not more so. The implementation of the the utility functions themselves can be as Perlish as you like. Non-Perl programs may need a scripting language, but Perl already has great use at doing that.

Off-topic: anyone have experience embedding Lua in C programs? Did you like the results?

Replies are listed 'Best First'.
Re: Re: Perl Script Engine
by Anonymous Monk on Jan 30, 2004 at 22:13 UTC
    The more I think about it, the more right you are. I think I'm just going to concentrate on writing clear clean maintainable perl. But I like the idea of using XML as the configuration format Thanks for all of the useful comment Dave