|
Boost : |
From: Prabhu Ramachandran (prabhu_at_[hidden])
Date: 2000-10-14 09:52:16
hi,
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
Agreed.
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
tool.
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.
<snip>
>> 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.
prabhu
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk