Boost logo

Boost :

From: Prabhu Ramachandran (prabhu_at_[hidden])
Date: 2000-10-14 09:52:16

        Sorry about the delayed responses. Was busy and not well.

>>>>> "Ullrich" == Ullrich Koethe <koethe_at_[hidden]> writes:

    Ullrich> I think, py_cpp and ILU represent two extremes in a
    Ullrich> spectrum of possibilities: ILU is a giant project with
    Ullrich> extremely broad scope (many languages, multiple
    Ullrich> protocols, total unification), while py_cpp is a small
    Ullrich> tool that does just one thing elegantly and efficiently.
    Ullrich> Accordingly, target applications are different in both
    Ullrich> cases: one would use ILU to build a distributed,
    Ullrich> multi-language object system, but one would use py_cpp to
    Ullrich> add scripting to an existing project as quickly as
    Ullrich> possible.

        I agree but just wanted to mention it as a possibly
interesting idea that you may want to think about...

    Ullrich> I imagine the typical py_cpp user has implemented a
    Ullrich> (perhaps huge) system for his particular application
    Ullrich> area. Now he wishes to add the capability to use this
    Ullrich> system interactively (that is, by issuing commands at a
    Ullrich> prompt and running scripts). This extension is but a
    Ullrich> small (if important) aspect of the whole system, so it
    Ullrich> should be implemented by a correspondingly small and
    Ullrich> simple tool.

        Yes, that sounds ok.

    Ullrich> It wouldn't be reasonable to double the size of an entire
    Ullrich> project (by adding ILU, for example), just to enhance a
    Ullrich> small aspect of the functionality. The burden to
    Ullrich> programmers and users (installing and understanding ILU)
    Ullrich> would be too large in relation to the benefit. Many


    Ullrich> projects failed because developers got distracted by huge
    Ullrich> and beautiful tools instead of concentrating on their
    Ullrich> main tasks. In constrast, a small tool like py_cpp can be
    Ullrich> easily integrated into the existing system, so that
    Ullrich> programmers wouldn't be distracted and users need not
    Ullrich> even realize that py_cpp existed.

        If it gets to that point, sure. Looks like it has a larger
chance of getting there if you dont bother about ILU and stuff too.
So, yeah it is really fine that you are doing a specific C++ -> python

    Ullrich> (The story might look different if ILU-like capabilities
    Ullrich> were part of the operating system. Then the general tool
    Ullrich> would exist anyway, so one might as well use it without
    Ullrich> bothering whether it's small or large. But this requires
    Ullrich> a degree of standardization that seems to be out of reach
    Ullrich> at present.)

        That's true.


>> But it sure seems to make sense to add an abstraction layer
>> between languages.

    Ullrich> Yes, but the smaller the granularity of the wrapped
    Ullrich> functionality, the more the complexity of this
    Ullrich> abstraction layer will hurt performance. A ridiculous
    Ullrich> example: imagine your WWW browser would open an ILU
    Ullrich> connection for every single pixel of each image - this
    Ullrich> would be way too slow. So you will need a thinner
    Ullrich> abstraction layer for finer granularity (but probably
    Ullrich> py_cpp is still to slow to routinely access single
    Ullrich> pixels).

        Not if the ILU was used to compile a new library that deals
with the python calls directly. What I really meant was that one
generates the library just as py_cpp does now but with a layer of
abstraction that is used _during_ the conversion of the library and
_not_ during runtime. This may have problems of its own and will
certainly add complications.

    Ullrich> I guess, at present there is no one-size-fits-all
    Ullrich> solution to your problem.

        Frankly I use python exclusively for scripting. So it really
is not my problem. :) I personally am happy with py_cpp and what you
have planned for it.


Boost list run by bdawes at, gregod at, cpdaniel at, john at