the fallacy of “the right tool” ]

因为源代码依附 于它的编程语言,它们是一个概念上的合体所以,我建议,当我们在谈论编程语言时,应该改成“使用正确的材料来干活儿”的说法相比起选择是使用飞利浦的 螺丝刀还是三菱的改锥这样的问题,我们修改后的说法会对编程语言的选择起到更深远的意义材料需要持久的耐用,而工具大部分时间是丢在一边

多语言编程

“用正确的工具干活儿”这话并不能简单的应用到编程语言上,因为它们不是工具,而是材料这就是为什么在一个项目中大量使用多语言是危险的它很容易让项目变成一个混乱的“复合板“项目

如果你的工具碰巧是 一种编程语言,那你生产的源代码将和你的工具融合到一起没有这个工具,你的产品完全不能运行很显然,程序员的生产的产品是“源代码”编程语言并不是扮演工具的角色,从软件的性质上 看,它应该是材料工具可以扔掉,材料构成主体

3月21日 深圳 osc 源创会开始报名罗,送华为海思开发板

我 们的上一个web应用项目里使用了6、7种的编程语言(groovy, java, html, css, hql/sql, ant)如果我们感觉需要的话,还可以轻松的再增加更多的语言再增加clojure, scala 或 ruby/jruby 并不会觉得不合适一个懂得多种语言并有能力在多种语言间切换到程序员就被称作“多语言程序员”

如 果我们在一个简单或复杂传统工程中使用一个工具,就比如用锤子把木片钉成橱柜,或用起子拆解计算机,当你完成了这个“活儿”后,工具会被你丢在一旁你的 最终产品(一个新的木橱柜或一堆电路板)并不包括工具大多时候,当你的活儿干完后,你的产品上不会再有“变更请求”

编程语言是产品材料

[英文原文:

编程语言不是工具

总结

在 上面提到的我们做过的web应用项目中,我们使用了很多工具grails是我们的框架,jetty是我们的web容器,spring framework提供了强大的服务,我们用idea把它们结合到一起我们可以轻松的用tomcat替换jetty,或用eclipse替换idea 工具需要可替换,甚至是一次性的

让我以一个免责声明来开始这篇文章:我绝对的认可懂得多种编程语言的价值,也认为“用正确的工具干活儿”是个好思想但在编程工作中,人们对这个概念有个误解,我认为需要在这里指出一下但请记住,对这个误解的诠释并不是来否定这个思想的

让 我从一个古怪的类比开始:假设这有一个电影,是关于一个政治阴谋,涉及到一系列复杂的国际冒险,冲突波及到7、8个国家每个演员都说着他们本地的语言, 没有字幕谁能看懂这个阴谋的情节?恐怕只有少数几个懂得多语言的制片人能欣赏的了这个电影我们大部分人都不会去看它

多语言电影

但它们也是工具

造成 多语言项目产生的一个主要理由通常是“使用正确的工具干活儿”的概念而这个“活儿”通常指的是一个大项目里的一些小任务,比如编译项目,访问数据库,实 现永不定型的业务逻辑对于每个子任务,都有某个语言能够更出色的完成除了人们对这种多语言的做法造成的隐藏成本存在争议外,还有一个对于“工具”这个 词的误解需要注意