Why is Ada considered "too specialized" for scientific use
in [Fortran]
|
From: Warren on 6 Apr 2010 16:45 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 6 Apr 2010 17:37 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 7 Apr 2010 00:25 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 7 Apr 2010 02:43 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 7 Apr 2010 08:53
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. |