A gentle critque..

[Paulo Herrera]

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.

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