有人使用称为交互式数据语言(IDL)的语言吗?它很受科学家欢迎。我认为它是一种糟糕的语言,因为它是专有的(运行它的每个终端都必须购买昂贵的许可证)并且它的支持很少(尝试搜索 IDL,这种语言,现在在堆栈上)。我试图说服我的同事停止使用它并学习 C/C++/Python/Fortran/Java/Ruby。有没有人足够了解甚至关心 IDL 并对此发表意见?你怎么看呢?我应该告诉我的同事现在不要再在这上面浪费时间了吗?我怎样才能说服他们?
编辑:人们得到的印象是我不知道或不使用 IDL。另外,我说 IDL 的支持很少,这在某种意义上是正确的,所以我必须澄清一下,科学图书馆确实很大。我一直使用 IDL,但这正是问题所在:我只使用 IDL,因为同事使用它。IDL 使用了一种文件格式,即 .sav,它只能在 IDL 中打开。所以我必须使用 IDL 来处理这些数据并将数据传回给同事,但我知道我使用另一种语言会更有效率。这就像有人在电子邮件附件中向您发送了一个 microsoft word 文件,如果您不明白这是多么错误,那么您可能写了太多单词而没有足够的代码,然后您购买了 microsoft word。
编辑:作为 IDL Python 的替代品很受欢迎。这是来自AstroBetter的 IDL 的优点(和缺点)列表:
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 方便)
- 数组索引约定“向后”</li>
- 小阵列性能较慢
- 没有标准的 GUI 运行/调试工具
- 支持许多小部件系统(担心选择哪个)
- 当前缺少相当于 IDL 中的 SAVE/RESTORE 的功能
- matplotlib 还没有所有 IDL 2-D 绘图功能的等效项(例如,曲面图)
- 使用用作标志的关键字参数不太方便
- 绘图:
- 比较不成熟,还有很大的发展空间
- 缺少一些绘图类型(例如,表面)
- 3-d 能力需要 VTK(尽管 matplotlib 有一些基本的 3-d 能力)