A gentle critque..

[jcc7]

In article <e4ca0r$2hvj$1 at digitaldaemon.com>, Paulo Herrera says...
>
>Bill Baxter wrote:
>> In article <e4brql$1ihs$1 at digitaldaemon.com>, BCS says...
>>> In article <e4baj5$aut$1 at digitaldaemon.com>, Walter Bright says...
>>>> BCS wrote:
>>>>> What do ya think new D users would think about a converter that does 
>>>>> 100% correct convention of a sub set (+10%) of C (and maybe cpp) code? 
>>>>> Say just global function prototypes, structs typdefs (c style) and 
>>>>> anything else that would be easy to get right. Some of the stuff (in C, 
>>>>> the most common stuff) translates directly, and shouldn't be that bad to 
>>>>> translate.
>>>> There is always something in each header that is not translatable :-(
>>> But with any luck you wont need that part most of the time. What I'm suggesting
>>> is a tool that does a best effort translation generating a header for parts that
>>> can always be done (file scope function, simple structs, global variables of
>>> common types, etc.) in other words, the bulk of most C headers.
>> 
>> Note that that's already how SWIG works pretty much.  It doesn't have a full C++
>> parser, but it can parse and generate wrappers for a lot of simple C++ code just
>> by including the header.  It's not going to work for wrapping wxWidgets or
>> something like that, but it is useful to have.
>> 
>> There has also been talk in the SWIG mailing lists about generating C wrappers
>> from C++ code.  Don't think anyone is actively working on it, but there is
>> interest in such a thing out there.  That could be useful for D purposes too.
>> With a little work it could lead to the ability to use any SWIG-wrapped C or C++
>> code from D.  It's a thought for an alternative to trying to write a C++ to D
>> translator type thing.
>> 
>> 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.
>
>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.
>
>I'm a scientist that have to write numerical codes. I've been searching 
>for a better language (combination of languages) than Fortran for some 
>time. I've used Fortran+F2PY+Python, C++, Python+SWIG+C++, and Java to 
>write code. None of those alternatives to replace Fortran were 
>completely satisfactory. One of the reasons is that Fortran is very good 
>at doing number crunching. It's very fast, it includes array operations, 
>and it is easy to learn.
>
>However, Fortran95 (as standard) lacks other tools, such as: conditional 
>compilation, unit testing, true OO programming, command line arguments 
>(that was only fixed in the new 2003 standard), etc. To me those are the 
>most interesting D's features. In fact, I think D features make it a 
>terrific alternative to Fortran. however, there are a couple of things 
>that would make it even better: array operations (it's in Walter's 
>plans) and OpenMP support.
>
>About using different languages
>-------------------------------
>I understand that some times is useful to be able to program using a 
>combination of languages. However, those cases should be the exception 
>if you want to take advantage of a better language features. Mixing 
>languages always adds problems and, in my opinion, makes difficult to 
>have a clear design. As example, you can check how difficult has been 
>creating a good SWIG interface for C++ or the problems of the maintainer 
>of F2PY (Fortran to python interface generator) to support new compilers.
>
>I think D already has a very easy way (probably the easiest with the 
>exception of C++) to communicate with C if needed. Why to spend more 
>valuable time improving that?
>
>About native libraries
>----------------------
>I think the way to go is to create QUALITY native D libraries. I think 
>we usually overestimate the cost of porting/developing native libraries. 
>As example, this weekend I played to create a native XML SAX parser. In 
>a couple of hours I had a useful version. I'm not sure if it was 
>easier/shorter to link to a C library (that was my first idea).
>
>I think D main problem is the lack of good quality (documented) native 
>libraries. More than 80% of project at www.dsource.org are unmaintained 
>and/or don't have documentation. Therefore, collaborating in or using 
>those projects is impossible. In my opinion libraries and good quality 
>documentation are the main reasons of the success of Python and Java.
>
>About writing a native XML library
>----------------------------------
>If someone is interested in creating native SAX and DOM XML libraries 
>please drop me an email. By the way, XML is another effective way to 
>communicate (actually, exchange data) between different languages.

Someone may have already have started such a project. Have you seen this list? 
http://www.prowiki.org/wiki4d/wiki.cgi?AllLibraries/XmlLibraries

The rest of them may be abandoned, but at least Mango (which is much, much more
than just an XML tool) is still in active development.


>I apologize if part of this email is off topic in this thread.
>Paulo.

Don't worry about it. Threads go off-topic all topic all the time around here.
This thread was practically off-topic from the beginning. ;)

jcc7