为什么我拒绝将Multiwfn做成全图形界面

为什么我拒绝将Multiwfn做成全图形界面?
Why do I refuse to make Multiwfn a full graphical interface program?

文/Sobereva @北京科音 2014-Jun-6



时常有一些国内的用户提议将笔者的波函数分析程序Multiwfn (http://sobereva.com/multiwfn)做成全图形界面(GUI)的程序,本人是拒绝的,原因在之前已经反复提到过。由于近来又有人提到此事,故专门写个文谈谈这点。我不指望初级用户能接受本文的观点,但我相信随着使用者水平的逐渐提高,会越来越赞同本文。

Multiwfn目前的界面是文本和图形混合式界面,不需要图形界面的地方是纯文本显示,只有需要图形化观察结果的时候才会提供图形界面。这种设计有着很大的好处:

(1)可以十分方便地写脚本进行批处理,Multiwfn里的每一步操作只需要通过重定向的方式输入即可,见手册5.2、5.3节的一些简要说明,结果也可以直接重定向到文本文件里便于用户进一步处理,还可以将输出信息直接从屏幕中复制出来(见手册5.4节)。只需要稍微懂一些DOS批处理文件的语法或者Linux的shell脚本编写,就可以很方便地令Multiwfn大批量地分析,这个特征对于产生动画就显得特别便利,例如《通过键级曲线和ELF/LOL/RDG等值面动画研究化学反应过程》(http://sobereva.com/200)。对于经常需要分析的任务,也可以写成特定脚本,到时候一行命令就能完成。钟成编写的Multiwfn辅助工具VMwfn(http://emuch.net/bbs/viewthread.php?tid=7308796&fpage=1)也充分体现了这个设计的优势。文本+图形界面的混合设计使得Multiwfn十分灵活,而做成全图形界面的话灵活程度就差远了,只有屏幕上的控件可以操作,多一点的事都没法做到(甚至有点被蒙在鼓里的感觉)。

(2)Multiwfn有的功能需要图形界面,有很多则本身就不需要图形界面,比如计算键级。目前Multiwfn的设计,在启动程序时不需要终端有图形的支持,比如可以以SSH方式登录服务器然后运行Multiwfn。如果非要搞得全图形界面,那么纯文字终端的用户根本连启动Multiwfn都不可能。有人误以为Multiwfn的分析都是不耗时的,因此不需要弄到服务器上跑,实际上这是错误的。的确,Multiwfn的效率很高,但不代表所有支持的分析方法都不怎么耗时。例如,aRDG分析,见《使用Multiwfn研究分子动力学中的弱相互作用》(http://sobereva.com/186),由于方法本身的高计算量,对较大体系、较长轨迹做这样一次分析可能会耗时很长,几个小时甚至一天都有可能,放到多核服务器上算明显是有必要的。

(3)便于程序开发。Multiwfn只给真正需要的地方安排图形界面,因此在大部分的代码开发中,不需要写图形界面的代码,这比起开发图形界面程序省时多了去了。Multiwfn程序里有好几百个选项,全都搞成图形界面,至少笔者是吃不消的,与其弄这样虚无浮华的东西还不如把精力用在开发、改进、完善真正最重要的功能上。另外,全图形界面的话代码会显得很臃肿,代码量、程序体积、编译时间可能会翻番。这么一来,程序表面虽然看起来仿佛好看了,却丢失了内在真正的气质和优美。另外,弄成全图形程序后调试也会更为麻烦,浪费开发时间。

(4)便于跨平台。为了照顾广大用户,Multiwfn是Windows+Linux+MacOSX三平台的程序。图形界面的程序跨平台,这是个众所周知麻烦的事。Multiwfn目前的图形界面使用DISLIN,在不同平台上显示效果有差异,比如有的平台控件大一点,有的小一点,有的操作还有点差异,实际显示出来的控件排列还往往有差异,弄不好的话严重影响使用。如果全弄成图形界面,那么多菜单得在三个平台上都测试、修改,笔者没这个精力。

(5)便于用户修改。Multiwfn是鼓励用户修改程序来实现自己需要的更多的功能的。Multiwfn目前的程序结构很清楚,易读也容易改,想加个选项立刻就加上去了。要是全图形界面,若用户想加个自己的功能,比如仅仅是将内部数据输出到文本文件里,得花更多时间去了解程序结构,还得去了解DISLIN图形库的基本使用,这明显给用户增添负担。

Multiwfn目前的界面操作是最快捷的,大多数任务敲几下键盘就出来。特别是对于有小键盘的用户,稍微使用熟练后,比如作一个ELF平面图,整个操作过程只需要两三秒钟。而弄成图形界面后,只不过是把按键盘改成了点鼠标,这有何意义?根本毫无意义!反倒是,每次移动鼠标瞄准后再去点击,比起直接敲键盘速度还慢,降低了使用效率。

有人觉得,全图形界面才显得程序专业,否则就不专业,这种观点我完全理解不能。全图形界面的量化程序寥寥,比如Hyperchem就是典型,虽然是全图形界面却反倒很难用,早就没了市场,甚至有人认为已经沦为了本科教学的低端工具。而主流的量化程序,几乎无一不是纯文本的。虽然Gaussian在Windows下有图形界面,那其实也完全是可有可无的(DOS命令行下照样可以执行),而且大多数人还是在Linux下面用服务器跑。实际上,设计出对于一个程序的功能来说最适合、最恰到好处的界面,那才叫真正的专业。反倒是,一个程序本来不适合全图形界面化,而非得强迫弄成全图形界面,把程序搞得更难用,那才真是显得很外行,显得很没品(就像戴一大砣金链子似的)。

但是也不是说目前的Multiwfn的界面就已经完美了,比如显示等值面图的速度对于格点精度较高的时候会略慢,而且没法通过拖动鼠标自由地改变视角。像这样对使用效率有真正影响的地方,才会在未来的版本中尝试改进。笔者不会为了没有任何意义的改进而花费精力的。

Multiwfn全GUI化的好处,说来也就只有一个,就是能讨好外行人(刚接触量化的人也属于这类),第一次启动就看到了自己熟悉的图形界面,使用信心会增加。而启动后,若看到黑乎乎的文本界面和文字提示,顿时就使心灵大受打击,伤害了使用信心,甚至就败退了,从此不用了。这一点,绝对不是程序自身的问题,而100%是使用者的问题!

说到这一点的时候,我就不得不说说现在量化工作者,特别是量化初心者们的研究态度了。60年前,Boys搞量化计算要面对庞大却又异常缓慢的计算机,成天直接跟1和0打交道,而且能用的机时还非常有限,也没有现成的程序,甚至没多少前人的工作可供参考,却实现了从头算(可参考JPC,100,6007对Boys的介绍),那是什么样的研究态度?(甚至Parr那时候还辛苦地摇着手摇计算器算N2呢!)而如今的量化工作者,我不得不说水平正在普遍严重下滑,而比起水平下滑更严重的是钻研精神的急剧丧失,者特别是对于那些刚开始搞量化的人而言。这些人当中的很多人,一点理论也不愿意学,就知道拿现成的程序傻算,碰到问题也不过脑子就知道到处傻问。Multiwfn程序启动后,屏幕上的提示清楚得不能再清楚,手册写得已经详细得不能更详细了(耗费巨大精力写了376页,在手册第一页就已经提示了在手册第四章有教程,稍微看几眼就能马上会用),何况还有近30万字的中文帖子,甚至还专门写了帮助入门的帖子《Multiwfn入门tips》(http://sobereva.com/167),我真是只能帮用户到这了。如果用户仅仅因为没接触过命令行界面,就不愿去稍微学习、了解哪怕一点点更多的东西,那么,这样的用户,根本没有最基本的作为量化工作者应有的研究态度,丧失了这样的用户我不会觉得有任何可惜的。这样的用户,就算用上了全GUI的Multiwfn,笔者窃以为也不大可能会做出很重要的研究成果。而那些勤动脑子钻研问题、乐意仔细读手册的Multiwfn的用户,我总是尽最大可能去解答他们的问题(只要有时间的话),他们提出的在改进程序上的建议我也很乐意听取。

值得一提的是,虽然Multiwfn的外国用户很多,也经常发来邮件问各种相关问题,但是他们当中从没有人建议要将Multiwfn全GUI化的,而且经常在Multiwfn的易用性上予以积极的评价(例如有个人对Multiwfn的拓扑分析功能就评价道这代表了AIM程序未来的发展方向)。我也感到外国的Multiwfn的用户的钻研态度普遍很好,很多Multiwfn里面很深入,可能需要仔细看手册才知道用法的功能他们都用得很好。比如,Chemical Physics 434 (2014) 11-14这篇文章是一个伊朗人写的,他目前还没什么名气,通过刘述斌提出的位阻分析方法讨论水簇的稳定性。这里面涉及到Multiwfn的对实空间函数全空间积分的功能(主功能100里的4),还涉及到steric energy density(自定义函数40),而这两样在Multiwfn的众多功能里算是相对深入的功能和特征。这个伊朗人从没有咨询过笔者使用问题,而只是光靠研读手册就搞懂了用法(当然,手册里已经提供了足够充分的信息),并得到了挺好的研究结果,我觉得这样的研究者真是Multiwfn用户里的楷模。

总之,将Multiwfn做成全图形化的害处远大于好处,我更不会为了盲目地讨得初级用户的欢心而将之改成全GUI界面。笔者会一直坚持以笔者认为最好、最合理、最正确的方式将Multiwfn做得尽可能完美。