Tangent on embeddability (was: Choosing Perl/Python for my particular niche)

[Fred Ma]

Cameron Laird wrote:
> 
> In article <roy-3EDA29.08465327032004 at reader1.panix.com>,
> Roy Smith  <roy at panix.com> wrote:
>                         .
>                         .
>                         .
> >2) It's dead simple to embed in a C/C++ application.  This is one place
> >where it really outshines Python.  It's literally two lines of C to get
> >a Tcl interpreter up and running.  It's equally trivial to extend Tcl by
> >providing functions in C.  Compare this to the native Python/C
> >interface, boost.python, or swig, and you really appreciate the
> >difference!
> >
> >For most general purpose tasks, I reach for Python first.  But if I
> >needed to provide a quick scripting interface to an existing C library,
> >or wanted to embed some easy scriptability into a large C/C++ app, Tcl
> >is what I would be looking at.
> 
> Me, too, to a large extent.  I think you overstate Tcl's
> advantage, though, Roy, in a couple of ways.  First, I
> agree that Tcl is objectively easier and more reliable
> in embedding; Python still has blemishes in ease-of-use
> and portability in this role.  It can be hard getting
> all of Python embedded correctly, especially, in my ex-
> perience, when working on multiple platforms.
> 
> However, Tcl has historically been so easy that it hasn't
> bothered documenting the process.  Python has a definitive
> (if aging) embedding manual that I regard as more inviting
> than what Tcl offers.
> 
> Also, ctypes, Boost and Pyrex *are* successful, and appear
> to me progressing faster than any of their Tcl cousins.
> 
> Yet another way to look at the comparison is that a sig-
> nificant number of people rely on SWIG, and, to them,
> Tcl and Python are indistinguishable.
> 
> Follow-ups narrowed.  Most of Perl's response to all of
> this is, "Wait 'til 6!"


Thanks, Roy & Cameron, for the glimpse into TCL.  I had just
a passing bout with it in trying to use Synopsys's TCL based
shell.  It was far too brief to be a fair assessment, since
the documentation wasn't quite up to it, and I fell back to
their conventional shell (which itself was suppose to be
a brief detour to get some design information mulched out
from some verilog files).  Certainly didn't get to the level
of using it to interface to C libraries.  For the most part,
however, I'll be using "P..." for data conversion rather
than coordination of different library routines.  I've got
a pretty good template worked out with matlab on top and
C++ on the bottom.  I'll probably stick with this model until
I graduate.  I'm looking at "P..." to help with converting
design information from verilog to SystemC (C++ library for
digital hardware simulation) so that I can use it in the
matlab/C++ model, but it won't be part of the main line of
computation.

Fred