A gentle critque..

[John Reimer]

Bill Baxter wrote:
> In article <e4dhnf$1l5n$1 at digitaldaemon.com>, Paulo Herrera says...
>> Walter Bright wrote:
>>> Those are good parallels, and it's good you brought that up. Working C++ 
>>> legacy code is not going away and is not going to be translated to D. 
>>> What will happen is *new* code will be done in D.
>> Walter,
>> I guess you have good reasons to think in this way, but my experience is 
>> different.
>>
>> I've been in two different graduate schools and at two different 
>> departments (Civil Engineering and Earth Sciences). I think the 
>> situation in those departments in different to what people observe in a 
>> CS department. In both places I met people that buy expensive Fortran 
>> compilers not only to compile old libraries, but to write new code. I 
>> know people that write large parallel codes in Fortran and that use a C 
>> library (PETSc) for the core numerical routines. Most of them are young 
>> researchers, so they learned Fortran few years ago. So, I don't think 
>> Fortran is still around because of old legacy code or "old legacy 
>> programmers".
>>
>> I think most of that people use Fortran because there wasn't anything 
>> better for that kind of code. I think/hope D can be a viable alternative.
> 
> Yeh, my impression is that Fortran users care most about 
> A) the ability to easily use the gobs of existing Fortran code thats out there
> and 
> B) having basic operations like C[i] = A[i] + B[i] run as fast as possible for
> their given architecture.  
> I seem to recall Fortran also has some other syntactic sugar that makes various
> array operations easier than with C.  Not sure how important that is.
> 
> For A) nothing beats the ease of calling legacy fortran code than fortran
> itself.  It's hard to beat there.  
> 
> For B) C's lack of alias-free arrays means C compilers can't optimize as
> aggressively as Fortran ones.  C99 has the restrict keyword, but here it is
> seven years after the C99 standard, and the big compiler vendors still don't
> seem interested in implementing it.  And besides if you're using Fortran, you're
> doing numerics.  Fast numerical code is pretty much the only benchmark that
> matters in that world, so if you want to sell a fortran compiler, it better do a
> great job on numerical code.  C compiler writers sell to a much wider variety of
> folks, so the need to optimize numerics in order to make a profit is much less. 
> 
> None of the above has anything to do with whether Fortran is a great language or
> not.  Its good enough to get their job done, and the costs of moving to a
> different language outweigh the benefits for some folks.
> 
> And even if young researchers are using it, I suspect that that also has a lot
> more do with what their professors were proficient with than the merits of the
> language -- i.e. it *is* a legacy/inertia issue.  I took a few classes in the
> Applied Math dept where the prof would provide a skeleton of Fortran code or
> some support code in fortran and you were supposed to fill in the rest.  He said
> we were free to use C or C++, but then we'd have to scrap together our own
> bootstrap code.  I went with C++ but every other student in the class went with
> Fortran, because it was the default path, and because the prof was more likely
> to be able to provide help with the Fortran.
> 
> Er, so summing up, I'm agreeing with you Paolo, that some people aren't going to
> give up on Fortran just because a better language comes along.  But mostly
> because of how easy it is to call Fortran from Fortran, and because that's what
> they teach to young numerical researchers.  But that's not everyone.  Some
> numerics people do see the light and long for better more scalable tools and
> aren't afraid to spend time learning something new.  I know at least one
> dyed-in-the-wool fortran numerics guy who's writing a massive new library in C++
> because he wants the modularity maintainability provided by OO abstractions.
> But currently he has to put up with people saying his code is going to be slower
> than the equivalent Fortran code.  If D could match Fortran for raw numeric
> speed then at least that one argument would go away.  So I agree with Walter
> that if D can be as good at numerics as Fortran then some, but certainly not
> all, new code would be written in D.  This guy's library is a good example.  Big
> new C++ code base with virtually no external dependencies.  Probably would have
> been perfect for D if he had known about it -- and if D had been 1.0 when he
> started -- and if there had been sufficient resources (like books) out there to
> learn how to program in D.
> 
> Bill Baxter


Just curious: how does Fortran scale for use of parallel computations? 
Perhaps some Fortran compilers are more advanced in that field than 
C/C++?  If so, lack of intrinsic (computational) parallel support (ie, 
easily programmable) could be a short-coming that D might continue to 
share with C/C++?  Could this also be a reason Fortran still remains 
more attractive to some extent?

Of course, I'm not familiar enough with scientific uses of Fortran to 
comment on that language comparatively.  I just wonder if some of these 
advanced Fortran compilers also contain automatic parallelism of some of 
the computational tasks?

On a slightly different but related topic:

My observation of D is that, as wonderful a language as it is, it still 
inherits much of the same low-level concurrency difficulties of C/C++. 
There's no adoption of clean/provable parallel constructs as should be 
seen in languages hoping to take on the 21st century's multi-core 
systems.  We're still stuck with the tricky/deadlock-friendly mechanisms 
of mutex's and semaphores that require highly skilled programming and 
extremely astute/alert developers (even then deadlocks are often 
unpredictable).  We need something higher level (and provable) to 
lighten the load for D users and remove the nasty complexities from 
parallel programming. (see CSP -- Communicating Sequential Processes -- 
and Pi Calculus type constructs/constraints).

Such high-level parallelism support is usually most palatable and useful 
by integrating the constructs with keywords within the language (I'm not 
sure how attractive these features would be if integrated via mixins or 
templates in D, but it has been done to some degree with object 
inheritance in other languages [see JCSP for Java])  A month or so ago, 
Kris first pointed this out in a previous post to this newsgroup.

Granted, I think such a feature is a difficult task to integrate into D, 
but I also think it's one major detail that would really set D apart 
from other computer languages.  The addition would likely be considered 
hugely welcome in multiple scientific, engineering, and computational 
science sub-cultures.

-JJR