Published: 2017-06-27

编程语言几点迷思

Java vs Lisp

暂时还没有想好怎么描述这两种现象,故取代表性的两种语言。

语言的表达力强的语言好于表达力弱的语言

表达力强的语言一定好于表达力弱的语言吗?

毋庸置疑,lisp的表达力是远高于java的,无论是macro, 还是对编程范式不强制性。

什么是好,对于不同的使用者答案并不一样。在一流的hacker手里,表达力越强使用起来越自由,生产力也越高。对于普通使用者可能差异并不明显。而对于一定规模的组织使用者来说,表达力越强,代码会需要一定的规范来控制和限制,才能产生一个多人可共同维护和参与的效果,这点上可能可以部分解释为什么大型企业偏睐java这一类限制性很强的语言。

这自然而然引出下面探讨的一点

限制和自由

java对于语言使用添加了很多限制,防止使用者做傻事,而lisp则拥有极大的自由,允许你做任何能做的事。

这两种设计或者哲学思想在产品中也很常见,像windows和unix,apple os和android。

站在编程语言发展的角度来看,限制的好处在于帮人们约定一定的条件,出来的代码或者软件互相之间可以方便地交流沟通借鉴,由此使得整个生态更加健康,而较低的沟通和学习成本以及健康的生态会吸引更多的人来贡献和完善,形成良性的循环。这也解释了java生态生命力如此旺盛的现象。反观lisp社区间缺乏统一的凝聚,各自分裂成几块,新生面孔少,跟语言自由的特性或许脱不了关系。

站在个人使用者的角度来看,同样水平的人使用lisp的生产力要比使用java要高。因为使用lisp直接切中要害地解决问题,而是用java在解决问题的同时会额外承担一些限制导致的消耗。对于个人或者小型项目来说这些消耗没有必要成了累赘和繁琐,而对于一定规模的组织来说,这些消耗是使整个团队效率最大化的必要支出。

这样推到出的结论是,同等程度熟练下,对于个人或者小项目来说,lisp使得生产力最大化,而在大型组织中,java才是团队效率的保证。

然而如果考虑到生态这一影响,使用java仿佛站在了巨人的肩膀上,所以推到得到的结论可能更加倾向于使用java。

所以也解释了很多人喜欢用lisp类语言快速原型,然而用java类语言具体实现。

万能的语言和不同领域挑选适合的语言

Paul Graham 在《黑客与画家》中描述过愿意采用100年后的编程语言来作为现在的开发。作者指出编程语言存在一个进化的脉络,一些语言会进入死胡同,所以更倾向于选择靠近主干的语言。另外一方面是,编程语言可以分成两大组成部分:基本运算符的集合(扮演公里角色)以及除运算符以外的其他部分(原则上,这个部分可以用基本运算符表达出来),作者认为基本运算符是决定一种语言是否长期存在的重要因素。内核最小,最简洁干净的编程语言会存在于进化的主干上。第三点是作者看来预测100年后的编程语言可能时间靠谱的做法,因为软件发展以及走过了50年,编程语言的进化速度更响数学符号的进化而不像真正的技术(比如交通和通信)的进化速度,而且未来增长的算力会被合理“浪费掉”。

在我目前看来,编程语言的发展更像是技术变革的选择,从系统编程选择了C, 网络编程助长了的Java, php、ruby、javascript等在web开发领域的大放异彩,虽然有很多通用型编程语言,但语言的生态已经发展出来适合做一类或者几类特定的事情。当出现新的大的技术变革时,发展一门新语言来解决特定的问题要比在原有语音上演化来得更容易,从经济角度上来说就是成本更小。或许类似于大公司和小公司,当新的浪潮来临时,大公司没有小公司行动迅速,最终会使得某些小公司成为新领域的大公司,也许是因为在大的尺度上人本身的认识倾向于不改变或者是改变本身是件风险很大是事。这容易得出一个结论,大部分通用的编程语言(特别是他们的除运算符的其他部分)更像是领域特定语言,擅长解决特定领域的问题。

所以说,假设100年后还有编程语言,现在使用100年后的语言真的好吗?我认为从语言核心上来说是这样,但从领域或生态上来说,100年后的问题现在并不存在,挑选最能解决现在问题的语言,然后跟随着进化的主干道,挑选最适合新领域的语言思想和工具,因为学习一门新语言的成本并不太高,当100年后,使用的语言自然就是最能解决问题的最先进的。

让我想起一个有趣的比喻手里拿着锤子,看见什么都觉得是个钉子。不禁思考,如果考虑到学习一门新语言的成本可能小于旧语言演化的成本,追寻一门统一的通吃的编程语言意义真的有那么大吗?

变种问题

往小处来看的话,一个变种的问题是,编程采用普通的文本编辑器还是集成的开发环境,采用vim类还是emacs类。和编程语言不同的地方在于,编程工具更是单独面向用户的,好比在一家大的企业中你写出的程序别人需要读懂但你用的编程工具并不一定别人要理解。以后再思考整理。

Author: Nisen

Email: imnisenATgmailDOTcom

Emacs 25.2.1 (Org mode 8.2.10)