为科学代码选择前端/解释器 我在过去几年中开发的仿真工具，是用C++编写的，目前有一个TCL解释的前端。它是这样编写的，既可以在交互式shell中运行，也可以通过传递输入文件来运行。无论哪种方式，输入文件都是用tcl编写的（我添加了许多其他特定于模拟的命令）。这允许非常强大的输入文件（例如，当运行monte-carlo sims时，可以在输入文件中直接将随机分布编程为tcl过程）

不幸的是，我发现与现代解释语言相比，tcl解释器变得有些有限，其语法似乎有点神秘。由于计算引擎是作为一个带有c兼容API的库来编写的，因此编写替代前端应该很简单，我正在考虑换一个新的解释器，不过我有一点时间来选择（主要是因为我对许多解释语言没有丰富的经验）。我已开始探讨的方案如下：

继续与tcl合作：
优点：
-无需更改现有代码。
-现有的输入文件保持不变。（尽管我可能会选择tcl前端）
-拥有大量社区支持的成熟语言。
缺点：
-感觉受到语言语法的限制。
-用户抱怨学习tcl有困难

Python:
优点：
-现代口译员，效率极高。
-大型活跃社区。
-著名的科学和数学模块，如scipy。
-学术科学/工程界常用（我的代码的典型用户）
缺点：
-我从未使用过它，因此需要花时间来学习这门语言（这也是一门专业课程，因为我想学习python已经有一段时间了）
-输入文件的严格格式（缩进等）

Matlab:
优点：
-非常强大且广泛使用的数学工具
-强大的内置可视化/绘图功能。
-可通过社区提交的代码以及商业工具箱进行扩展。
-许多科学/工程学术界人士熟悉并熟悉matlab。
缺点：
-无法作为可执行文件分发-需要是附加组件/工具箱。
-需要（？）matlab编译器（这是很昂贵的）。
-需要Matlab，这也是昂贵的

---

这些优点和缺点正是我所能想到的，尽管我对一般的解释语言几乎没有经验。如果列出的这些优点/缺点是合法的，我很想听听大家对我在这里提出的口译员和我没有想到的任何其他口译员的看法（例如，php是否适合这样做？lua？）。有在代码中嵌入解释器的第一手经验者优先

从发布前开始，我一直是Tcl/Tk的坚定支持者，直到我用它做了一个更大的项目，发现它是多么的不可维护。不幸的是，由于原型在Tcl中非常简单，您最终会看到“一次性”脚本呈现出它们自己的生命

在过去的几个月里，我已经采用了Python，我发现它是Tcl承诺的全部，而且还有更多。正如许多Python老手可以告诉您的那样，源代码缩进在第一个小时内最多是一个麻烦，然后它似乎不是一个障碍，但肯定是有帮助的。顺便说一句，Tcl的作者约翰·欧斯特豪特（John Ousterhout）因为写了一种强迫Tcl程序员使用的语言（我当时只有1TB，所以我觉得没问题）而受到了褒奖和批评

Python无法很好地处理的唯一Tcl构造是任意的

eval“${prefix}${command}arg”

构造，这些构造无论如何都不应该在Tcl中使用，但它们是和

uplevel

类型语句（这是一个不错的主意，但适用于一些毛茸茸的代码）。实际上，Python感觉有点与dynamic

eval

对立，但我认为这是一件好事。不幸的是，我还没有开发出一种既包含GUI又包含Tcl/Tk的语言；Tkinter在Python中完成了这项工作，但它带来了伤害

我根本不能和Matlab说话

---

有了几个月的Python经验，我几乎肯定会将任何正在开发中的Tcl程序移植到Python中，以保持理智。

您考虑过使用Octave吗？据我所知，它几乎是matlab的替代品。这可能允许您为拥有matlab的用户提供支持，并为没有的用户提供一个免费的替代方案。由于您的程序的“肉”似乎是用另一种语言编写的，因此性能方面的考虑似乎没有提供一个具有以下功能的环境那么重要：绘图和可视化功能、跨平台、拥有庞大的用户群、，用一种几乎所有学术界和/或参与流体流动建模的人都知道的语言。Matlab/Octave可能具有所有这些功能。

除非有其他建议，否则我得出的最终答案是使用Python

---

我认真考虑过matlab/octave，但在阅读octave API和matlab API时，它们差异很大，因此我需要为它们分别构建接口（或者对宏非常有创意）。使用python，我最终得到了一个单一的、更易于维护的前端代码库，我们所知道的每个人都在使用它。谢谢大家的提示/反馈

CoreMaster2？听起来就像是我公司另一个部门开发的代码。不，这是一个通过多孔介质的学术流程模拟器，主要由我所在研究小组的研究生和博士后使用。我不会称Python为“高效的”。Python代码效率相当低，数字处理通常由通过Python API访问的C代码完成：）但我仍然使用它，因为它太简单了