该不该限制程序员的语言?
该不该限制程序员的语言?当然,这里的程序员肯定不是 java 之于 hadoop,objective-c 之于 mac 的那种,而是像我一样,对于每天处理的任务,从 c/c++ 到 bash 几乎什么语言都能做到的那种。 前几天终于亲耳确认了是老大拍板要把团队内的脚本语言都统一成 python。作为团队一直在使用 perl 做主力脚本语言的我瞬间感觉胸闷。所以下面牢骚居多。 其实老大也明白,像 perl vs python 这样的传统圣战题材,是争论不出个所以然来的。之所以拍出这个决定,是为了减少团队的代码维护成本。这中间我隐隐约约嗅到了点 perl 代码难以维护的意思。 水母 perl 版主 flw 认为,代码维护难度的决定因素是写代码的人,而与语言关系不大。我补充认为,能写出无法维护的 perl 的人,写出来的 python 也靠谱不到哪儿去。 换一个角度,合格的程序员更应该对未知事物充满好奇。在 2009 年刚刚进入团队的时候,我对 perl 一无所知,当时反而是还写过一点 python。这些年下来,perl 沉淀为首选,其实经过了相当漫长的自然而合理的选择过程。与此同时,我也在维护着一部分 python 代码。两者各有其擅长的场景,通过数据而不是语言来耦合,我觉得这样最有效率。如果哪天出现一种在我的任务领域更有表达力的语言,我也一定乐于学习(请复习 程序员的三大美德 )。 所以当听到对于语言的强制规定时,我的第一反应是团队的人员要出问题。 以我不长不短的从业经历,还真碰到过一次强制规定语言的案例。那是刚工作不久。某元老级网游公司把原来外包给我们用 ruby 实现的支付系统用 c++ 重写了,也是号称为了降低维护成本。结果是以成本导向招进来的驾驭不了 ruby 的人也很难驾驭那个用 c++ 重写的系统。几年后这公司垮了。 这里可能还有屁股决定脑袋的问题。当领导的大概都喜欢整整齐齐的经济林,因为树苗可以批量供应,既便宜管理起来又方便。而在下面当树的,不想长成参天大树的恐怕不会是什么好种子,而经济林里大概很难长出参天大树来。 至于是经济林好,还是原始森林好,这又是个圣战潜力题材。怕是战不出结果的。 食君之禄,忠君之事。我目前正在用 python 重写以前的工具。不过我有两个愿望:第一个是但愿我的第一反应是错的;第二个是能把以前