Why is Ada considered "too specialized" for scientific use
in [ADA]
|
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: BrianG on 6 Apr 2010 22:03 Georg Bauhaus wrote: > Keith Thompson schrieb: >> Georg Bauhaus <rm-host.bauhaus(a)maps.futureapps.de> writes: >> [...] >>> C99 (note the year) has complex types, says C hasn't. Well, it >>> hadn't, as some point in the last century. >> [...] >> >> Unfortunately, the C99 standard has not yet been universally adopted. >> Very few compilers fully support it. And this differs from Ada'05 how? How many compilers support it? More importantly (to me), how many non-compiler tools support it? --Bg
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: Georg Bauhaus on 7 Apr 2010 05:08
BrianG schrieb: > Georg Bauhaus wrote: >> Keith Thompson schrieb: >>> Georg Bauhaus <rm-host.bauhaus(a)maps.futureapps.de> writes: >>> [...] >>>> C99 (note the year) has complex types, says C hasn't. Well, it >>>> hadn't, as some point in the last century. >>> [...] >>> >>> Unfortunately, the C99 standard has not yet been universally adopted. >>> Very few compilers fully support it. > > And this differs from Ada'05 how? By (1) the number of years between standard publication and support of basic data types and (2) that complex is much older in both Fortran and Ada than it is in C99. But I said that C99 *is* available in 2006, Keith Thompson noted that MS C (not MS C++) is among those implementations that do not *fully* support C99. If only there was a 3rd edition of K&R. I'd hope that (since almost everyone is still relying to C in spite of everything) this new edition could draw attention to at least the new and better type stuff, even when it keeps being as suboptimal as C arrays. > How many compilers support it? Fewer than the total number of compilers (Ada 95 or Ada 2005) available, TTBOMK. > More > importantly (to me), how many non-compiler tools support it? Don't know. Syntax tools have few new things to deal with. X-language tools might even be ahead if they had already supported multiple inheritance of interfaces. Other tools for source code analysis announce to support Ada 2005. Some makers depend on customer demand and either fade or grow. WRT scientific computing, there is one noteworthy development: an Ada subset called SPARK, which I guess is sharing perspective with Fortran subset F in a sense. In part, SPARK brings back some of the spirit of original Ada 83, even when including newer language features into a reasonably small subset. I think that this subset includes stuff very valuable in scientific programming, insofar as the latter will profit from data types and array indexing proven mathematically to be correct, so, for example, leaving out bounds checking is no longer an adventure but becomes a justified consequence. |