最短的捷径就是绕远路

最短的捷径就是绕远路

题图自如何解读杰洛说的「最短的捷径就是绕远路」? - 知乎

最近在拜读History of Programming Language,有2K页,累&无聊死了,但有时候很有意思:

The American side of the development of Algol -

几天后,Algol 58会议进入僵局 - 某欧洲佬拍桌而起:我永远不会把一个句号当小数点用!

当晚,Wegstein 提出了一个建议:我们搞三个语言,一个标准语,只有AST,一个交流语,用于把程序写上书里面交流,一个机器语,代码怎么存机器里面是这解决的问题。

哎?这不就是non textual representation of code吗?学过smalltalk/lamdu/MPS,用structural editor的,都知道这个。对于不知道的,可以看看Why Concrete Syntax Doesnt Matter

然而,smalltalk是1972的,比这晚了整整14年,并且59年后(2017),这方法也没成主流。

是什么,使得Algol 58如此超越时代?很简单,因为当时5年后才有ASCII,Algol也是史上第零个有标准的语言。这导致没有一套能关照各硬件的字符集,也没有大量把concrete syntax,language reference弄一起的语言(当时语言就几个),就自然不会让人先入为主的产生‘编程语言就应该定义syntax’。

当然,还有那不知名的欧洲佬对美帝国主义的不妥协。

从这,可以得出一个principle of noncompromise:

一旦妥协,接受局限性,后人就会把局限性视为理所当然。而没有问题,那儿来的答案?跳出盒子思考的最好方式,就是一开始不弄个盒子。

无独有偶,几天前在参加lambdaconf,去听APL,讲师开发了个APL -> C with GPU的编译器,源代码为946行(最短时期750行)跑在GPU上的APL(这项目叫Co-dfns by arcfide)。

猜下是用什么开发的?两个记事本。一个屏幕分两半,左边一个,右边一个。没有scroll bar。代码文件则叫做a, b, c...简直是跟主流开发流程反着来!

为什么?大体如下:

“当我用着最糟糕的工具,有最严苛的字数限制,最没帮助的命名,我明白,代码必须写得最短最清晰,否则记事本的糟糕界面就会让我无法继续。这也是为什么我强烈反对IDE的原因。”

换句话说,这是principle of noncompromise的应用-把问题极端化,让之不得不被解决。

真微妙啊,完全相反的两种syntax处理方式,竟然可以由同一条principle激发出。

文章被以下专栏收录
22 条评论
推荐阅读