离散数学，前几章节

@workaholic 你真的理解我说什么了吗？你真的看那本书了吗？雷死我了。和你讨论这个就是我的错误

@workaholic
最初接触编程的时候我的想法和你是一样的。好比武学的“无招胜有招”，听上去不错，好比世界大同的美好愿望，看上去美好，但实际却不现实。

聪明人不会干费劲不讨好的事情，高手有能力去驾驭任何语言，但不代表他有必要去用一门拙劣的语言干NB的事情。事实是，那样不NB，反而显得很不明智。

很多linux kernel党就都不怎么喜欢C++（我没有贬低C++的意思），就是个例子。

你可以看看《黑客与画家》，看看保罗•格雷厄姆对编程语言的观点。

@clino 这个所谓的“理解错误”是你一厢情愿的，我承认的是我以为python有shell那样的缺点，那是因为我对它确实不了解。至于你扯解释和动态语言的关系，真的都是你一厢情愿。不妨看一下聊天记录。

@clino 这句话完全成立，主要也是和aisk同学说的。具体实现当然有分类，这是废话。但谈论语言(本身只是一套规范)的分类不一定有结果，因为不一定只有一种类型的实现，怎么叫只是因为惯例，就这么简单。仔细看一下前文，我只是说部分解释型语言（如果你一定要咬文嚼字的话，就是部分语言的解释型实现）的缺点。我对python不够了解(也没兴趣)，通过DR.蔡 的这番论述，以为它也有这个缺点，这点你已经说清楚。我对python没有好恶，你也不必护主心切了

@aisk 那你就认为我是耍流氓把。这些叫法确实都是convention或者tradition，而不是一个truth。LISP的情况在习惯中确实没有被划分到任何一种，那么这就是它的convention，遵循它就是了。

@aisk gcj诞生于openjdk诞生之前，人们希望有一个开源的选择。如今用得不多了吧。我试用过，执行不一定比jre快，更多时候还要慢。

刚才已经说了，语言规范是脱离于实现的，但是还是会按照主流使用方式和惯例，把XX语言说成编译型，把XX语言说成是解释型，这样比较有实际的参考价值。

@keakon 文章见解倒蛮独到的，一直很反感GB系列的编码，没想到还有其自身优势。但是从非技术层面来说，unicode以及得到推广，用起来比较方便，为了省几个字节而用中国国标，老外肯定不答应。

@workaholic 我认为高手最在乎用什么语言，不同语言之间简直就是不同的宗教，为信仰而言。用热衷函数语言的和热衷OO的几乎是两个世界的人

@clino
@aisk
理论上是不存在编译和解释的分类，两者皆可实现。但是我们还是会以其通常的执行方式作为区分。我一直认为java之类的就是第三类存在，字节码也有自己的指令集，相当于一种虚拟的汇编，而再vm解释成二进制。用字节码技术的语言，有编译型语言的执行效率，但同时又可以具备更多的动态特性。

@xspoco 淘宝现在的政策是偏向于买家，所以遇到问题，和卖家沟通不了，找小二没错的

@clino 你说的其实应该归为第三类分类，字节码是种中间状态，而非二进制。java有JIT，所以还是将其归为编译语言。

@ccming 用个golang mascot的头像，帮ruby说话，太没节操啦。。。。。

@qinix 如果从这样一个角度看：都是整数和浮点数，就是长度不一样。貌似还真是成立的，哈哈

大拿说的话，听了就当真理。也不搞清楚人家什么意思，显而易见的错误当然由编译器抵下了，业务逻辑上的bug，自然不能依赖编译器。

@clino 和动态静态没有关系，我说的是部分解释型语言的缺点，比如shell，函数声明都必须在前面。纯粹逐行解释，没有全文遍历的解释型语言都会有这个问题。但，但凡动态语言，基本都是解释型的，js、python之类的解释型语言通过词法分析和语法分析得到语法树后，就可以开始解释执行，语义上的错误必须在运行期才能发现。所以真正的错误运行了才知道。如果没有足够的测试用例覆盖所有的代码，其可靠性比静态语言真差远了。

it seems that go does the right thing and does it right...

解释形语言需要运行时排除语法错误，这点确实是硬伤

@leegorous 没错，组合（聚合）+duck typing也是OO的一种良好实现（Go就是这么做的），没有人说过继承是OO的绝对内涵