From: Warren on
Sebastian Hanigk expounded in news:hpfsf8$495$1(a)news.lrz-muenchen.de:

> Warren <ve3wwg(a)gmail.com> writes:
>
>> Obviously Fortran persists because of existing code base and
>> those that only "know" that. But egads, the current rendition
>> of Fortran seem to have so many "bags on the side" and is
>> downright "butt ugly". Why anyone would want to continue
>> to wallow in that swill, is beyond me. Ada as a language OTOH,
>> is so nice and clean by comparison.
>
> I won't even start with your puny attempts at a language crusade,
.....
> Sebastian

Wooo-oooo, aren't we snubby today.

Warren
From: Georg Bauhaus on
On 4/6/10 9:53 PM, J. Clarke wrote:
> On 4/6/2010 10:03 AM, Georg Bauhaus wrote:

>> So for scientific computing, MS C will be a less attractive choice
>> than GNU C or Intel C, or Comeaucomputing's C on top of MS C adding
>> C99 to MS C, or ...
>>
>> Or less attractive than compilers for one of the other
>> languages such as Ada or Fortran or ... that support both fairly recent
>> standards and computing with complex numbers.
>
> What is the objection to using the C++ complex library?

(Or, in other circumstances, objections to using a library such
as Leda maybe.)
I'll speculate about two major reasons for not hoping for the C++
complex library to replace Fortran function libraries any time soon.
At least in some domains...

One reason would be successful tradition: a researcher has successfully
written a scientific program using knowledge available with Fortran 77;
moving to Fortran 90 has improved the solution. Why switch to
non-Fortran? The post-hoc fallacy aside, if non-Fortran is C++, to use
C++ effectively it takes learning a language integrating very many parts
in far reaching and novel ways (from the researcher's perspective).
Most parts need to be well understood in order to bridle the compiler.
To him or her, what is the indisputable advantage of C++ in relation to,
say, a modern subset of recent Fortran? Maybe the support of physical
unit checks at compile time is an example. But the mechanisms behind
template specialization based C++ computation are not that easy to
grasp, are they? At least hardly easier than just moving to Fortran 95
or later and manually checking units by paying attention.

Remembering professor Fitzpatrick's published remark that started this
thread, a researcher's job is probably focused on computing scientific
results rather than optimizing language use. So Fortran 90 it is, or
C---until a new generation of researchers and research problems
gives rise to a new tradition of similarly forced attire using another
language. Technical arguments involving language properties beyond
immediate necessity are subordinate, as ever. After all,
we continue to pay them for this style scientific software! ;-)
[end of speculation]
From: J. Clarke on
On 4/6/2010 5:37 PM, Georg Bauhaus wrote:
> On 4/6/10 9:53 PM, J. Clarke wrote:
>> On 4/6/2010 10:03 AM, Georg Bauhaus wrote:
>
>>> So for scientific computing, MS C will be a less attractive choice
>>> than GNU C or Intel C, or Comeaucomputing's C on top of MS C adding
>>> C99 to MS C, or ...
>>>
>>> Or less attractive than compilers for one of the other
>>> languages such as Ada or Fortran or ... that support both fairly recent
>>> standards and computing with complex numbers.
>>
>> What is the objection to using the C++ complex library?
>
> (Or, in other circumstances, objections to using a library such
> as Leda maybe.)
> I'll speculate about two major reasons for not hoping for the C++
> complex library to replace Fortran function libraries any time soon.
> At least in some domains...
>
> One reason would be successful tradition: a researcher has successfully
> written a scientific program using knowledge available with Fortran 77;
> moving to Fortran 90 has improved the solution. Why switch to
> non-Fortran? The post-hoc fallacy aside, if non-Fortran is C++, to use
> C++ effectively it takes learning a language integrating very many parts
> in far reaching and novel ways (from the researcher's perspective).
> Most parts need to be well understood in order to bridle the compiler.
> To him or her, what is the indisputable advantage of C++ in relation to,
> say, a modern subset of recent Fortran? Maybe the support of physical
> unit checks at compile time is an example. But the mechanisms behind
> template specialization based C++ computation are not that easy to
> grasp, are they? At least hardly easier than just moving to Fortran 95
> or later and manually checking units by paying attention.
>
> Remembering professor Fitzpatrick's published remark that started this
> thread, a researcher's job is probably focused on computing scientific
> results rather than optimizing language use. So Fortran 90 it is, or
> C---until a new generation of researchers and research problems
> gives rise to a new tradition of similarly forced attire using another
> language. Technical arguments involving language properties beyond
> immediate necessity are subordinate, as ever. After all,
> we continue to pay them for this style scientific software! ;-)
> [end of speculation]

Look, you were whining about "MS C" not implementing a complex data type.

Well Visual C++ 2008, which is the only "MS C" in current production,
most assuredly DOES implement a standards-compliant complex data type,
so I don't really understand the point of your complaint.

From: Georg Bauhaus on
On 4/7/10 6:25 AM, J. Clarke wrote:

> Look, you were whining about "MS C" not implementing a complex data type.

Did I? I didn't. I remember saying that even in 2006 (from which
the note in question dates) there were well enough compilers
supporting C99 on Windows NT.

If VC2010 doesn't support C99, as reported, then still this perceived
lack would not have been a reason to dismiss C just for lack of a
complex data type. And in fact, VS2005, which was available in 2006,
does not have <complex.h> for C. VC++ does support <complex>,
but enough harm has been done in assuming that writing C using
a C++ compiler is a good idea.

> Well Visual C++ 2008, which is the only "MS C" in current production,
> most assuredly DOES implement a standards-compliant complex data type,
> so I don't really understand the point of your complaint.

My complaint, or observation, is that more than one researcher
talking about programming languages tends to act as a show man
when he or she does not really (need to) know what he or she is
talking about. This creates gossip, perpetuates hearsay, and,
by imitation, drives the choice of programming language for
research. Obviously then, decisions to use this or that language
will not be as informed as could be. Chances are that program
quality suffers. I hope this observation can be shown to be wrong.
From: J. Clarke on
On 4/7/2010 2:43 AM, Georg Bauhaus wrote:
> On 4/7/10 6:25 AM, J. Clarke wrote:
>
>> Look, you were whining about "MS C" not implementing a complex data type.
>
> Did I? I didn't. I remember saying that even in 2006 (from which
> the note in question dates) there were well enough compilers
> supporting C99 on Windows NT.
>
> If VC2010 doesn't support C99, as reported, then still this perceived
> lack would not have been a reason to dismiss C just for lack of a
> complex data type. And in fact, VS2005, which was available in 2006,
> does not have <complex.h> for C.

So what?

> VC++ does support <complex>,
> but enough harm has been done in assuming that writing C using
> a C++ compiler is a good idea.

What "harm" is this? And in point of fact, VS2005 has no C compiler
except the C++ compiler that you say should not be used for writing C.
What you are calling a "C compiler" is in fact a command line switch
applied to the C++ compiler.

>> Well Visual C++ 2008, which is the only "MS C" in current production,
>> most assuredly DOES implement a standards-compliant complex data type,
>> so I don't really understand the point of your complaint.
>
> My complaint, or observation, is that more than one researcher
> talking about programming languages tends to act as a show man
> when he or she does not really (need to) know what he or she is
> talking about. This creates gossip, perpetuates hearsay, and,
> by imitation, drives the choice of programming language for
> research. Obviously then, decisions to use this or that language
> will not be as informed as could be. Chances are that program
> quality suffers. I hope this observation can be shown to be wrong.

My complaint is that you seem to be complaining to be complaining. If
you're using a C++ compiler then write C++, don't whine because its C
support is half-assed.