A gentle critque..

[Bill Baxter]

In article <e4cubh$nou$1 at digitaldaemon.com>, Ben Cooley says...
>
>In article <e4cgup$2te2$1 at digitaldaemon.com>, Bill Baxter says...
>>
>>In article <e4ca0r$2hvj$1 at digitaldaemon.com>, Paulo Herrera says...
>>>
>>>Bill Baxter wrote:
>>>> 
>>>> Finally about whether it's worth it to be able to call C++ code, I'd like to
>>>> point to the example of Fortran.  It was superceded by better languages with
>>>> better syntax many many years ago, but people still use it.  I hear a lot of
>>>> people saying "we're better off without all that old junky C++ code anyway".
>>>> But the fact of the matter is that nobody in the real world has the time or
>>>> budget to go back and rewrite all their old code (that already works and has
>>>> been debugged) just because it would be easier to read in a new language.  Most
>>>> numerical work is still based on lots of legacy fortran code, even if the front
>>>> end code is now written in C or C++ or Python or what have you.   It just makes
>>>> no sense to rewrite gobs and gobs of stuff that works.
>>>> 
>>>> Gotta go so there's no time to finish my point, but there are some interesting
>>>> parallels in this debate with the migration away from Fortran, I think.  
>>>> 
>>>> Bill Baxter
>>>Hi everybody,
>>>This is my first post to this mailing list.
>>
>>Howdy.
>>
>>>
>>>About the Fortran example
>>>-------------------------
>>>I think the Fortran example is a bad one. Which better languages were 
>>>available long time ago? C or C++? Do you think C or C++ have a clean 
>>>syntax? I don't think so, that's why I've been exploring D.
>>>There are a lot of C (e.g. GSL, PETSc) and C++ (e.g. ITL, Blitz++) 
>>>numerical libraries, so I don't think that is the main reason people 
>>>still use Fortran.
>>
>>
>>My point was that while some people still use Fortran (and others have moved
>>on), LOTS of people still use old Fortran *libraries*.  I.e. C/C++ are to
>>Fortran as D is to C/C++.  And just as with Fortran, there's just no value
>>proposition in rewriting gobs of well-known, well-tested, well-debugged code,
>>like that available at netlib.org.  Dreaming that everything of value that has
>>ever been written in other languages (including Fortran, C, and C++) will get
>>rewritten in D is just that, dreaming.  Heck, from what I hear there are still
>>plenty of mainframes out there, cranking away on Cobol code.  Because it just
>>doesn't make sense to spend a lot of resources fixing what ain't broke.
>>
>>Writing new libs from scratch is certainly the best in the long run.  But that
>>takes time, and it takes a lot of raw man hours.  In the short term, it seems
>>obvous to me that the best bet is to increase the number man-hours by increasing
>>the number of 'mans' -- attracting as many folks as possible to D.  But starting
>>off by saying "sorry you can't use your old code" is just going to put people
>>like Ben off from the start, thereby shrinking the pool of potential
>>contributors.   I don't think D needs compatibility with C++ -- I'm inclined to
>>think it's pretty hopeless even with a working C++ compiler as a starting point
>>-- but some tools to create wrappers for existing C++ code (a la SWIG), should
>>be doable, and would be a huge help in luring people to D.  
>>
>>I would venture to guess that the vast majority of C++ code that people write in
>>real life is not at all like the STL, but more like the subset of C++ that's
>>contained in  Java.  Those are the things you want to target (most bang for the
>>buck), and, no co-incidence, those are precisely the things that SWIG targets.
>>Libraries like Blitz++ and ITL that go crazy with C++ templates are so steeped
>>in C++-specific issues that I doubt they could be wrapped reasonably anyway,
>>whether done by hand or by a wrapper-generator.
>>
>>Apparently this idea to use SWIG has been discussed (and even worked on?) a bit
>>before:
>
>I agree. And I'm not interested anymore in arguing about "why" this should be
>done.  If it isn't made obvious to anyone by the post about "finally having the
>Windows API translated to D".. then it never will be.  <rolls eyes>
>
>I think the practical way to do this is to allow D to comprehend basic C++
>vtable types, access C++ members and methods and be able to instantiate macro
>constants.  Other C++ interop would be handled using inline cpp { } blocks which
>could access D vars.  

Yes, we're in agreement insofar as we both think it would be good if it were
easier to use legacy C and C++ code with new D code.  I think the majority of
readers of this list would agree there's nothing wrong with that.  They might
prioritize it differently, but I think most everyone here can agree that if a
magic wand could make C++ callable from D then it should be done.  But seeing
Walter's Giant List of all the interoperability issues pretty much clenches it
for me that making D work _directly_ with C/C++ is just a non-starter.  Not
unless Google "buys" D tomorrow and throws 20 full time engineers on it.  On the
other hand, SWIG, or SWIG-like, wrapping of C/C++ for consumption by D is a much
more feasible, realistic goal.  SWIG makes the easy stuff easy (automatic, just
%include "header.h") and the hard stuff doable (with manual annotations), but it
doesn't magically make the impossible possible (like porting the STL to Python).

Forgive me if I'm misunderstanding you, but your talk of accessing vtables and
such from D sounds like you're still thinking of making D understand C++
binaries.  I just don't think that's practical given the current D development
situation.  But I think it would only take one or two determined souls to revive
the SWIG approach and wrangle it into something useful.

Speaking of Google, and projects for one or two determined souls, were there any
D proposals submitted to the Google Summer of Code?

Regards,

Bill Baxter