一个实际的Lisp项目开发心得
在万家灯火，元宵节的烟花绚烂绽放的时刻，checkin了代码，随手统计了下代码行，恰好1000行整（包括空行）。冥冥中自有天意？
这个项目是一个分布编译打包发布程序，需要控制多台远端的服务器进行编译，编译过程有很多步骤，还要根据需要增删build 的步骤即参数。
最早的程序是用Python写的，只在一台机器上作，后来随着项目越来越复杂，打包编译花的时间越来越多。于是决定重写，那谁说重写代码是创业公司自杀行为来着？简直扯淡。
我决定使用 Common Lisp 来重写它。经过一周多时间，基本完成。
这一千行代码作的事情却一点也不少，它包含了：
1. 一个web界面，大概6、7个控制器，两个主要的view （没有html模板文件，都是通过lisp代码生成)
2. 一大堆的编译配置选项
3. 操作数据库的部分
4. 解析遗留系统 json 文件的部分
5. 通过ssh 执行命令，并将命令输出结果显示到web页面的部分
6. 编译任务的部分 ： 创建、运行状态跟踪、命令输出
再整理下代码，估计可以缩减到 700行以内。
通过这个项目实践，对自己使用lisp的信心更足了。越复杂的项目，它的优势体现的越明显。
Common Lisp开发相比其他语言的一个核心优势是它的开发流程！
通过emacs + slime 这类工具，可以实现程序边运行边修改。程序运行中，可以修改函数代码，也可以修改程序中的变量的值，而不需要重新启动程序。这一点是相比其他开发语言来说非常显著的优势。
用common lisp开发的一个典型工作状态是： 打开emacs ， 通过slime 开始执行程序，然后在源代码的各处敲敲打打，边修改边看执行的状态，还可以立刻在 repl 环境下修改变量的值。
这种边运行边开发的模式与PHP那种还不同，PHP程序虽然修改完可以在网页上立刻看到效果，但是是重新启动了一个执行的进程，之前的运行环境都要重新来。
Python也一样，虽然python有类似Lisp REPL那样的交互环境，但是却难以修改源代码，并非不可能，实在是没有趁手的工具。
再往下说 Java C++一类编译型语言，写程序与编译调试运行，整个流程分的太开，流程太长。
这种快速增量开发的模式，带来的就是更高的开发效率，和更复杂问题的处理能力。