Hi Tim, Thanks for the feedback. I have to disagree on a few points. IDL is a 30+ year old language, and it has several key strengths: 1. Backwards compatibility. We try very hard to not break existing code. Occasionally we do make significant changes to the language (IDL 8.0 for example) but they are always enhancements, not breakage. Because of this, we need to be very careful when changing existing routines like the Contour procedure - if we changed it, we would need to guarantee that the resulting plots looked virtually identical to the previous plots. 2. Cross platform. If you write a widget application in IDL, it's going to look and work the same on all platforms, with just a few minor exceptions. Our remote-sensing ENVI application is a good case. It's about a million lines of IDL code, of which only a few hundred (at the most) are platform specific. However, because our widget toolkit is cross platform, we sometimes need to make compromises on functionality to avoid platform differences. 3. Ease of programming. IDL is designed primarily for scientists and engineers, who want to quickly import data, analyze it with vector arithmetic, and then produce publication-quality results. It also comes with everything out of the box - you get all of the common file formats - jpeg, tiff, scientific formats like NetCDF, XML, a URL object; a cross-platform widget toolkit; all of the built-in math routines, as well as two different graphics systems - the low-level direct graphics and the modern object graphics. Finally, you get the IDL Workbench development environment, based on Eclipse. 4. Support and maintenance. We have an excellent technical support team that consistently gets kudos for rapid response and solving customer needs. We also do product releases on a very regular basis, with significant enhancements. We also have a product services group that can build custom solutions for customers. 5. Forward looking. Direct graphics (like the contour procedure) is old and crufty. In IDL 8.0 we added a new "function" graphics system, along with many new language features such as automatic garbage collection, lists & hashes, operator overloading, the null operator, simple "." notation for object-oriented programming, and a foreach operator. In IDL 8.1 & 8.2 we continued to enhance the new graphics, added Google Earth KML output, added internationalization conversion routines, JSON parsing, etc. We are also developing new solutions for cloud-based computing, so you can deploy IDL on a server and create clients (web pages, mobile apps, etc.) that use IDL to access & process data. Hope this helps. Cheers, Chris IDL Software Engineering Manager Exelis VIS

I agree with most of this, although I strongly disagreed with the "old and crufty" part, until I realized you were describing the Contour command and not me. :-) In fact, these old and crufty commands are still more flexible and are often (I would say usually) easier to manipulate to get the final graphical result you want. Although, I guess I am talking about Coyote Graphics commands here, because I pretty much never use a TV or Surface command anymore and haven't in the past 15 years or so. But, this week I wanted to know the area enclosed by an isocontour line and I could find no way to get that information without resorting to the old PATH_XY keyword on the venerable Contour command. Perhaps there is a way with function graphics, but I certainly couldn't find it. This brings up a further point. It is extremely difficult to switch to a new graphics system that (A) is still having the bugs worked out of it, and has essential parts of it (e.g., a workable Colorbar) still missing, and (B) is so poorly documented. It becomes virtually impossible to know if something is not working because it is buggy or because you are doing something stupid. Of course, we all know who I am going to blame! (I'm probably not so different than most of your customers in this regard. Or, if so, only in the fact that I am sometimes willing to admit I've done something stupid.) Just to give an example from this morning, I'm trying to get an image to honor the Position keyword. How hard can that be? Well, I've been at it for a hour and a half with no joy so far. As I say, frustrating! Aside from just general frustration (at the slowness, at the way you seem to have to do something wrong, then put it right and have to watch it render all those painful steps, at not knowing whether something is working as it suppose to, etc.) my biggest problem with function graphics is its complete lack of programmability. Maybe this is related to lack of documentation. But, I seriously doubt that anyone outside the walls of Excelis will ever be able to create a new graphics procedure on their own. Nor will they ever be able to fix one that is broken. I can add a feature to a Coyote Graphics program in less than half an hour most of the time. I couldn't add a feature to a function graphics command if I had half a year to do it! Anyway, from where I stand, that doesn't look as "forward looking" as I wish it did.

Hi Chris, Thanks for the reply. I will try to make this my last post as I’m starting to feel like a broken record. You say you have to disagree on a few points however you seem to have confirmed both of my points. Me: “the way in which the inbuilt library is left to stagnate” You: “IDL is a 30+ year old language”, “Direct graphics (like the contour procedure) is old and crufty” Me: “poor GUI abilities such as no styled text box widget (i.e. the ability to change the colour, font, etc of text in a text box)” You: “However, because our widget toolkit is cross platform, we sometimes need to make compromises on functionality to avoid platform differences.” So I’m not exactly sure what you are disagreeing with. However I do have some comments on some of yours points. Backwards compatibility. I totally agree that any changes to the existing procedures need to be backwards compatible, this is goes without saying. But that’s no reason for not making updates. As for continuing to support every bit of functionality good or bad ever introduced in a 30+ year old language without depreciating things from time to time, your digging your own grave there. For example if the /cell_fill part of the contour function is clearly a weak point why can’t that part of the procedure be depreciated and a new procedure be introduced say contourf as a replacement that way users can expect some difference in functionality. Depreciating a feature gives users time to update their code to use the new feature before its finally removed, and is a well established practice in just about every other successful language. I just can’t see how it’s a good idea to blindly keep functionality around indefinitely that is a weak spot in a language. This is partly what gave the need for libraries such as Davids in the first place. Cross platform. “If you write a widget application in IDL, it's going to look and work the same on all platforms” umm forgive me if I’m wrong but this statement is not correct at all. From my use of IDL it seems that IDL on Windows uses native windows widgets much like the Java SWT library, where as the *nix platforms seem to have some kind of custom draw interface that looks quite different. Also its behaves differently for example on windows if I have a classic drop down menu that contains a widget_buton with further sub menus, on windows the sub menus open when the mouse hovers over the menu button however on *nix I need to click the button before the sub menu appears. I do agree that functionality needs to be a compromise as providing cross platform support is difficult. However a styled editable text box should hardly be a hard thing to build and support. Ease of programming. I agree with most of what you said here IDL does a pretty good job of running out of the box. The only things I would site here is that you point to the two graphics libraries, where the stagnation and limitations of one of those is the whole point of this topic, and second “IDL is designed primarily for scientists and engineers, who want to quickly import data, analyze it with vector arithmetic, and then produce publication-quality results” Sure this is one target audience but it is clear that you want to expand that to large projects rather than just the quick analysis of data. Your desire to support server side applications shows this, and is likely to attract more pure programmers/computer scientists (like myself) to maintaining permanent IDL applications. Support. I’ll take you word on this ;-) Forward looking. While it is good to see Exelis has a plan to extend the abilities of IDL. I can’t be help worry the some of it is niceties that come at the expense of the improvement/replacement/redevelopment of existing and essential features. Anyway this is just my view, hopefully its useful feedback. By the way I’ve tested the Object Graphics library and aside from the points David has already made is just far to slow to be a viable alternative to Direct Graphics.

Just to conclude my rant from yesterday about how difficult it is to make an image fill up a window, it turned out that the documentation for the ASPECT_RATIO keyword to the Image() function explains exactly the opposite of what is actually the case. But, even when you figure that out you aren't home yet. It turns out that if you really want the image to show up in the right place, you also have to use the ASPECT_RATIO keyword in the same way on the Map() function. This keyword is not even documented for the Map() function. Misleading documentation, undocumented keywords, lots and lots of frustration. This is continually my experience with Function Graphics.