我所踏入的，并不是蓝海

从刚到日本开始，我就在帮忙做一个自然语言处理用的小工具了，后来这成了我的打工。

我在这份工作里尝试了gltracy介绍的Node结构的程序框架（很美）；把复杂的类抽象成接口，用工厂提供不同实现方法的对象（可以说失败了）；了解了盲目大规模重构的代价；用python作为脚本扩展java（Jython）；java的GUI编程（Swing）；多线程的一些基础用法（synchronized、CountDownLatch之类）；用eclipse的tptp插件找自己程序的性能瓶颈；斯坦福大学的parser和自己的程序结合的方法；trie字典树；chart算法；用于树结构的正则表达式（完善中）…… 可谓收获颇丰，我非常满足。

其中最让我自豪的就是用于树结构的正则表达式。以正则表达式的语法找到树中的指定节点，然后把它替换为新的节点，或者修改它的属性等等。本来觉得实现这个逻辑太麻烦了，但又找不到这方面的库，于是就一点一点增加功能，终于成了一个稍微拿得出手的小玩意儿了。可是，最近在查PCFG的实现方法时无意中发现斯坦福大学早已经实现了我的想法，而且实现的更为彻底，可以支持的搜索条件远多于我的，估计对特殊字符的应对也会比我的无保护模式好得多吧= =。

以前也遇到过类似的事，当时是我想找一个功能全面的树节点类，查了查java自己没有这个结构，于是没多想直接自己实现了一个。之后为了维护这个树节点类的各种bug，我可说是呕心沥血，最后发现其实用一般的XML节点类就完全可以胜任树节点的工作（jdom/jdom2）。于是进行了第一次大规模重构，把我的节点类全面替换为jdom的。当时想顺便修正一些破坏程序易读性的随手写的代码，结果导致重构时间远远超过预期，代价惨痛。不过这是另一个话题了……

斯坦福的实现虽然更完善，但要换成他们的库又需要我的程序做很多重大修改，而且他的语法并不是正则表达式语法，所以我们现有的几千条已经写好的表达式脚本要逐一手动替换成斯坦福风格，还要让用我这个工具的研究员改学另一套脚本语言。这一切代价太大，除非非常需要他们的某项功能，否则我不想做这个替换工作了。

这次发现对我的影响在于，打碎了我原本“实现世界上第一个用于树结构的正则表达式，让它成为我的第一个开源项目！”的幻想，也让我感觉到自己离这个领域中的蓝海的距离。