Re: Choosing Perl/Python for my particular niche
Also sprach Cameron Laird:
[color=blue]
> I generally favor Python over Perl; in the absence of
> more details, I think there's mild evidence that those
> who don't specialize in programming are happier over the
> long term with the readability of the former. They're
> very close, though. The one most certain advantage
> Python boasts is a dimension that I'd think important
> to you, although you haven't mentioned it: Python's
> interfaces to C++ are MUCH easier to manage than Perl's.
> Perl6 will change this. For now, though, it's FAR
> easier to practice "dual-level programming" with Python
> and C++. If you have a large existing library of C++
> work, I think that tips the balance toward Python.
> Understand, SWIG and other alternatives make Perl-to-C++
> links possible; with Python's facilities, though,
> including Pyrex, they're *fun*.[/color]
When it comes to embedding C/C++ into Perl, SWIG is the last thing that
I'd recommend. It may be capable of transforming such a library into a
Perl module on its own with no user intervention. However, C/C++ doesn't
map particularly well onto Perl from an interface point-of-view: A 1:1
translation of a C++ API doesn't look particularly good.
Those things should be done manually. How much work this is depends on
the library. Some only require a few lines of XS. XS' learning curve is
admittedly a bit steep. Not because it is difficult in itself but rather
because the documentation leaves a few things to be desired. There are
some actions on completing perlxstut.pod on its way right now, though.
There is also Inline::CPP, although I don't think it is as mature as
Inline::C. And since you have mentioned Tcl, even that can be inlined
with the help of Inline::Tcl.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_ $;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus}) (rekcah{lrePbus })(lreP{rehtona bus})!JAPH!qq(r ehtona{tsuJbus# ;
$_=reverse,s+(? <=sub).+q#q!'"q q.\t$&."'!#+sex isexiixesixeseg ;y~\n~~dddd;eva l
Also sprach Cameron Laird:
[color=blue]
> I generally favor Python over Perl; in the absence of
> more details, I think there's mild evidence that those
> who don't specialize in programming are happier over the
> long term with the readability of the former. They're
> very close, though. The one most certain advantage
> Python boasts is a dimension that I'd think important
> to you, although you haven't mentioned it: Python's
> interfaces to C++ are MUCH easier to manage than Perl's.
> Perl6 will change this. For now, though, it's FAR
> easier to practice "dual-level programming" with Python
> and C++. If you have a large existing library of C++
> work, I think that tips the balance toward Python.
> Understand, SWIG and other alternatives make Perl-to-C++
> links possible; with Python's facilities, though,
> including Pyrex, they're *fun*.[/color]
When it comes to embedding C/C++ into Perl, SWIG is the last thing that
I'd recommend. It may be capable of transforming such a library into a
Perl module on its own with no user intervention. However, C/C++ doesn't
map particularly well onto Perl from an interface point-of-view: A 1:1
translation of a C++ API doesn't look particularly good.
Those things should be done manually. How much work this is depends on
the library. Some only require a few lines of XS. XS' learning curve is
admittedly a bit steep. Not because it is difficult in itself but rather
because the documentation leaves a few things to be desired. There are
some actions on completing perlxstut.pod on its way right now, though.
There is also Inline::CPP, although I don't think it is as mature as
Inline::C. And since you have mentioned Tcl, even that can be inlined
with the help of Inline::Tcl.
Tassilo
--
$_=q#",}])!JAPH!qq(tsuJ[{@"tnirp}3..0}_ $;//::niam/s~=)]3[))_$-3(rellac(=_$({
pam{rekcahbus}) (rekcah{lrePbus })(lreP{rehtona bus})!JAPH!qq(r ehtona{tsuJbus# ;
$_=reverse,s+(? <=sub).+q#q!'"q q.\t$&."'!#+sex isexiixesixeseg ;y~\n~~dddd;eva l
Comment