Interactive Data Language, IDL: Does anybody care? [closed]

Question

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)

Answer 1

So many IDL fanboys here! I'm also an astronomer and I've extensively used IDL and Python. All I can say is that IDL survives to this day because of the laziness of fellow astronomers, who can't or don't want to learn new better programming language. Most of my colleagues haven't used anything else besides Fortran or IDL. For them there's only IDL in the entire world. By the way, many of the younger astronomy students are also all about IDL and don't even want to check Fortran, or god forbids Python or C/C++. Those are languages for programmers and mathematicians, and not for astronomers.

About the licensing fees. How many IDL versions have been and how many of them has your university bought? I guess many...

Yeah, go ahead buy that new IDL 8.x version. I've heard that its the new plotting package allows you to modify parts of the plot after it's been generated. WOOOW! That's so cool!

p.s. There's nothing in IDL that can't be done in Python in a much better and cleaner way. Most of the scientific tools in it are extensive and very stable. I haven't had any problems with plotting all sorts of plots in matplotlib. Its GUI tools are excellent and intuitive, and not unlike the crappy IDL "widgets".

This is very much alike the situation in my old university, where the old professors were kinda stumped by time, because they refused to learn anything new in programming. They became not competitive and stopped doing any significant work.

Answer 2

I'm an fMRI researcher at Children's Hospital in Cincinnati, and for years radiology researchers here have used IDL to develop an image processing package (called CCHIPS). It is a very well developed package, and has had quite a few people expanding its utility over the years. Even though I'm pretty much a hardcore MATLAB user, and therefore have a tendency to lean towards packages like SPM for fMRI image processing, I still end up using CCHIPS and writing/editing a few IDL scripts quite often. It's not as "comfortable" to me as MATLAB (we all have out favorite "blankies", after all!), but it's fairly easy to learn.

I guess my point is this... If a programming resource works well, is well established, is used well by many, AND (most importantly!) there are still people within your organization willing to maintain/debug/modify/expand the resource, then there's no need to take an alarmist stance that changing to something new must be done immediately. If there were no one at all at your institution willing to maintain a resource any more, that may be cause for urgent concern. Otherwise, I would suggest getting a little more familiar with what you don't like, then applying gentle pressure to introduce what you feel is a better option, backing it up with clear reasons for change.

Answer 3

I'm a climate scientist, and I use IDL every day. It's a love-hate relationship. But I'm going to come to IDL's defense here because I don't think you've articulated good reasons for the scientists you work with to make the switch.

The only viable replacement for IDL in that list is Python coupled with the full set of scientific libraries. Even then, many things are harder, or more verbose in python than in IDL. Languages like C and Fortran are just too low level for tooling around analysing a dataset or making some figures, and they lack an interactive shell.

Most scientists are interested in getting answers to questions, and tools like IDL, Matlab, and NCL are purpose built to help us get answers faster.