Embedded Perl or Python (XPost)

[Chris]

Hi Cameron

Thanks for the interest.

when I say smallest footprint its because to me size does matter :)

I like my apps to be as small as possible for easy delivery. 

So for example if PERL "requires" the whole package to be present then
it would be too bloated 

I would like just a small as possible DLL or possibly statically link
the interpreter into my app with minimum external files

so my concerns are 
can it be done 
which will do it better
which will be faster. (some of the scripts will be called many times so
compounding speed is an issue) can I precompile to decrease load times ?
which will be the smallest in size?


Chris

claird at lairds.com (Cameron Laird) wrote in
news:vlgkb4dtchna9e at corp.supernews.com: 

> In article <c907a3eba2b531449c8dc7a212285911 at news.teranews.com>,
> Chris  <rebel at removethis.rebel.com.au> wrote:
>                .
>                .
>                .
>>I am developing a software project where a major portion of it is to 
>>enable script access to c++ classes  
>>
>>The idea is to extend the basic functionality of the program by
>>allowing third parties to write add ons that are called by my c++
>>classes as virtual functions.
>                .
>                .
>                .
>>Given the above which interpreter is most likely to fit my bill with
>>the smallest footprint ?
>                .
>                .
>                .
> Let's be clear on what we're discussing.  When you write,
> "smallest footprint", do you seriously mean, "creates the
> smallest differential in the size of the resulting exe-
> cutable image"?  Frankly, that would surprise me; your
> project sounded interesting and useful up until those 
> last two words.  I don't mean to be harsh; unless there's
> something you're not telling us, though, the size of 
> executables-as-file-images is quite unlikely to be even
> the tenth most important aspect of your target.
> 
> I'll anticipate a bit more, and observe that Python is
> likely to be the better choice, because it remains easier
> for a newcomer to extend-or-embed (it's not clear that
> you've decided between these alternatives), at least until
> Perl 6 meets all its goals.