Why is Ada considered "too specialized" for scientific use
in [ADA]
|
From: Keith Thompson on 5 Apr 2010 12:44 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. Many support most of it, but I understand that Microsoft's compiler still supports only C90 (with maybe a handful of C99-specific features). Which means that as soon as you write "#include <complex.h>", you've limited the portability of your program. -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Charmed Snark on 5 Apr 2010 13:33 Nasser M. Abbasi expounded in news:hp95j8$i29$1(a)speranza.aioe.org: > I was browsing the net for scientific software written in Ada, and > came across this strange statement: > > http://farside.ph.utexas.edu/teaching/329/lectures/node7.html > > "Scientific programming languages > What is the best high-level language to use for scientific > programming? Just asking "what is best" in any selection process is going to be contentious except for the simplest of things. Somewhat like asking "what is the best laptop?" Too many inputs to consider. > This, unfortunately, is a highly contentious question. > Over the years, literally hundreds of high-level languages have been > developed. However, few have stood the test of time. Many languages > (e.g., Algol, Pascal, Haskell) can be dismissed as ephemeral computer > science fads. Others (e.g., Cobol, Lisp, Ada) are too specialized to > adapt for scientific use. ... > The remaining options are FORTRAN 77 and C. I have chosen to use C " > > I find this strange, because I think Ada can be the best programming > language for numerical work. So, I do not know why the author above > thinks Ada is "too specialized to adapt for scientific use". Surely he expanded on this? How is it too specialized (in his opinion)? > Is there > something in Ada which makes it hard to use for scientific > programming? I recently tried to introduce a co-worker to the fact that Ada is free and easy to install (cygwin gcc-ada) yada yada. He started reading a couple of free online (PDF) books and said his eyes glazed over and that he has no further interest. I suppose things might be different if there was a job market for that skill here (Toronto). So that factor seems to be one important reason for some folks. Library support would be another factor, I would think. People don't want to become experts in interfacing to C (for example). But as I do more and more of this, I am finding this to be less of an issue. Maybe a good "The Art of Binding [GNAT] Ada" document would help people with this. I do feel that Ada does require you to "engineer" your project more, which is a good thing. But this is something that some folks seem to dislike. It probably impacts the inexperienced programmers the most. This is the very crowd that needs to be won over. Otherwise, it sounds as if the author has too quickly dismissed the language, without much familiarity in it. > The main problem I see with Ada for scientific use is that it does not > have as nearly as many packages and functions ready to use output of > the box for this, other than that, the language itself I think is > better than Fortran and C for scientific work. > --Nasser One huge improvement I see in Ada-2005, is the built-in inclusion of Ada.Containers. Having them "included" saves me from having to instruct downloaders of where and which version of the Booch components (or was it Charles?) etc. Having them included means that my project should always "work" the same, (in theory at least) regardless of the version of the compiler used. I am making big use of these containers in the rewrite of my basic interpreter project. I have got far enough along now to believe that this is a very practical language change. I love the higher level of abstraction without having to forego "repesentation" when it is required. My only worry remains on compiler portability to HPUX, Solaris and AIX. But at this point, I am going on faith that this will not be a huge open source problem going forward. It is encouraging to see the results of gcc-ada making it more universally available, and hopefully increasingly well tested. I feel that the benefits of an Ada rewrite now seems to outweigh the risk of compiler availability. One beauty of open source is that I don't have to justify the rewrite. But I could easily do that, as the design is much improved now (I also expect a big performance improvement later). Rewrites allow the lessons learned to be applied and Ada is also a big factor. It's funny how I got started on this rewrite- it was the farthest thing from my mind in January. I was starting to think about threads and matrix operations that might benefit etc. The Ada tasking model came into the thought process at some point. So now I'm looking forward to designing that into the interpreter when it gets further along. Just my own nearly at par $0.02 Cdn. Warren
From: Nasser M. Abbasi on 5 Apr 2010 15:24 "Charmed Snark" <snark(a)cogeco.ca> wrote in message news:Xns9D5189EB419BSnarkCharmedImSure(a)188.40.43.213... > > I am making big use of these containers in the rewrite of > my basic interpreter project. > I looked at the Ada 2005 LRM, Containers.Vectors for example, and And I have small question http://www.adaic.org/standards/05rm/html/RM-A-18-2.html Given this below function Element (Container : Vector; Index : Index_Type) return Element_Type; Then to get the element at index 5, one needs to write something like Element(V,5). Is there a way to redefine this so one need to only write V(5) ? because If I have large equations, it is more clear to write V(i) than Element(V,i) everywhere? Did you find this "longer" syntax an issue for you? I have not used Containers before. But the list of functions looks impressive. ps. is your interpreter project somewhere on the net to look at? thanks, --Nasser
From: Warren on 5 Apr 2010 16:28 Nasser M. Abbasi expounded in news:hpddc6$csh$1(a)speranza.aioe.org: >> I am making big use of these containers in the rewrite of >> my basic interpreter project. > > > I looked at the Ada 2005 LRM, Containers.Vectors for example, and And > I have small question > > http://www.adaic.org/standards/05rm/html/RM-A-18-2.html > > Given this below > > function Element (Container : Vector; > Index : Index_Type) > return Element_Type; > > > Then to get the element at index 5, one needs to write something like > Element(V,5). > > Is there a way to redefine this so one need to only write V(5) ? You could use V.Element(5), but that doesn't really shorten the notation. You could declare an internal function for that purpose, though there are probably better solutions: procedure My_Proc(args...) is package P is new Ada.Containers.Vector(...); V : P.Vector; Function XV(X : Index_Type) returns Element_Type is begin return V.Element(X); end; begin ... := XV(5); Note however (as I found out, snickers), you can't use the V.Element() notation when the input value is a cursor. That kept tripping me up until I clued in-- the cursor specifies both the container and position internally. So you must use Element(Csr) form of the call instead, for cursor values. > because If I have large equations, it is more clear to write V(i) than > Element(V,i) everywhere? Did you find this "longer" syntax an issue > for you? Not really, because when you deal with several containers (Maps mostly in my case), I tend to spell out the full package heirarchy anyway for clarity and to avoid hiding caused by "use". One thing I did do however, was create a SimpMap package that took care of all of the compare function definitions for me. I got real tired of redeclaring equality functions for every new integer/modular type involved. > I have not used Containers before. But the list of functions looks > impressive. > > ps. is your interpreter project somewhere on the net to look at? > > thanks, > --Nasser My Ada rewrite is still in the early stages, so it is not up on SourceForge yet. If you want to experiment with the C version, or look at the documentation, you can visit: https://sourceforge.net/projects/bdbbasic or for language and other documentation: https://sourceforge.net/apps/mediawiki/bdbbasic/index.php?title=Main_Page But if you email me directly, I can also send you the tar-balled Ada version of the project. You'll see a lot of container examples in it, which might be useful. Warren
From: none on 5 Apr 2010 16:51
On Mon, 05 Apr 2010 13:19:07 +0200, Georg Bauhaus wrote: > On 4/4/10 6:46 AM, Nasser M. Abbasi wrote: >> I was browsing the net for scientific software written in Ada, and came >> across this strange statement: >> >> http://farside.ph.utexas.edu/teaching/329/lectures/node7.html >> >> "Scientific programming languages >> What is the best high-level language to use for scientific programming? >> This, unfortunately, is a highly contentious question. Over the years, >> literally hundreds of high-level languages have been developed. However, few >> have stood the test of time. Many languages (e.g., Algol, Pascal, Haskell) >> can be dismissed as ephemeral computer science fads. Others (e.g., Cobol, >> Lisp, Ada) are too specialized to adapt for scientific use. >> >> ...... >> >> The remaining options are FORTRAN 77 and C. I have chosen to use C " >> >> I find this strange, because I think Ada can be the best programming >> language for numerical work. So, I do not know why the author above thinks >> Ada is "too specialized to adapt for scientific use". Is there something in >> Ada which makes it hard to use for scientific programming? > > The text, by Professor Fitzpatrick, Physics, 2006, appears to be an > fine example of quite useful justification rhetoric. > (Of the kind well explained by, e.g. Leon Festinger or Irving Goffman.) > It is full of false facts that in general would offer > to an author the comforts of blissful ignorance and a convincing > appearance at the same time. (Who has not been in this situation? > Assuming that a quick proactive defence of your standing is > more tempting than the alternative: is to shut up?) > > The only reason I can think of is pure fashion - Ada has not been taken up as a popular programming language for scientific use, therefore it is not suitable. But choosing a language based on popularity is not the best approach - although it does have some validity, providing you recognise that popular today does not mean popular when you *really* need maintenance on the software. Dismissing Algol as ephemeral ignores its influence and continuing usage as a base of pseudo-codes. Important numerical libraries were first implemented in ALgol, and later translated to Fortran when Algol's momentum faltered. But that again confuses usefulness of a language for scientific programming with popularity. Ada is heavily influenced by Algol, and I can see nothing in Ada that would prohibbit is wider uptake - other, again, than fashion. It was a language designed to promote re-usability, maximise correctness, and include efficiency and portability, and still has a variety of compilers available, so I can't see any reason why *not* to use it, if you are proficient in its use. |