php 语法恶心,怎么克服学习 Go 时的恶心感觉,语法太奇怪了

266

2019-10-11 11:35:06 +08:00

@ppphp PL 不一定是直接拿来编程的。其它的用法至少包括定制语言实现，以及拿来 spec 去 derive 新的语言。

虽然直接拿来写代码的用户最多，但这些人的作用也更容易被其他用户写的代码取代。语言发展得越久，这部分解决方案越成熟，这样的用户就越来越不重要。例如，内建的元编程普遍代替用户使用外部脚本编码的能力要求，仅仅是为了生成代码而掌握脚本的开发者在市场上的重要性越来越低，只会这样的技能竞争的开发者就会逐渐被市场淘汰。

而不想被语言牵着鼻子走的开发者，多少必须了解语言在用来编码以外的实用意义，其中对大多数人最明显和差不多最容易的就是评估对选型的影响，而这和理解设计非常相关。

一个好语言，实用上应该是容易满足需求的语言，这并非能通过直觉就能判定，而需要选型分析作为基础。

除此之外，所谓写得快，(只要设计得不要故意找茬)更多是语言面向的问题域决定的，解决不同问题的语言之间没多大可比性。然而不论一门语言原本面向的是什么问题域，上升到公共的通用领域，就要求语言必须容易被定制。越是通用的高级语言，这些用途的界限就越不明显，也要求越强的抽象能力和设计的一致性。

评价这样用的语言是不是够用(先不说好)，要求用户需要有熟练理解不同语言设计和实现的经验，这对大部分只是满足写得快跑得快的用户来讲是非常高的门槛。对 PL 理论的理解可以降低这个门槛，因为现在已经很难彻底设计出的新的好用的机制，而基本上所谓的新语言都是堆砌已有的设计而已，这些设计很大程度上是 PL 理论中已知的(尽管理论基础仍然非常不全面)。

在这个背景下，开发者理解的所谓对语言的直觉是分档次的。有的开发者只能粗糙地认识到某个具体语言的代码写起来容易不容易(而且没写过不被坑还不知道)，另一些开发者能在不写具体代码的时候光凭阅读语言的 spec 就能看出某一类语言在项目中有什么坑，高下立判。

至于实际项目为什么用看起来蠢的语言？无非是妥协。不说培养直觉的问题，光是阅读 spec 就需要投入时间，这比直接暴力试错慢得多了。只要使用的语言不是没有可用的实现(而得自己糊一个)，这样的收益并不明显。对只需要用一种或者少数几种 DSL 就能大致满足需要的领域，效率显然太低了。

但这反过来也就说明，这样的领域还有更重要的本领域内部的业务问题没解决清楚，没发展能到利用通用的可编程性和自动化普遍地提升该领域问题的解决效率而已；对口味不挑的非专家，随便一个不要太反人类的语言就能基本糊弄过去了。

另外你看来有个显然的误区，认为解决问题的难度和“聪明”有关系。而从可用性来讲，大多数搞数学的还真在这方面明显不够聪明； Python 这样已经被实现出来的语言再烂也比大多数数学家平时使用的语言像样。