I saw the discussion on comp.lang.idl-pvwave about Why IDL Sucks. While the author probably just needed to vent his frustrations on not getting IDL to do what he wanted, I think it’s worthwhile to examine the complaints because I think many programmers new to IDL may have many of the same misconceptions (think of it as an addendum to my 12 tips for beginning IDL programmers article).

  1. Integer-to-float conversions. IDL will promote operands to match the precision of the most precise operand. So 7 / 2 = 3 since they are all integers. When either operand is a float, you get a float result: 7. / 2 = 7 / 2. = 3.5. This is “the right thing” to do (as evidenced that every dynamic programming language I know does it this way).

  2. The compiler. Welcome to the world of dynamic languages! IDL doesn’t know about many errors until it executes the code because things can change right up to that point. This is a feature (though of course it has a downside and isn’t appropriate for every programming task). This is no different than Python, Ruby, or any other dynamic language. Not sure what you mean by “when IDL actually does manage to catch an error, there’s about a 0.00001 probability of it telling you what line the error is on.” It always tells me. Are you using CATCH or ON_ERROR? I would recommend you use them only when you have to and when you know what you are doing.

  3. FOR-loops. “This inadequecy is completely inexplicable.” There are loops in IDL, so you must be talking about the fact that vectorized operations are faster than loops. This is the same for other interpreted languages, most notably see Matlab and Python (with it’s NumPy, numeric, etc. numerical packages).

  4. Recompilation. IDL doesn’t automatically save compiled routines to files. That would be a nice feature. Check out the SAVE to do it manually.

  5. Pass by reference…sometimes. Yes, IDL passes named variables by reference. “You can’t expect a programmer to keep track of when he’s passing by reference and when he’s passing by value unless you make explicit use of pointers.” I’m not sure why that would be; if you’re passing a named variable, you’re passing by reference.

  6. Column-major array ordering. This is because IDL was designed to handle images. So IDL uses image-processing convention of [column, row] i.e. [x, y]. “Every other language in the history of mankind is row-major.” Don’t tell Fortran that.

  7. Redefinition of structures. You can’t redefine a named structure without doing a .reset (or exiting IDL). That’s the reason you would use a named structure. Anonymous structures can be redefined all you want; named structures enforce consistency.

  8. Ugly Histograms. Yes, there are some issues. Not sure which you are talking about here, though.

  9. Anti-parallelism. Check out the thread pool. For more control, check out Tech-X’s FastDL.

  10. Integer indexing of FOR-loops. Yes, it’s odd that unlike any other named variable in IDL, the index of a FOR loop doesn’t change type as needed. It gets its type from the start value of the FOR loop and it doesn’t change inside the loop. (This probably has to do with some kind of internal optimization to try to make FOR loops a bit faster, but I’m not sure really why this is, it just is.)

  11. Data-type comparison inconsistencies. “But for 0.2, the float type has roundoff error.” So does the double.

IDL> print, 0.2D, format='(F25.20)'

This article has useful information that every IDL (or scientific) programmer needs to know.

  1. Logical operators with floats and ints. IDL chose Fortran style over C style for the truth value of integers. You can chose the C style with
compile_opt logical_predicate
  1. Non-existent variables still exist. This is IDL’s version of Schrodinger’s cat because naming a variable brings it into existence (as an undefined variable). “Existing” really isn’t a useful property. “Defined” is more useful. Then, your test
print, n_elements(stupidvariablethatIhaventdefinedyet)

tells you exactly that stupidvariablethatIhaventdefinedyet isn’t defined.

  1. Global variables in FOR-loops. I’m not sure why you can’t do this, but it probably has to do with point 10 above. System variables are just one kind of global variable in IDL. I would try to stay away from them as much as possible. Try heap variables (pointers and objects). Common blocks and system variables have their uses (I suppose), but they are asking for trouble.

So, yes, there are some things to watch out for in IDL. But with a little forewarning, you can get IDL to solve your problems (and probably much faster than constantly recompiling your 100 times longer C program).