Re: thoughts on dynamic from a beginner's perspective
- From: Jon Harrop <jon@xxxxxxxxxxxxxxxxx>
- Date: Sun, 08 Feb 2009 05:21:12 +0000
Dan wrote:
On Feb 7, 8:16 am, Jon Harrop <j...@xxxxxxxxxxxxxxxxx> wrote:
Dan wrote:
I still don't see what purpose would be served by translating good
working engineering and heavy duty numerical codes from Fortran to
another language such as Lisp ( or C++ or 'take your pick' ). In
fact, I'll contend taht Fortran is still a very good language for
writing such codes today (fortran is no more a relic than Lisp is).
I've yet to hear a good argument for "translating" such codes.
Money. If you're selling good numerical codes then you will make a lot
more money by targetting popular languages than if you try to sell people
Fortran code.
Well... quite often, you need a code that has a functional purpose
within your own organization rather than one whose main purpose is to
make money through sales.
Then: safety. Interoperating between managed languages makes it trivial to
debug programs with no risk of segmentation faults or access violations.
That saves development time and, therefore, money.
Fortran only works well for certain kinds of numerical programs. For many
other numerical programs (e.g. FFT, FMM, DWT, suffix trees) Fortran is
suboptimal. For some other programs, particularly those requiring rich
data structures, Fortran is down right awful.
There are certainly codes for which fortran is not optimal. But...
there are also quite a few codes for which it is very optimal.
Very few, I think. Fortran has been almost entirely squeezed out by vendor
tuned libraries written in assembler (e.g. Intel MKL) and high-level
languages that are vastly more productive to develop in (e.g. Mathematica,
OCaml).
Indeed, I am only familiar with a single active project written in Fortran:
CASTEP.
In the same light, you don't want some CS who's good at other
languages (maybe many languages) leading the developement of an
engineering or scientific code which requires an intense knowledge of
physical science and numerical analysis techniques.
I disagree. Familiarity with modern approaches is beneficial not
detrimental.
Yes and No. First off, not all modern approaches are necessarily
beneficial (though they may often be assumed as such).
Can you give specific examples?
If they were always truly beneficial, then we wouldn't see them come and
go so quickly.
Again, what exactly are you referring to?
Secondly, whenever you have someone without the numerical/
analytical knowledge making decisions on which algorithms to use for a
very scientific problem making the decisions, you're usually asking
for trouble.
Sure but you said they knew about modern software practices and not that
they did not know about numerical methods.
My bottom line "preference" for a large engineering or scientific code
would be for it to be lead by an engineer who is also well versed in
programming. A CS who's versed in engineering would be fine too,
but... those guys are more rare.
I see. By "CS" you imply that they are not familiar with numerical methods?
That is not always a clear distinction. For example, my degree was mostly
physics but also part CS.
Of course, another reason I feel languages such as fortran are often
good for numerical codes is because they will likely be maintained by
other engineers, etc. in the future. For those situations, I like
the idea of keeping things simple. I've seen enough engineers alter
and mess up fortran code. Imagine those same guys trying to maintain
a more complex language?
Modern languages are often simpler. For example, all functions accept one
argument value and return one value in ML, multiple values are represented
by tuples and there are no restrictions upon where function values can go.
That is a *lot* simpler that Fortran where there are many unnecessary
restrictions ranging from no recursion in F77 to no environment capture in
F2003.
Their strengths are often in their science rather than in their
programming wares.
Conversely, their programming wares can be their weakness.
I know a lot of computational scientists and would only trust the ones
familiar with modern languages to do a good job in developing numerical
software. I would not even consider collaborating with any scientists
developing software who were not familiar with modern techniques. They
would certainly do more harm than good.
So... I take it you agreed with my "reading" of the Fatemen paper
then?
Oh yes. :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?u
.
- Follow-Ups:
- References:
- Prev by Date: Re: Which language would choose?
- Next by Date: Re: Which language would choose?
- Previous by thread: Re: thoughts on dynamic from a beginner's perspective
- Next by thread: Re: thoughts on dynamic from a beginner's perspective
- Index(es):
Relevant Pages
|
Loading
