为什么程序员动不动拽英文单词不是装 B

2015-12-07 00:42:02 +08:00
 cheka
看到我厂另一位同事写的“为什么程序员英文要好” https://tanronggui.xyz/t/239995 特来呼应一下。

(部分内容曾经发在知乎 http://www.zhihu.com/question/23581913/answer/25023096

类似以下的对话几乎每天都会发生在我们公司——我们公司不是外企,只是民营小企业,也没有国际友人。

“用户报了一个 bug ,我提个 issue 给你”

“好,我 check 下。”

“这个 bug 我 fix 了,代码已经 commit 。”

“那我们下周升级这个 App 。”

这四句话里,有 6 个英文单词,我给它们做个归类,分析下为什么我们会不自觉地选用英文而非相应的中文单词。

首先, bug 这个词已经深入人心,专指计算机软件产生的问题,不仅是专业的工程师用这个词,很多用户也会直接说这个程序有 bug 我用不了。这个从早期计算机教育里就引入的英文单词已经用来专指软件的逻辑故障,比任何单一中文词汇都更加准确;譬如如果改说程序出了故障,大部分人很可能第一反应是硬件问题,如果说程序有了问题,又无法立刻表明究竟是使用产生问题还是程序本身问题。

再看 issue, commit 这两个词,中文可以翻译为“工单”和“提交”,为什么我们要用英文呢,因为我们用的代码和问题管理软件里用的就是这两个词,所以对一个工程师说我给了你一个 issue ,那么他第一反应就会打开管理软件去查看,说的人和听的人脑子里都不用翻译转换。当然,如果用的软件是中文的话,我相信我们肯定会用“工单”而非 issue ,总之怎么省事怎么来。

再看 check, fix ,还有 App ,在中文里是有相对明确的对应词汇的,分别是“检查”,“修复”,还有“应用”。实际上我们也确实有时候会用对应的中文词,但是用英文更多,为什么呢?因为这几个英文词念起来更省力啊。

所以深究起来,想要用语言口头表达一个概念,以及想要理解自己听到的一个概念,都是要付出成本的,前者会涉及到词汇是否好念,是不是能够第一时间想到(从概念转换到词汇),后者会关系词汇是不是清晰(同音字 /词就很讨厌),是不是能迅速理解(从词汇转换到概念)。

在语言学里有一条著名的经验法则, 由哈佛语言学家 Zipf 提出并以他的名字命名,也就是 Zipf 定律。 Zipf 发现,如果把一种语言中的所有的词按照词频从大到小排序,并记录它们的排列位置,那么一个词的词频 f ,和它的位置 r ,近似满足如下关系:

f*r=k 其中 k 是一个常数。

掩藏在这公式背后的意思是,对于同一个概念,说话者期望选择一个出现频率很高,但是词义较含糊的词来表达,而听者则希望接受到一个出现频率很低,相应更精确的词汇。极端情况下,说话者巴不得只用一个词就能表达天下所有的意思,而听者则最好是一个萝卜一个坑,一个概念只有一个词相对应。总之双方都指着对方多担待,自己省点事儿。 Zipf 将此称为最省力原则(Principle of least effort).

对应这个原则的 Zipf 定律就是反映了说者和听者两者间讨价还价最后的折衷,即只有相当少的一些词能够表达很多语义,相应具有很高的出现频率;而绝大多数的词则能较准确的表达特定意思,也就只有较少的出现频率。

虽然 Zipf 定律针对的是同一种语言内部,但是在全球化的今天,很多英文词汇已经因为指向明确(因为很多概念首先来自英文,并且在其他语言还没来得及翻译的时候就已经广泛传播),同时也好念,从而符合最省力原则,在口头交流中被双方接受。


反过来说,如果我和一个非软件行业的人解释我们的工作,我基本不可能用任何英文(当然 bug 这个词例外),因为那时候我很清楚光自己说得爽不行,对方听不懂一问再问更麻烦,不如一开始就用中文。


所以说当我们一群码农在内部交流时不停冒英文,真的只是偷懒,而不是装 B 。

非 IT 行业里,很多情况也类似,很多英文术语会直接对应该领域中某个流程中的特定环节,提高沟通效率。


总之,这些单词就是这个行业的黑话。

另外,传说计算机开发中有两大最困难问题:更新缓存,以及变量命名。英文水平高一些,对于变量命名是非常有帮助的,一个不准确或者含糊的名字,不仅会给阅读者(甚至包括起名字的本人)带来歧义,未来还会妨碍新的命名,实际对程序是一种污染。

我们自己遇到过一个实际例子,打卡被命名为 checkin ,当时虽然感觉不是很准,但是将就用了;等到我们策划签到功能时,发现签到的英文就是 check in ,那怎么办,要改的话,不仅后端代码里有,各种对外 API 里也有,意味着所有移动客户端都要改,还要照顾那些不升级的老客户端;可是不改,就要想一个新名字,可这个不准确的新名字一方面用来别扭,另一方面还可能造成未来同样麻烦。

总体来说,扇贝对工程师的英文水平要求是很严格的,甚至扇贝程序中所有文字,实际上是先写成英文,再翻译成中文。虽然一开始有人觉得浪费时间,但是逐渐大家还是接受了,好处是从工单描述,到变量,再到注释,都能尽可能维持一致性。

我们曾经拿托福阅读题给公司里所有员工都做过一次测试,工程师的平均成绩和大部分是英语专业毕业的内容编辑团队是一样的,还有几个满分。
13413 次点击
所在节点    程序员
122 条回复
FrankFang128
2015-12-07 10:53:08 +08:00
没有时间跟你扯,我在一秒钟前在命令行里敲了 git push ,难度我还要翻译成我刚才 git 推了一下,你 git 拉一下。

这样说话很神经好吗?编程届中英混杂无法避免,谁给我翻一下 Linux 的中文, review 翻译成审查也不对,审查太正经了,而 review 真的就是只是 re-view 一下。
FrankFang128
2015-12-07 10:54:48 +08:00
@cyr1l 单词长度低于 5 个字,就是装逼。
MForever78
2015-12-07 10:55:48 +08:00
我是前几天才知道句柄原来是 Handle 翻译过来的。

FML...
liangguan5
2015-12-07 10:58:20 +08:00
程序员使用 bug 等英文一点都不装 B ,但您的标题「动不动拽英文单词」本身就隐射人家装 B
kingme
2015-12-07 10:59:25 +08:00
@felinx 所以如果这篇文章是他们内部论坛的,并没有什么不对。相同的话,放在不同的地方,产生的效果可以是很不同的。

我甚至可以要求我的团队 写 C 不洗 def mian main ,这是我的要求,有什么不可以呢?但是,程序员写 main 就应该写成 mian !这句话对吗?
Lonely
2015-12-07 10:59:44 +08:00
楼主,我 fuck 你
10iii
2015-12-07 11:01:12 +08:00
广总:<程序员在工作对话中允许使用的英文单词清单>
fim8
2015-12-07 11:05:07 +08:00
真的累。
learnshare
2015-12-07 11:05:46 +08:00
编程界仍然是以英语为主要语言的,如果某一天易语言变得大众化,我们也会用中文来装一下。

g67261831
2015-12-07 11:08:55 +08:00
有装逼的可能。但不一定是全部。
leemail
2015-12-07 11:16:57 +08:00
"总体来说,扇贝对工程师的英文水平要求是很严格的,甚至扇贝程序中所有文字,实际上是先写成英文" ... "打卡被命名为 checkin "
cyr1l
2015-12-07 11:19:39 +08:00
再者说了, 装个逼怎么了? 这世道这么乱, 装个逼都不行?
StYu
2015-12-07 11:21:00 +08:00
因为代码是英文(易语言这种异类除外),命令行大多数时候是英文,而且很多工具都是英文的。
说英文更方便对方在界面上找到相应的操作位置,使用对应的命令。
再就是基于以上两点,大家都习惯了。
029xue
2015-12-07 11:25:35 +08:00
@leemail 这有问题吗?去酒店第一步不也是 check-in 吗?
chuhemiao
2015-12-07 11:33:03 +08:00
只怪我当初英语没学好,你在说啥
zouxcs
2015-12-07 11:35:28 +08:00
这个臭虫我已经修改了
874808862
2015-12-07 11:37:04 +08:00
会一点的都这样
Thoxvi
2015-12-07 11:50:48 +08:00
问题不应该是奔着方便 /高效来的么…习惯就好开心就好为什么要和装 13 扯上关系…
243205964
2015-12-07 11:52:18 +08:00
感觉这和装 b 没什么关系吧?习惯怎么说就怎么说啊,大家都能准确的理解就 OK 啊。
weyou
2015-12-07 11:52:21 +08:00
@learnshare 这算是有中国特色的爱国主义程序吧

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://tanronggui.xyz/t/241604

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX