Interactive Data Language, IDL: Does anybody care?
- by Alex
Anyone use a language called Interactive Data Language, IDL? It is popular with scientists. I think it is a poor language because it is proprietary (every terminal running it has to have an expensive license purchased) and it has minimal support (try searching for IDL, the language, right now on stack) . I am trying to convince my colleagues to stop using it and learn C/C++/Python/Fortran/Java/Ruby. Does anybody know about or even care about IDL enough to have opinions on it? What do you think of it? Should I tell my colleagues to stop wasting their time on it now? How can I convince them?
Edit: People are getting the impression that I don't know or use IDL. Also, I said IDL has minimal support which is true in one sense, so I must clarify that the scientific libraries are indeed large. I use IDL all the time, but this is exactly the problem: I am only using IDL because colleagues use it. There is a file format IDL uses, the .sav, which can only be opened in IDL. So I must use IDL to work with this data and transfer the data back to colleagues, but I know I would be more efficient in another language. This is like someone sending you a microsoft word file in an email attachment and if you don't understand how wrong that is then you probably write too many words not enough code and you bought microsoft word.
Edit: As an alternative to IDL Python is popular. Here is a list of The Pros of IDL (and the cons) from AstroBetter:
Pros of IDL
Mature many numerical and astronomical libraries available
Wide astronomical user base
Numerical aspect well integrated with language itself
Many local users with deep experience
Faster for small arrays
Easier installation
Good, unified documentation
Standard GUI run/debug tool (IDLDE)
Single widget system (no angst about which to choose or learn)
SAVE/RESTORE capability
Use of keyword arguments as flags more convenient
Cons of IDL
Narrow applicability, not well suited to general programming
Slower for large arrays
Array functionality less powerful
Table support poor
Limited ability to extend using C or Fortran, such extensions hard to distribute and support
Expensive, sometimes problem collaborating with others that don’t have or can’t afford licenses.
Closed source (only RSI can fix bugs)
Very awkward to integrate with IRAF tasks
Memory management more awkward
Single widget system (useless if working within another framework)
Plotting:
Awkward support for symbols and math text
Many font systems, portability issues (v5.1 alleviates somewhat)
not as flexible or as extensible
plot windows not intrinsically interactive (e.g., pan & zoom)
Pros of Python
Very general and powerful programming language, yet easy to learn. Strong, but optional, Object Oriented programming support
Very large user and developer community, very extensive and broad library base
Very extensible with C, C++, or Fortran, portable distribution mechanisms available
Free; non-restrictive license; Open Source
Becoming the standard scripting language for astronomy
Easy to use with IRAF tasks
Basis of STScI application efforts
More general array capabilities
Faster for large arrays, better support for memory mapping
Many books and on-line documentation resources available (for the language and its libraries)
Better support for table structures
Plotting
framework (matplotlib) more extensible and general
Better font support and portability (only one way to do it too)
Usable within many windowing frameworks (GTK, Tk, WX, Qt…)
Standard plotting functionality independent of framework used
plots are embeddable within other GUIs
more powerful image handling (multiple simultaneous LUTS, optional resampling/rescaling, alpha blending, etc)
Support for many widget systems
Strong local influence over capabilities being developed for Python
Cons of Python
More items to install separately
Not as well accepted in astronomical community (but support clearly growing)
Scientific libraries not as mature:
Documentation not as complete, not as unified
Not as deep in astronomical libraries and utilities
Not all IDL numerical library functions have corresponding functionality in Python
Some numeric constructs not quite as consistent with language (or slightly less convenient than IDL)
Array indexing convention “backwards”
Small array performance slower
No standard GUI run/debug tool
Support for many widget systems (angst regarding which to choose)
Current lack of function equivalent to SAVE/RESTORE in IDL
matplotlib does not yet have equivalents for all IDL 2-D plotting capability (e.g., surface plots)
Use of keyword arguments used as flags less convenient
Plotting:
comparatively immature, still much development going on
missing some plot type (e.g., surface)
3-d capability requires VTK (though matplotlib has some basic 3-d capability)
