A gentle critque..

[Don Clugston]

Paulo Herrera wrote:
> 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. 

Welcome! There are quite a few of us here already.

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.

And Fortran takes numerics seriously. Unlike almost all of the more 
recent languages. D is the only recent general-purpose language I know 
of that takes numerics seriously (that's what initially attracted me to it).

> 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.

I agree. When porting a library
(a) there isn't any algorithm development (not much 'thinking' time 
required);
(b) it's very easy to test (you can run test cases against the original 
version);
(c) the D version is frequently greatly superior to the original.

D is a fantastic language for writing libraries in. IMHO, if we had even 
a small number of libraries with solid unit test coverage, everything 
else would start to look obsolete very quickly.

> 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.

And .NET too.

> 
> 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.

Right on topic, I would say.
-Don.