| Re: Migrate away from idl? [message #68757 is a reply to message #68681] |
Thu, 19 November 2009 13:03   |
MarioIncandenza
Messages: 231
Registered: February 2005
|
Senior Member |
|
|
Here's my list:
1) Routines that should absolutely be builtin (with massive royalties
paid to the original authors, of course):
HIST_ND (JD Smith)
PERCENTILES (Martin Schultz)
SETUNION|INTERSECTION|DIFFERENCE (RSI)
SYMCAT (David Fanning)
2) Builtins that should work better:
- DIM keyword for MOMENT (how can we not have this?!?)
- Why can't OPLOT or PLOTS do what OPLOTS (no attribution) can
(separate symbols,colors,sizes for each element of an array, specified
with array keywords)? This function needs to be builtin especially
because OPLOTS just loops through, and is therefore very slow.
- Why can't STRSPLIT work on arrays of strings?
- "% Only three levels of variable concatenation are allowed."
As for other packages:
I have another project that committed early on to Perl Data Language
(PDL), mostly because someone had written an interface to read HDF
files into PDL, and Perl was a language we felt comfortable with. I
had to buy our systems guy a six-pack after he got PDL running on our
machines-- if I didn't have a "systems guy," I would probably have
quit and ported the whole thing to IDL. I strongly believe IDL is
worth the money, if it does nothing but install cleanly and fully
functional, which none of its current competitors (except Matlab)
do.
Does it take 10-20 extra lines to get your PostScript up to pub.
quality in IDL? Yes it does, but you only have to write them once.
IDL's default settings could be better, but if you expect the default
settings to be exactly what you need, you're either doing something
really simple, or you've little experience. It's amazing, reading this
thread, to think how much damage IDL has done to themselves by not
setting FONT=0 as the default for PostScript.
Does it take 300 lines of code to get an image overlaid on a map
decently? Yes it does-- well, there's definitely some room for
improvement there.
For applications pointed at "end-users" IDL is just a dog. But for
scientific users who aren't programmers by training, the incumbent
advantage of the millions of lines of IDL code free for the taking is
not to be dismissed lightly.
But I'm glad people continue to explore and report back, because like
David, I hope that it puts some pressure on ITTVis.
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
