今天被问了一个很有意思的问题：（Lisp 的）代码真的可维护么？（这里的维护，意思比较泛化，包含一般性的代码改动，甚至重写。）
缘起我在微博写道 “Noir 是个好东西”。Noir 是 Clojure 的 web 框架，而 Clojure 是 Lisp 的一种方言。看过《黑客与画家》的人应该知道 Lisp 是多么的光芒万丈，但同时又被很多人所厌恶，真是超典型的矛盾统一体。不过这里不打算讨论这个矛盾。将上面的问题转换一下之后是：
代码的可维护性跟语言有关吗？
我觉得有关，但这只是基于当前现状的。像 Lisp 这么小众的语言，应用到项目当中，技术人员一拨一拨的流动时（这也不算是一个好的现状，不利于自身的积累），如果想一直都能找到合适的人来做，这本来就已经是一个问题。在国内，许多不是技术驱动的公司里，几乎很难碰到会使用小众技术解决问题的（所以如果你遇到了没有这样的氛围却依然坚持不懈的玩各种小众玩意的，千万不能随意放手啊），技术选型的其中一项是团队里或者市面上都流行什么。但如果不存在人口基数的问题，代码的可维护性应该是跟语言没什么关系的。
代码的可维护性跟什么有关系呢？
架构。因为像可维护性，代码演进这些问题是架构设计的时候考虑的。代码书写的风格，代码的组织方式，资源布局，运行机制与策略等等这些都会有影响。除了架构，有洁癖的通常会比无洁癖的产出更容易维护的代码（写得烂不烂的问题是可以通过学习改进的），代码整洁整齐，用法一致也便于维护。
按照我的猜想，应该是可以使用 Noir 并产出可维护的项目的。
回到语言细节上，因为很多人接受不了那一连串的括号，总是第一感觉以为要人肉去数哪些个括号，特别是N多层嵌套的时候，和这个类似的，nodejs 推广过程中也好多好多个声音说 N 层回调嵌套看着头晕。
我有必要再解释这个问题么？如果反过来问，一个语言能给你带来的价值减去其缺点所造成的损失结果是多少？这不代表我承认 Lisp 或者 JavaScript 的缺陷有多大，有多招人讨厌，而是想说，我们能否正确认识其价值，放大其价值。
哪些语言被创造出来最大的幸福是其价值得到显现。当然，价值这东西很难拿出来讨论，自己心里明白就好。
也许在最大化其利益之后，那才是踏踏实实的讨论改正缺点，但是有时候，比如 Lisp 的括号（列表表达式），最大的缺点也正正就是最大的优点，最好的办法是，当没看见吧。