交互式数据语言，IDL：有人关心吗？
有人使用一种称为交互式数据语言 (IDL) 的语言吗？ 它很受科学家的欢迎。 我认为它是一种糟糕的语言，因为它是专有的（运行它的每个终端都必须购买昂贵的许可证）并且它的支持很少（尝试搜索 IDL，该语言，现在在堆栈上）。 我试图说服我的同事停止使用它并学习 C/C++/Python/Fortran/Java/Ruby。 有没有人足够了解甚至关心 IDL 并对其发表意见？ 你怎么看呢？ 我现在应该告诉我的同事停止在这上面浪费时间吗？ 我怎样才能说服他们？
编辑：人们的印象是我不了解或不使用 IDL。 另外，我说过 IDL 的支持很少，这在某种意义上是正确的，所以我必须澄清科学图书馆确实很大。 我一直使用 IDL，但这正是问题所在：我只是因为同事使用它才使用 IDL。 IDL 使用一种文件格式 .sav，该格式只能在 IDL 中打开。 因此，我必须使用 IDL 来处理这些数据并将数据传输回同事，但我知道使用另一种语言会更有效率。 这就像有人在电子邮件附件中向您发送了 microsoft word 文件，如果您不明白这是多么错误，那么您可能写了太多单词而没有足够的代码，并且您购买了 microsoft word。
编辑：作为 IDL 的替代品，Python 很流行。 以下是 IDL 的优点（以及缺点）的列表，来自 < a href="http://www.astrobetter.com/" rel="noreferrer">AstroBetter：
IDL 的优点
- 成熟的许多可用的数值和天文库
- 广泛的天文用户群
- 数值方面与语言本身很好地集成
- 许多本地具有丰富经验的用户
- 小阵列速度更快
- 更容易安装
- 良好、统一的文档
- 标准 GUI 运行/调试工具 (IDLDE)
- 单一小部件系统（无需担心选择或学习哪个）
- 保存/恢复功能
- 使用关键字参数作为标志更
方便IDL
- 适用性窄，不太适合一般编程
- 大型数组速度较慢
- 数组功能不太强大
- 表支持较差
- 使用 C 或 Fortran 进行扩展的能力有限，此类扩展难以分发和支持
- 昂贵，有时与其他没有或没有这些功能的人协作会出现问题买不起许可证。
- 闭源（只有 RSI 可以修复错误）
- 与 IRAF 任务集成非常尴尬
- 内存管理更尴尬
- 单个小部件系统（如果在另一个框架中工作则无用）
- 绘图：
- 对符号和数学文本的支持很糟糕
- 许多字体系统、可移植性问题（v5.1 有所缓解）
- 不那么灵活或可扩展
- 绘图窗口本质上不是交互式的（例如，平移和缩放）
Python 的优点
- 非常通用和强大编程语言，但易于学习。 强大但可选的面向对象编程支持
- 非常大的用户和开发人员社区，非常广泛的库基础
- 使用 C、C++ 或 Fortran 进行扩展，可移植的分发机制
- 免费； 非限制性许可； 开源
- 成为天文学的标准脚本语言
- 易于与 IRAF 任务一起使用
- STScI 应用工作的基础
- 更通用的阵列功能
- 大型阵列速度更快，对内存映射的支持更好
- 许多书籍和在线文档资源可用（针对该语言及其库） )
- 更好地支持表格结构
- 绘图
- 框架 (matplotlib) 更具可扩展性和通用性
- 更好的字体支持和可移植性（也只有一种方法）
- 可在许多窗口框架（GTK、Tk、WX、Qt...）中使用
- 独立于所使用框架的标准绘图功能
- 绘图可嵌入其他 GUI 中
- 更强大的图像处理（多个同时 LUTS、可选的重采样/重新缩放、Alpha 混合等）
- 支持许多小部件系统
- 对为 Python 开发的功能具有强大的本地影响力
Python 的缺点
- 更多需要单独安装的项目
- 在 中不太被接受天文学界（但支持明显增长）
- 科学图书馆还不成熟：
- 文档不完整、不统一
- 对天文图书馆和实用程序的了解不够深入
- 并非所有 IDL 数值库函数都在 Python 中具有相应的功能
- 一些数值结构与语言不太一致（或者比 IDL 稍微不太方便）
- 数组索引约定“向后”
- 小阵列性能较慢
- 没有标准 GUI 运行/调试工具
- 支持许多小部件系统（担心选择哪个）
- 当前缺乏相当于 IDL 中的 SAVE/RESTORE 的功能
- matplotlib 尚未提供所有 IDL 2-D 的等效功能绘图功能（例如，曲面图）
- 使用关键字参数作为标志不太方便
- 绘图：
- 相对不成熟，仍有大量开发工作
- 缺少某些绘图类型（例如曲面）
- 3-d 功能需要 VTK（尽管 matplotlib 具有一些基本的 3-d 功能）
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)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（13）
这里有这么多 IDL 粉丝！ 我也是一名天文学家，并且广泛使用 IDL 和 Python。 我只能说，IDL 能够存活至今，是因为天文学家们的懒惰，他们不能或不想学习新的更好的编程语言。 我的大多数同事除了 Fortran 或 IDL 之外没有使用过其他任何东西。 对他们来说，全世界只有 IDL。 顺便说一句，许多年轻的天文学学生也都热衷于 IDL，甚至不想检查 Fortran，或者上帝禁止 Python 或 C/C++。 这些是程序员和数学家的语言，而不是天文学家的语言。
关于许可费。 IDL 版本有多少个？您的大学购买了多少个？ 我想很多...
是的，继续购买新的 IDL 8.x 版本。 我听说它的新绘图包允许您在生成绘图后修改部分绘图。 哇！ 这太酷了！
ps IDL 中没有什么是 Python 中不能以更好、更简洁的方式完成的。 其中大部分科学工具都是广泛且非常稳定的。 我在 matplotlib 中绘制各种绘图时没有遇到任何问题。 它的 GUI 工具非常出色且直观，与蹩脚的 IDL“小部件”没有什么不同。
这和我以前的大学的情况非常相似，那里的老教授们都被时间难住了，因为他们拒绝学习编程中的任何新东西。 他们变得没有竞争力并停止做任何重要的工作。
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.
我是辛辛那提儿童医院的功能磁共振成像研究员，多年来，这里的放射学研究人员一直使用 IDL 开发图像处理包（称为 CCHIPS）。 这是一个非常完善的软件包，多年来已经有很多人扩展了它的实用性。 尽管我几乎是 MATLAB 的铁杆用户，因此倾向于使用 SPM 等软件包进行 fMRI 图像处理，但我最终仍然经常使用 CCHIPS 并编写/编辑一些 IDL 脚本。 对我来说，它不像 MATLAB 那样“舒服”（毕竟我们都有最喜欢的“毯子”！），但它相当容易学习。
我想我的观点是这样的......如果一个编程资源运行良好，建立良好，被许多人很好地使用，并且（最重要的是！）您的组织内仍然有人愿意维护/调试/修改/扩展该资源，那么就没有必要采取危言耸听的立场，认为必须立即采取新措施。 如果您的机构中根本没有人愿意再维护资源，这可能会引起紧急关注。 否则，我建议您稍微熟悉一下您不喜欢的内容，然后施加温和的压力，介绍您认为更好的选择，并以明确的改变理由来支持它。
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.
我是一名气候科学家，我每天都使用 IDL。 这是一种又爱又恨的关系。 但我要在这里为 IDL 辩护，因为我认为你没有为与你一起工作的科学家阐明做出转变的充分理由。
该列表中唯一可行的 IDL 替代品是 Python 以及全套科学库。 即便如此，Python 中的许多事情也比 IDL 更难或更冗长。 像 C 和 Fortran 这样的语言对于分析数据集或制作一些图形来说水平太低，而且它们缺乏交互式 shell。
大多数科学家都对获得问题的答案感兴趣，而 IDL、Matlab 和 NCL 等工具是专门为帮助我们更快地获得答案而构建的。
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.
要击败你的敌人你必须学习它，尽管不一定掌握它。
我会选择您最喜欢的一种语言，并将其与 IDL 进行比较和对比。 IDL有什么优势？ 有什么缺点？ 请您的同事向您展示一些他们最喜欢的用 IDL 编写的代码，并将其与您最喜欢的一些代码片段进行比较。 这可能并不全是坏事——毕竟人们花了大量的钱并使用它。
试图取代最喜欢的东西可能不是赢得朋友或赢得争论的好方法。 如果您得出结论认为 IDL 仅提供很小的优势或没有优势，那么请尝试构建从较新的语言（例如 Ruby）到 IDL 的网关，以便人们可以结合使用这两种语言。 您可能正在尝试消除一种根深蒂固的文化，这种文化对 IDL 非常满意，非常感谢，但如果他们采用混合方法并最终用另一种语言取代他们的 IDL，因为另一种语言实际上更优越，那么你将会产生积极的影响。
无论如何，我从来不喜欢范式转变和浪费时间和金钱为了获得另一种工具的意识形态利益而投资于一种工具是一个糟糕的商业决策。 然而，在有意义的情况下，旧的专有技术必须被逐步淘汰——尽管分阶段的方法是关键。
To defeat your enemy you must learn it, though not necessarily master it.
I would take a favorite language of yours and compare and contrast it to IDL. What advantages does IDL have? What disadvantages? Ask your colleagues to show you some of their favorite code written in IDL and compare it with some of your favorite code snippets. It may not be all bad - people are paying big bucks and using it after all.
Trying to replace something that is a favorite may not be a good way to win over friends or win an argument. If you conclude that IDL offers only slim or no advantages then try to build a gateway from a newer language (such as Ruby) to IDL so people can use either in conjunction. You may be trying to remove an entrenched culture that's very-happy-with-IDL-thank-you-very-much, though if they take to a hybrid approach and eventually replace their IDL with another language because the other language is actually superior then you'll have made a positive impact.
Whatever the case, I'm never a fan of paradigm shifts and losing time and money invested in one tool for ideological benefits of another is a bad business decision. However old proprietary technology must be phased out when it makes sense to do so - though a phased approach is key.
作为一名博士。 天文学学生 我大约一年前开始使用 IDL。 我也不完全相信这种语言，当然也对它的专有性感到非常恼火（但请查看开源变体 GDL： http://gnudatalanguage.sourceforge.net/）。 然而，它是一种非常强大的语言，内置了许多科学家经常使用的工具和功能，例如，它可以开箱即用地进行各种拟合，并且具有大量可供使用的图形绘图工具。 此外，还有许多基于 IDL 构建的工具，例如 IDL 天文学用户库 (http://idlastro.gsfc .nasa.gov/）。 因此，虽然一开始将所有这些工具实现为一种开放语言可能会更好，但恐怕现在已经没有回头路了，因为这么多人正在使用并且已经习惯了它。
Being a Ph.D. student in astronomy I started using IDL about a year ago. I'm also not entirely convinced of this language and certainly quite annoyed by it being proprietary (but check out the open-source variant GDL: http://gnudatalanguage.sourceforge.net/). Nevertheless it is a very powerful language that has many tools and functions built in that scientists use a lot, e.g. it can do all sorts of fits out of the box and has a large number of graphical plotting tools ready to use. Also, there are many tools that built upon IDL, like the IDL Astronomy User's Library (http://idlastro.gsfc.nasa.gov/). So, while it might have been better to implement all these tools into an open language in the beginning, I'm afraid there is no back now that so many people are using and -- and have gotten used to it.
如果费用是主要考虑因素，并且您只需要 IDL 语言解释器本身，而不是花哨的软件包，那么您可能会对 Fawlty Language 感到满意，它是 IDL 的免费克隆。
（链接现已失效！） http://fl.net23.net/
我实际上已经做了真正的工作用这个而不是 IDL 向公众发布，没有告诉老板，作为测试，并成功了，但后来我主要运行非 GUI 程序并进行交互式命令行工作。 我上次检查时 GUI 小部件不完整。 然而，在编程的简单性方面，Fawlty 远远领先于 GDL。
If the con of expense is the main concern, and you need only the IDL language interpreter itself, not the fancy packages, you could be happy with Fawlty Language, a free clone of IDL.
(link now dead!) http://fl.net23.net/
I've actually done real work released to the public with this instead of IDL, w/o telling the boss, as a test, and succeeded, but then I mostly run non-GUI programs and do interactive command line work. GUI widgets weren't complete last time I checked. However, Fawlty was way ahead of GDL in terms of straightforward programming.
我是一名天文学家，多年来一直使用 IDL。 它有一些非常好的东西 - 例如数组处理，包括字符串数组 - 并且有相当多的天文学相关例程可用。 另一方面，作为一种语言我更喜欢Python。 成本是 IDL 许可证的一个问题 - 即使对于单个用户来说也不便宜。 还有其他的烦恼。 IDL 默认生成的 PostScript 绘图不是很好。 每次都指定粗线，而且字体有点难看，这很烦人。 我已经开始使用 matplotlib python 模块，它有很多值得推荐的地方。 例如，不需要重新制作绘图来更改轴标题。 我只希望我有所有这些方便的 IDL 天文学库例程，都是用 python 为 matplotlib 编写的。
I'm an astronomer and have used IDL for many years. There are some things that are very nice about it - e.g. array handling including string arrays - and quite a bit of astronomy related routines are available. On the other hand, as a language I prefer python. Cost is an issue for IDL licenses - not cheap even for a single user. There are other annoyances as well. The PostScript plots that IDL makes by default are not very good. It's annoying to have specify thick lines every time and the font is kinda ugly. I've started using the matplotlib python module and it has much to recommend it. For example, one doesn't need to remake a plot to change an axis title. I only wish that I had all those handy IDL astronomy library routines written in python for matplotlib.
好吧，我确实在堆栈上搜索了 IDL，这就是我到达这里的原因！ :-)
我已经编程了近 30 年，并且刚刚学习 IDL。 到目前为止，我承认我并不太喜欢它。 然而，它确实具有许多其他语言所没有的一些功能（例如，数学数组运算可以使用单个命令完成，而不是使用循环或其他一些设备）。
正如其他人所说，IDL 的流行在一定程度上是文化因素和根深蒂固的问题。 我第一次听说 IDL 是在大约 20 年前。 那时，在我看来，Stallman 提出了一些不错的想法和一些有用的工具，而 Linus 还没有发布他著名的 comp.os.minix 消息。 因此，IDL 在任何具有竞争力的开源领域都处于领先地位。 据我所知，开源社区中还没有任何东西具有竞争力（我了解 GDL，但如果我没记错的话，它远远落后于 IDL - 我很乐意纠正这一点）。 最终，它可能会被取代，但我不认为这种情况会很快发生。
Well, I did search for IDL on stack and that's how I got here! :-)
I've been programming for almost 30 years and am just learning IDL. Thus far, I admit that I'm not overly fond of it. However, it does have some things that many other languages don't have (e.g. mathematical array operations can be done with a single command, not with loops or some other device).
As others said, IDL's popularity is somewhat cultural and a matter of being entrenched. I first heard of IDL almost 20 years ago. At that point in time, it seemed to me that Stallman had some nice ideas and a few useful tools out, and Linus had not yet put out his famous comp.os.minix message. Thus IDL had a good head start on anything open source that would be competitive; to my knowledge nothing in the open source community is competitive yet (and I know about GDL, but if I'm not mistaken, it's way behind IDL - I'd be happy to be corrected on that). Eventually, it may be supplanted, but I do not expect that to happen soon.
如果我错了，请纠正我，但你是在问你是否应该告诉你的同事“停止浪费时间”在一门语言上，你不知道，但不喜欢，因为它是专有的？？？
嗯，我认为这有点短视。 首先，您应该询问您的同事“为什么他们使用 IDL”。 我已经断断续续地使用 IDL 大约十五年了，我想他们会告诉你“因为我可以快速完成我必须做的事情”。 我已经使用 IDL/C++/LabVIEW/Python/Pascal 进行编程 20 年了，我认为您应该使用最适合这项工作的语言/环境。 我不会将 IDL 用于华丽的用户界面应用程序，但对于千兆字节数据的分析和可视化来说，它很难被击败。 （我当然不会为此使用 Python 或 Ruby！）
关于 IDL 是专有软件。 确实如此（尽管您不需要需要昂贵的许可证来运行 IDL 应用程序。您可以使用虚拟机来运行应用程序，但需要昂贵的（真正的）许可证来开发应用程序）。 但是，专有有什么问题呢？ 我的汽车是专有产品（我猜你的也是:-)），我的电视机、电话等也是专有产品。
因此 IDL 是专有的，这意味着您无法更改语言（除了要求 ITTVIS 进行更改之外），但您甚至不知道该语言！ 所以有什么问题？ （顺便说一句，提到了开源版本 GDL，还有其他（开源）替代方案）。 您对 C++/Python/Ruby 等做出了多少贡献？
我希望专有论点不会因为您不喜欢（高）许可费而被（误）使用？ 确实有免费的（读：没有钱转移）C++/Python/Java 编译器，但 ITTVIS 是一家商业公司，想要赚钱。 好吧，我是一名专业程序员，虽然我支持开源思想，但我确实喜欢在月底获得报酬（猜猜这笔钱来自哪里:-)）。 （顺便说一句，我不是 ITTVIS 员工。）
所以，简而言之。 如果您认为 IDL 太昂贵，那没关系（但不要使用专有参数）。 还有其他选择，您可以自由选择！ 但在你（要求你的同事）改变之前，问问自己这会对你的生产力产生什么后果！ 您可能会节省几千美元的许可费，但如果完成一项工作需要花费 10 倍的时间.........
亲切的问候
Correct me if I'm wrong, but are you asking if you should tell your colleagues to "stop wasting their time" on a language, you don't know, but don't like because it's proprietary????
Well, I think it's a bit short sighted. First, you should ask your colleagues "why they are using IDL". I've been using IDL on and off for about fifteen years, and I think they'll tell you "because I can do what I have to do quickly". I've been programming in IDL/C++/LabVIEW/Python/Pascal for 20 years and I think you should use the language/environment that's best suited for the job. I wouldn't use IDL for a flashy user-interface application, but for analyzing and visualization of Gigabytes of data it's hard to beat. (I certainly wouldn't use Python or Ruby for that!)
And about IDL being proprietary software. Well that's true (though you don't need expensive licenses to run an IDL application. You can use the Virtual Machine to run applications, you need an expensive (true) license to develop applications). But, what's wrong with being proprietary? My car is a proprietary product (and I guess yours is too :-) ), so are my tv set, telephone, etc. etc.
So IDL is proprietary which means you can't change the language (other than asking ITTVIS for changes), but you don't even know the language! So what's the problem? (BTW the open source version GDL was mentioned and there are other (open source) alternatives). How much have you contributed to C++/Python/Ruby etc?
I hope the proprietary argument isn't (mis-)used because you don't like the (high) license fees? It's true there are free (read: no money being transfered) C++/Python/Java compilers, but ITTVIS is a commercial company, who wants to make money. Well I'm a professional programmer, and though I support the open source thought, I do like being paid at the end of the month (guess where that money has to come from :-) ). (BTW I'm no ITTVIS employee.)
So, in short. If you think IDL is too expensive, that's ok (but don't use the proprietary argument). There are alternatives, you're free to choose! But before you (ask your colleagues to) switch, ask yourself what the consequences are for your productivity! You might save a couple of thousand dollars on license fees, but if it takes 10 times as long to complete a job.........
Kind regards
我在医学成像研究实验室使用 IDL 已有 8 年了。 我还使用 MATLAB、LabVIEW 和 Visual C++。
IDL 成本：编程终端确实需要 IDL 许可证。 不过，如果您能忍受闪屏，您可以在任何终端上的免费“虚拟机”下运行您的 IDL 应用程序。 此外，许多其他语言/开发环境的成本与 IDL 一样高（如果您合法使用它们）。 在这所大学，Visual Studio 的每个许可证比 IDL 更贵。
IDL/MATLAB 与 Visual C++/etc：您可以用 IDL 在一天内编写一个程序或 GUI 应用程序，而用 C++/Visual C++ 编写一个程序或 GUI 应用程序需要一周的时间——这是我们专家 Visual C++ 程序员的一句话。 IDL只需要两周的时间就能学会，而且有一本很棒的书可以学习。 当然，如果添加 Visual GUI，C++ 程序将运行得更快，并且您将有更多的控件可以使用。 但是，如果您想要构建具有用户界面的算法或应用程序原型来分析数据，IDL（或 MATLAB）将为您节省大量时间。
IDL 与 MATLAB：IDL 比 MATLAB 更冗长，并且没有用户群或工具箱数量，但它拥有的主要用户论坛非常出色，有许多反应灵敏的专家。 过去，IDL GUI 编程接口更为优越，尽管 MATLAB 可能已经迎头赶上——我仍然更喜欢对 IDL“小部件”进行编程。 另外，IDL 的内置功能有时看起来更“内置”一点，这可能弥补其较小的用户群。 一个很好的例子是 convolve 命令：IDL 中的“convol”与 MATLAB 中的“conv”。 该命令在 IDL 中是一个较长的字，但还包含用于标准化结果以及处理无效数据和边缘效应的标志。 MATLAB 语法更加优雅和简洁，并且能够直接从函数返回多个值是一件好事。
相信我：如果您想花更多时间处理数据而不是代码，那么学习 IDL 和 MATLAB 等“科学数据”语言是值得的。 我不会说一种语言比另一种更好，但这样的语言在实验室中是不可或缺的，尤其是成像实验室。
I've been using IDL for 8 years in a medical imaging research laboratory. I also use MATLAB, LabVIEW and Visual C++.
IDL Cost: It's true that programming terminals need IDL licenses. However, you can run your IDL applications under their free "Virtual Machine" on any terminal if you can put up with a splash screen. Also, a lot of other languages/development environments cost as much as IDL (if you use them legally). Visual Studio is more expensive at this university per license than IDL.
IDL/MATLAB vs Visual C++/etc: You can write a program or GUI application in a day in IDL that would take a week to write in C++/Visual C++ -- that's a quote from our expert Visual C++ programmer. IDL only takes two weeks to learn, and there is an excellent book to learn from. Of course the C++ program will run faster and you will have more controls to play with if you add a Visual GUI. However, if you want to prototype an algorithm or an application with a user interface to analyze data, IDL (or MATLAB) will save you a lot of time.
IDL vs MATLAB: IDL is a little more verbose than MATLAB, and does not have the user base or the number of toolboxes, but the main user forum it does have is excellent, with a number of responsive experts. It used to be that the IDL GUI programming interface was superior, although MATLAB may have caught up -- I'm still much more comfortable programming IDL "widgets." Also, IDL's built-in functions sometimes seem to have a little more "built-in," which may make up for its smaller user base. A good example is the convolve command: "convol" in IDL vs "conv" in MATLAB. The command is a longer word in IDL, but there are also included flags for normalizing the result, as well as for dealing with invalid data and edge effects. MATLAB syntax is more elegant and concise, and it's nice to be able to directly return more than one value from a function.
Trust me: learning "scientific data" languages like IDL and MATLAB is worthwhile if you want to spend more time working with data than working with code. I'm not going to say one is better than the other, but languages like this can be indispensible in the lab, especially an imaging lab.
当我开始学习 IDL 时，我也有类似的想法 - 我仍然不喜欢它，但我现在在 SolarSoft（一个用于太阳物理的软件分发系统......和大多数软件都是 IDL 格式）。
IDL 擅长处理大型数据立方体和数字图像，如果您了解 Fortran，那么学习它相当容易。 （大多数老科学家都是这样做的，而我必须作为一名非 CompE 的工程专业学生进入大学）
问题是——IDL 中有很多代码。 将其全部转换为其他语言并进行必要的测试的成本简直是天文数字。 我老板的估计是这需要十几个人年的时间，而且我们需要了解 IDL（无论什么新语言）和实际科学的人，以便他们理解为什么代码的逻辑在那里（而不仅仅是一些奇怪的东西）的语言）。 ......然后你必须考虑重新培训所有科学家。 以我们目前的资金水平，这是不可能发生的。
话虽如此，我希望他们的 Regex 引擎使用 PCRE 或至少支持零宽度断言。 他们终于做到了，这样我就可以将字符串传递到 XML 解析器中，而不必先将其写入文件，但我仍在等待真正的 SOAP 支持，而不是我的黑客尝试。 我必须解决一些限制，例如没有零元素数组（我使用指向数组的指针，因此我可以保留空指针）、命名空间（我用对象来伪造它）和缺乏 XPath 支持（当我遇到一些奇怪的问题时） 四倍...我必须返回大型记录集作为税收 delim，而不是 XML，但希望测试它们的 VOTable 实现是否存在相同的问题）
在遍历 DOM 树之后，树中元素每增加一倍，清理时间就会增加 在这一点上，我并不是建议人们停止使用 IDL，但我正在发起活动，让人们停止将他们的数据目录存储和分发为 IDL 保存文件，因为使用 IDL 读取数据目录受到限制。除 IDL 之外的任何内容。 我知道有一些努力为科学家提供数据准备服务，希望他们能够摆脱要求科学家拥有 IDL 才能使用数据的情况。
I had similar thoughts when I started learning IDL -- and I'm still not a fan of it, but I now have some code out there in the wild that I support in SolarSoft (a software distribution system for solar physics ... and most of the software's in IDL).
IDL's good at processing large data cubes and digital images, and it's fairly easy to learn if you know Fortran. (which most of the older scientists do, and I had to take in college as an engineering student who wasn't CompE)
The thing is -- there's a LOT of code out there in IDL. The cost of converting it all to some other language, and giving it the necessary testing is just astronomical. My boss's estimate is that it'd take over a dozen man years, and we'd need people who understood IDL, whatever new language, and the actual science so they understood why the logic of the code is there (and not just some oddity of the language). ... and then you have to consider retraining all of the scientists. At our current funding level, that's just not going to happen.
All of that being said, I'd love for their Regex engine to use PCRE or at least supported zero-width assertions. They've finally made it so I can pass a string into the XML parser without having to write it to a file first, but I'm still waiting for real SOAP support, and not my hack attempts at it. I have to work around restrictions like no zero-element arrays (I use pointers to arrays, so I can leave a null pointer), namespaces (I fake it with objects) and lack of XPath support (I've seen some odd problems when after walking DOM tree, the cleanup time quadruples for every doubling of elements in the tree ... I've had to return large recordsets as tax delim, rather than XML, but hope to test if their VOTable implementation has the same issues)
At this point, I'm not suggesting that people stop using IDL -- but I am campaigning to get people to stop storing and distributing their data catalogs as IDL save files, due to the restriction on reading them with anything other than IDL. And I know of a few efforts to make services for scientists to run their data prep, so that hopefully they can get away from requiring scientists to have IDL to be able to use the data.
我是地球科学领域的博士后，广泛使用 IDL 来处理大型数据集。 我不得不说它非常容易使用（对于我和其他许多人来说），如果它节省了我数百个小时的调试 C 内存错误的时间，那么它很容易值得许可成本（我也有 CS 学位） ，所以我知道“真正的”编程语言）。
听起来您的问题不在于 IDL，而在于文件格式。 不要说服同事使用不同的语言，而要说服他们使用不同的文件格式。 我几乎从未使用过 .sav 文件，我总是使用常见的数据格式，例如 geotiff、HDF、netCDF，甚至是简单的二进制或 ASCII（视情况而定）。 这样，我所有的同事都可以使用他们选择的语言来阅读它。
我来这里寻找有关将 IDL 与 SOAP 结合使用的信息，遗憾的是，上面的评论赢得了 google 竞赛。 现在如果我能找到一些关于它的实际信息就好了:)
I'm a post-doc in earth sciences, and have used IDL extensively for processing large datasets. I have to say it is very EASY to work with (for me and many others anyway), and if it saves me hundreds of hours of debugging c memory errors, than it is easily worth the license cost (I have a CS degree as well, so I know "real" programming languages).
It sounds like your problem is not so much with IDL as it is with the file format. Rather than convincing your colleagues to use a different language, convince them to use a different file format. I have almost never used .sav files, I always use common formats for data such as geotiff, HDF, netCDF, or even simple binary or ASCII as appropriate. That way, all of my colleagues can use their language of choice to read it in.
I got here looking for info on using IDL with SOAP, and, sadly, the comment above won the google contest. Now if only I could find some actual info on it :)
也许这可能对某人有帮助：GDL 确实处理（读取和写入）IDL .sav 文件。 SAVE 和 RESTORE 例程是在免费的CMSV 库（用IDL 编写）的帮助下实现的。
此外，GDL 可以构建为 Python 模块 - 然后也可以使用 Python 中的 .sav 文件。 GDL 中的 Python 支持仍然使用 numarray 包，因此它可能不是很方便。
Perhaps this might help someone: GDL does handle (read & write) the IDL .sav files. The SAVE and RESTORE routines are implemented with the help of the free CMSV library (written in IDL).
Furthermore, GDL can be built as a Python module- one can then use the .sav files from Python as well. The Python support in GDL still uses the numarray package, so it might not be very convenient, though.