| Re: IDL as programming language? [message #2728 is a reply to message #2725] |
Mon, 29 August 1994 07:19   |
thompson
Messages: 584
Registered: August 1991
|
Senior Member |
|
|
abz@waikato.ac.nz writes:
> (ii) Speed. Some of us Grads are running some really time consuming programs
> (large arrays, large loops). How does IDL compare with (say) FORTRAN in
> general, speedwise? (my impression is that it's pretty slow, but I could be
> wrong...)
Loops are very slow. On the other hand, you usually can do it without loops in
IDL. If you can't, there's always CALL_EXTERNAL or LINKIMAGE.
> (iii) Memory. How does IDL's memory management compare? Again, some of our
> programs (FORTRAN) have a tendency to gobblelarge chunks of memory (probably
> bad programming, but still...)
IDL does the same thing. I doubt if it would be any better than Fortran, but
don't know if it's any worse.
> (iv) What is a large IDL code like to debug?
Certainly no worse than Fortran, and one can fiddle with things to see how they
affect behavior much, much faster. According to the release notes for version
3.6, there is now a Motif-based interactive debugging tool for Unix platforms.
I haven't used it, but it should help things out quite a bit.
> (v) How 'robust' is IDL as a programming language? We have a variety of
> different programming styles here -- some prefer 'quick and dirty' programming,
> others a more structured approach. Forgive my possible ignorance, but I have
> the impression that IDL as a language is more suited to the 'quick and dirty'
> approach. Is this true? Does IDL as a programming language have many
> glitches or inconveniences from a mathematical programmers point of view?
I would agree with IDL as being oriented towards "quick and dirty" programming.
That doesn't mean that one can't put together large software systems--we do.
On the other hand, it doesn't enforce things like datatypes that other
languages might. This can either be a blessing or a curse, depending on your
point of view.
As far as inconveniences go, from a mathematical point of view, one can point
out the fact that IDL doesn't support a double-precision complex data type.
> Any info/advice would be much appreciated. The types of stuff we do
> here are generally large numerical (finite difference) codes on 2D and 3D grids.
> I'll wait a while before sending this to see if there is/has been any
> discussion on this topic in the newsgroup.
My impression has always been that IDL is best suited towards people (like
myself) who are working with actual data, with all the grungy details that
entails. People who use only "ideal" theoretical data tend to be more pleased
with packages like Mathematica or Mathcad.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
