 Programming Languages for Scientific Processing
started 11/20/2000; 10:01:20 AM - last post 11/21/2000; 11:27:01 AM
|
|
Chris Rathman - Programming Languages for Scientific Processing 
11/20/2000; 10:01:20 AM (reads: 919, responses: 6)
|
|
| Programming Languages for Scientific Processing |
|
For those who just want to take a shortcut and just have a graph to show them the best language for scientific processing, this is the place to go. The study was done a couple of years back so it doesn't reflect some advances in a couple of the languages.
A bunch of FP languages (CAML, Haskell, Clean, J, ....) are compared with the commonly used languages (C, Fortran, MatLab,...) in this field. Not to give the ending away but CAML scores really well in terms of both speed and abstractness.
Posted to "" by Chris Rathman on 11/20/00; 10:05:06 AM
|
|
|
|
Adam Vandenberg - Re: Programming Languages for Scientific Processing
11/20/2000; 11:50:24 AM (reads: 925, responses: 1)
|
|
|
I find this very interesting after reading the previously linked "C++ Templates as Partial Evaluation".
I thought the Template tricks were kind of clever, but they kind of give me the heebee-jeebees.
Instead of trying to do clever C++ hacks, I wondered if there were any other languages better suited toward scientific computing.
|
|
andrew cooke - Re: Programming Languages for Scientific Processing
11/21/2000; 1:50:19 AM (reads: 912, responses: 0)
|
|
|
Hmmm....
- You'd think a review of scientific languages would look at a modern Fortran rather than one from 1957! Fortran 90 might be what the writer was looking for... (and I believe many F90 compilers also have good support for parallelism - something very important for anyone using supercomputers these days, but also ignored by the article).
- Why even try to do GUI programming in the same language that you use for calculations?
- It doesn't seem very fair to judge the speed of Lisp-like languages by using Dylan (which is used much less widely than Common Lisp and has little commercial support).
- What about support from within the community? I can't imagine many Erlang programmers doing scientific processing, for example.
Not that I have anything against Caml...
|
|
andrew cooke - Re: Programming Languages for Scientific Processing
11/21/2000; 1:54:57 AM (reads: 989, responses: 0)
|
|
|
but they kind of give me the heebee-jeebees
Absolutely! (but I guess if you can use the library as a "black box" then it wouldn't matter)
|
|
Chris Rathman - Re: Programming Languages for Scientific Processing
11/21/2000; 8:17:28 AM (reads: 948, responses: 0)
|
|
You'd think a review of scientific languages would look at a modern Fortran rather than one from 1957! Fortran 90 might be what the writer was looking for... I think the '57 date was just a reference to when Fortran was originally written (back when it was called FORTRAN). Not sure what revision level was actually tested though.
Why even try to do GUI programming in the same language that you use for calculations? In my experience, a fast plotting package is a requirement (crossplot, graphs, etc...) but user interface is usually pretty minimal.
It doesn't seem very fair to judge the speed of Lisp-like languages by using Dylan (which is used much less widely than Common Lisp and has little commercial support). The author was using Mathematica and CLOS prior to the study for the bulk of the work (which the study was trying to make as a point of comparison).
As for Dylan, everything wrong that can go wrong, has happened to the language. I'm never quite sure why Dylan is so heavily compared to Lisp, but it does have multiple dispatch and some other flexibility that's not found in many other languages than CLOS (perhaps Cecil but that's more a research language). Anyhow, Dylan does provide much faster executables than many other OOP languages (Smalltalk, Eiffel, Java, etc), so it deserves to be in the study - though it's debatable whether it is part of the Lisp-like language family.
What about support from within the community? I can't imagine many Erlang programmers doing scientific processing, for example. Erlang provides some definite capabilities, but I would agree that Scientific Programming is not one of the fields that it's gonna excel in - unless we are talking distributed processing and then it becomes hard to beat.
|
|
Chris Rathman - Re: Programming Languages for Scientific Processing
11/21/2000; 9:23:23 AM (reads: 933, responses: 0)
|
|
Instead of trying to do clever C++ hacks, I wondered if there were any other languages better suited toward scientific computing. It's been nearly a decade since I've done stuff that qualifies as scientific computing - and most of that was in embedded instrumentation - so I haven't really kept up with the field. I was partially involved in one project where we were running Monte Carlo simulations on radiation clouds for pulsed neutron devices. We used a set of C libraries for that particularly programming chore and found working with complex numbers to be really cumbersome.
What with the advances in languages and processor speeds, a lot more options are available these days. I almost feel like these people are spoiled. :-)
Speaking of simulations, Lawrence Livermore was big into Sisal (a distributed Functional Programming language) at one time. But that project seems to have been deep sixed. They did manage to get Sisal to match some of the speed of Fortran, but I suppose their investment in nuclear simulations was just too much to go into new directions.
|
|
andrew cooke - Re: Programming Languages for Scientific Processing
11/21/2000; 11:27:01 AM (reads: 910, responses: 0)
|
|
|
I think the '57 date was just a reference to when Fortran was originally written (back when it was called FORTRAN). Not sure what revision level was actually tested though.
Fortran 90 (see the link I gave above) has features Fortran was criticised for not having (namespaces and data structures).
Also, I realise everyone is different, but I always found using stand-alone third party plotting packages saved a lot of effort (with Perl between Fortran and plotting package to change file formats/pre-process as required).
|
|
|
|