选择一个科学代码的前端/解释器

6
我过去几年开发的仿真工具使用C++编写,目前具有tcl解释器前端。它被编写为可以在交互式shell中运行,也可以通过传递输入文件来运行。无论哪种方式,输入文件都是用tcl编写的(我添加了许多其他特定于仿真的命令)。这允许使用相当强大的输入文件(例如-当运行蒙特卡罗模拟时,随机分布可以直接编程为tcl过程)。
不幸的是,我发现与更现代的解释语言相比,tcl解释器变得有些受限,并且其语法似乎有点神秘。由于计算引擎是作为具有c兼容API的库编写的,因此编写替代前端应该很简单,我正在考虑转移到新的解释器,但我花了一些时间选择(主要是因为我没有太多使用经验许多解释语言)。我已经开始探索的选项如下:
继续使用tcl: 优点: - 无需更改现有代码。 - 现有输入文件保持不变。(尽管我可能会将tcl前端保留为选项) - 成熟的语言,有很多社区支持。 缺点: - 对语言语法感到受限。 - 用户抱怨学习tcl的困难。
Python: 优点: - 现代解释器,已知非常高效。 - 大型、活跃的社区。 - 知名的科学和数学模块,如scipy。 - 在学术科学/工程界常用(我的代码的典型用户)。 缺点: - 我从未使用过,因此需要时间学习语言(这也是一个优点,因为我一直想学习python)。 - 严格格式化输入文件(缩进等)。
Matlab: 优点: - 非常强大且广泛使用的数学工具 - 强大的内置可视化/绘图。 - 可通过社区提交的代码以及商业工具箱进行扩展。 - 许多在科学/工程学术界熟悉和舒适使用matlab。 缺点: - 无法分发为可执行文件-需要添加/工具箱。 - 需要matlab编译器(价格昂贵)。 - 需要matlab,这也是昂贵的。
这些优缺点是我能想到的,尽管我对解释语言的经验非常有限。如果您对我提出的解释器有任何想法,这里列出的优缺点是否合理,以及我没有考虑的任何其他解释器(例如-php是否适合此类任务?lua?),我很乐意听取您的想法。在您的代码中嵌入解释器的第一手经验绝对是一个加分项!

不是的,它是一种学术性的多孔介质流模拟器,主要由我所在的研究小组的研究生和博士后使用。 - MarkD
我从未使用过它,但我听说scipy被推荐用于数值计算,所以我认为它是高效的。它只是在C后端上使用Python API,但这也是为什么开发了Python互操作性的原因。 - Matthieu M.
@MarkD,你能否告诉我你最终做了什么?我有一个类似的困境:http://stackoverflow.com/questions/6495965/supporting-both-tcl-and-python - Juan
1
@Juan:最终我选择了Python。具体来说,我正在使用boost::python将C++代码与Python解释器集成。 - MarkD
为Tcl添加一些专业性,同时为Python提出一些反对意见:在多线程环境下(例如,多个解释器并行运行脚本),Tcl比Python更好地处理嵌入,这是由于Python的设计非常有限所致。 - schlenk
显示剩余8条评论
3个回答

5
我曾经是 Tcl/Tk 的忠实支持者,从预发布版本开始一直到我用它完成了一个较大的项目,发现它是多么难以维护。不幸的是,由于 Tcl 中原型非常容易实现,你最终会得到一堆“一次性”脚本,它们却有着自己的生命力。
在过去几个月里,我采用了 Python,发现它完全符合 Tcl 的承诺,而且更加强大。正如许多 Python 老手所说,源代码缩进在最初的一小时可能会让人感到麻烦,但之后它似乎不再是一个阻碍,反而有助于编程。顺便提一下,Tcl 的作者 John Ousterhout 曾因为强制 Tcl 程序员使用One True Brace Style而备受赞扬和批评(我是 1TBS,所以这对我来说很好)。
唯一在Python中处理不好的Tcl结构是任意的eval "${prefix}${command} arg"结构,这在Tcl中本来就不应该使用,但是却被使用了,以及uplevel类型的语句(虽然这是一个好主意,但是会使代码变得复杂)。事实上,Python对于动态eval感觉有点敌意,但我认为这是件好事。不幸的是,我还没有遇到过像Tcl/Tk一样将GUI作为重点的语言;Tkinter在Python中完成了工作,但它并不完美。

我无法对Matlab发表任何评论。

随着几个月的Python编程经验,我几乎肯定会将正在进行开发的任何Tcl程序移植到Python中,以保持清醒的目的。


我已经学习了几个月的Python,我几乎可以肯定地将正在开发中的任何Tcl程序移植到Python...这是一个提议吗? ;)说真的,看起来Python有很多优点,而且我们有一位非常熟悉它的新博士后加入,这使得Python变得非常有吸引力。感谢您分享您的观点-这绝对是有帮助的! - MarkD
1
相反的是,我曾经使用Tcl处理过大型商业项目,并发现它具有极强的可维护性和可扩展性。在我的经验中,这两个因素更多取决于程序员或团队,而不是语言本身。 - Bryan Oakley
1
我已经在Tcl社区呆了15年了,不记得听到有人批评John Ousterhout“强制Tcl程序员使用One True Brace Style编写语言”的言论,但也许是我没有关注。当然,有些人不喜欢它,但如果使用其他风格,它就不会是Tcl了。这是一种特性,而不是bug。 - Bryan Oakley

3
你考虑过使用Octave吗?据我所知,它几乎可以完全替代大部分的Matlab。这可能使你能够支持那些拥有Matlab的人,并为那些没有Matlab的人提供免费的替代品。由于你程序的“核心”似乎是用另一种语言编写的,因此性能考虑似乎不像提供具有绘图和可视化功能、跨平台、拥有庞大用户群体并且几乎所有学术界和/或涉及建模流体流动的人都已经熟悉的语言环境重要。Matlab/Octave潜在地可以拥有所有这些功能。

我以前在Octave上有过非常糟糕的经历(多年前),以至于我甚至都没有考虑过它。这么说来,把它作为一个选择确实是有道理的。我想知道扩展Octave的API和Matlab的API有多相似? - MarkD
嗨,马克,我多年没用过它了,而且当我最初使用它时并不印象深刻。上周我和一位电气工程教授一起工作:他有一个完整的电磁层析成像代码,纯粹是用Octave编写的,运行非常快,这让我真正开始考虑再次关注它。我不知道Octave在像Matlab那样与Mex一起合并其他语言方面的地位如何,但一些搜索显示在这个领域有一些希望。 - reso
1
很高兴听到它在过去几年里取得了长足的进步。我一定要再试一次。 - MarkD

0

好的,除非有其他建议,我最终选择的答案是使用Python。

我认真考虑了matlab/octave,但是当阅读octave API和matlab API时,它们之间的差异足以让我需要为每个构建单独的接口(或者在宏方面变得非常有创意)。使用Python,我最终得到了一个单一、更易于维护的代码库,前端由几乎我们所知道的所有人使用。感谢大家的建议/反馈!


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接