我一直不太赞同研究必须先完成大量专业知识的积累。事实上，研究、创新和探索应该贯穿整个学习过程，甚至整个人的成长历程。

 

所以指望上学上到研究生再正式开始做"科研"是可笑的。因为已经晚了。抱有这种想法的孩子多半已被二手知识洗过脑了，不能再做真正意义上的研究了，于是乎褪变成了"为研究而研究"。国内这才出现了那些质量差得令人哭笑不得的所谓的"学士论文"和"硕士论文"，或许如今许多研究生能替导师打打短工就已经很不错了。。。这正应了小纳什的那句话："过度地接受二手知识只会损害自己的原创力."

前一阵子和刚上大学的表妹说到了毕业论文的选题。我的意见是，论文的题目很可能是过去学习过程中某一个特别有趣但还没有充分发掘的"延伸点"或者说"灵感源"。在平时没有做过任何实际的研究和探索之前，就挖空心思去想具体的研究方向和论文的题目，是武断而荒谬的。做出象样的成果的可能性在我看来几乎没有，除非导师自己乐意代劳。

我在和妹妹的沟通过程中一直试图表达这样一个意思，那就是研究应当成为一种习惯——一种看书习惯，一种解题习惯，一种听课习惯，和一种思考习惯。我们可能在学习过程中的任何一个点上得到灵感（如果我们以学科主人的姿态进行学习的话），进而作出自己的创造和贡献。很多时候，随着我们学习的深入，我们会惊讶地发现自己先前的一些延伸思考和创新成果，可能会跟前辈大家们的结论不谋而合！事实上，这种撞车是幸运的，而且随着时间的推移，撞车会越来越少，那么原创也就会越来越多了。可惜的是，许多人的心是浮动的，而研究和探索需要绝对宁静的心 :)

有趣的是，就当世界最顶尖的物理学家们仍对惯性定律和万有引力定律中的质量 (m) 的物理学本质百思不得其解时，中国的孩子们早已把"质量是物体所含物质的多少"这一句不是定义的定义，作为教条，背得滚瓜烂熟了，岂不悲哉？而根据我自己的经历，在中国的学校里如果对这样的细节问题追问老师的话，老师就会把"爱钻牛角尖"的大帽子扣在你的脑门上，而事实上这些问题多数在物理大家那里都是很重要的。

疑问，沉思，发散，和关联等等，都是研究的种子，而当研究已然成为一种习惯时，它便不再做作，不再神秘，不再喜大好功和脱离实际。

忍不住在 PerlChina 邮件列表中盘点了一下 Perl 里的 Web 应用框架（巧的是 PerlBuzz 最近也有一篇相关的讨论帖），于是乎，决定在我自己的 blog 上也贴一下 :)

原生 CGI/FastCGI 的 web app 对于较小的应用非常合适，但稍复杂一些就有些痛苦，但运行效率是最高的 ;) 如果是自己用 Perl 开发高性能的站，多推荐之。

Catalyst, CGI::Application, 和 Jifty 是最流行的三大框架。CGI::Application 是 CGI 之上很薄的一层，非常 popular，呵呵，这里的许多哥们使用之。Catalyst 也见过许多网站应用，包括比较大的网站。从技术和想法上讲，Jifty 的创新点非常多，有许多非常酷的设计，甚至有些独创之处。唐凤，Jesse Vincent, clkao 都是 Jifty 的开发者，我也为 Jifty 贡献过一些补丁和文档。

从架构上讲，这些框架与 Ruby 的 RoR 和 Python 的 Django 没有本质区别，甚至可以说是大同小异，只是许多细节和设计理念若有区别。比如 Catalyst 是典型的 N 种方式完成同一件事情，使用起来感觉更像是自组装的自行车；而 Jifty 则是 full-stack 那种，哲学是 One Best Way. 这些框架都存在一个问题，即多是"解释型"的，多是多层堆砌起来的。Web server 上都得跑一个很大的 runtime，都有 N 多 CPAN 依赖项，布署的成本都非常高（不是一般的免费租用空间能胜任的）。于是我发现，虽然我很喜欢 Jifty，但我却不愿在自己的 web 服务器上布署之，即使我有 root 权限。

这让我陷入了很深的思考。。。我和 Jifty 的老大 Jesse 也交流过。。。我们的 web 应用框架是否应该学习一下 C/C++ 这些编程语言的编译器？是否应该做成"编译型"的框架，而非解释型的？这样，即使我们开发时使用很多库，很多 Perl，很多工具，但经过框架的处理，最终我们可以得到一个高性能的依赖项极少的很薄的而且高度自治的网络应用？而且这种应用还可以在多机集群的环境中很容易地 scale？

这个最终得到的"二进制"的网站是什么样子，就依赖我们的想象力和需求了。它可以是一个非常轻便的 CGI/FastCGI 的 perl 脚本，或者根本不含 Perl，只有布署成本极易的 JavaScript 代码或者 PHP 代码。

在过去的一年内我做了许多有趣的尝试。XUL::App 就是这种思考的实践，我们在开发过程中可以使用许多 Perl，包括 Template::Declare 和 Locale::Maketext::Lexicon 这样的模块，但最终得到的 Firefox 插件产品中却不含一行 Perl 代码，可以安装在任何机器上。当然了，XUL::App 并非建站框架了，但有许多类似之处。

随后，因为工作需要，开始开发 OpenResty。在这里，我们的"最终的二进制网站"是一种极端，即完全由 .html, .js, .css 等静态文件组成，但却是高度交互性的。所以这种网站的布署成本严格为 0，毕竟它是纯客户端的网站，完全运行于用户的浏览器中，因此即使没有 lighttpd 和 apache 这样的服务器，直接从桌面双击打开也能正确运行。

然而，我们同时必须解决中央数据源的问题，所以我们走了通用目的但同时又是用户可定制的 web service 平台和跨域 AJAX 的道路。我们已经成功地得到了纯 JS 的博客、小BBS以及公司主页性质的网站。我们下面还要尝试纯 JS 的全功能论坛，纯 JS 的 Gmail 和 RSS Reader，以及原生 PHP 站的生成（不能否认 PHP 的布署在许多最一般的情况下比 Perl web app 要容易要经济，所以我们是朋友，不是敌人 ;) ）关于这个主题，我可以一直说下去，呵呵，不过这次 Perl Workshop 上的 OpenResty talk 我还可以慢慢道来，呵呵。

巧的是，clkao 也在我之前做过类似的尝试。他试图从使用了 Template::Declare 的 Perl 代码生成原生的客户端 JavaScript 代码，利用了一些 B::Deparse 模块的高级技巧。与 XUL::App 类似，他也把 perl 的 Maketext 的 I18N love 带给了客户端的 JavaScript 代码。必须承认，这一点也值得 XUL::App 学习，目前 XUL::App 的 I18N love 只限于 XUL 代码（虽然 JS 代码可以利用隐藏的 DOM 节点技巧而享受到 I18N，但无疑有些 hacky 了）。

无论如何，Jifty （以及最近的 Prophet）都是非常值得一看的好东东。我参加工作以来的大部分 $project 的灵感都来源于 Jifty. 所以我曾和 Jesse 说过："I've found myself stealing good ideas or even code from Jifty in $work but avoiding using Jifty directly."

那么作为初学者，学习那个好呢？以鄙人之见，博采众家之所长方是"万全之策" ;)