如此大的时间差别（去年10月份到今年5月份那可是7个月之久啊），难道是编辑“手误”，手误也应该做个解释啊，怎么就是不回留言呢。之前我也注意到一些发表的论文（10月份之前发表的）中刊出的“收稿时间”大概也在今年的2，3月份，当时我还想怎么这么多在我之后收稿的却在我之前发表呢，看来这也许是一种故意行为，“潜规则”！！！

难道出版社就为了显示自己发表周期短欺骗广大科研工作者吗？先不说这本身就是学术不端，重要的是它直接给投稿者带来了巨大的风险——剽窃。试想一篇思想类似的文章如果是在去年10分之后投稿如果发表了（当然前提是其它期刊刊出的收稿时间是真实的），那会是什么情况？？不用说别人肯定认为是我剽窃，所以收稿时间应该是绝对真实的，我想这也是这个信息在文章中出现的主要价值！！！！。另外的小问题就是给投稿者的工作量/绩效统计带来不便，明明是去年的工作量怎么体现的是今年的时间，万一领导复查，怎么说清楚呢。

结论，再也不向此刊投稿了。

斯坦福大学上个月在Proceedings of the National Academy of Sciences学报上发布了一个研究结果：“媒体行业中多工人员（multitasker）的认知控制”，强调指出一个显而易见的事实：从效率的角度考虑同时从事多任务，绝对会影响工作效率。该研究审视了IT领域中一个广为人知、却常常为人忽略的现象：不断出现、正在发生的多任务工作方式。敏捷实施者们这样写：这下可算有理由让团队只开发一个产品了，而且只能有一个产品负责人——将时间花在多个任务之上绝对是效率低下的工作方式。

Wired杂志指出：虽然其他研究重点关注多任务工作方式的眼前效果（比如：办公室里的工作人员经常检查邮件，这种情况下的工作效率），该研究提出了一个不同寻常的问题：“要是人们总在使用多任务工作方式会怎么样？”Stanford的研究者Clifford Nass、Anthony Wagner和Eyal Ophir调查了262名学生的媒体消费习惯。19名使用多任务方式最多的学生和22名多任务方式最少的学生此后参加了两个电脑测试，集中精力完成手上的测试。

他们使用了一些标准的心理测试指标，研究结果显示出：经常在多个信息流之间转换的学生，他们会在e-mail、网页、视频、聊天和电话之间来回切换，他们取得的进展远低于不怎么采取多任务方式的学生。更令研究人员惊讶的是：在任务切换能力的测试上，“重度媒体多任务人士”表现更差，“似乎他们过滤不相干任务的干扰的能力更差。”

该研究再次强调了认知科学家反复提到的事情：同时处理多个信息流的输入被认为是人类认知能力的问题。

对于造成差异的原因——被定位使用多任务方式的人是不是先存在心智上的不健全，还是说多任务方式造成了这种情况——“这是一个需要投入上百万美金才能回答的问题，可是我们没有一百万美金去取得答案。”Ness这么说。

Wagner接下来打算用脑部造影方法来研究多任务方式的神经学解释，而Ness将会研究儿童人群在多任务习惯上的发展。

文章开头指出，“productivity”（生产力，此处译为工作效率）通常被定义为生产效能(efficiency)、度量(metrics)，以及在生产过程中单位输入得到的产出的衡量。但对IT人员来说，什么是生产效能呢？作者给出了一个非正式的定义“一个有效率的人是指那些能够在指定的时间内以高质量的方式完成指定工作的人。”这引出下一个问题：我们如何做可以使员工更有效率？

作者援引Mr. Elgan在2009年4月5号的Computerworld那期中的一篇文章“Why Goofing Off at Work Boots Productivity"中的话说，

那些偷偷在Fackbook和Twitter上花少量时间的办公室“懒鬼”(slacker)比那些全部时间都用来做工作的人能做更多的工作。墨尔本大学的研究人员在一项新的研究中证实了这种真实性。他们的研究发现，一般来说，那些为了个人原因在工作时间内使用Internet的人比不用的人效率高9%。

作者指出，尽管Mr. Elgan没有指出这些研究者是如何衡量生产率的，但他给出了为什么那些在Internet上花费时间的人更具有效率的一些原因：

• 潜意识仍然关注于工作中的问题，解决方案通常会在随后出现；
• “游手好闲”(Goof off)的时间是一段清理个人思想、消除个人顾虑的时间。在这一小段时间后，你会回来全身心的投入到工作中；
• 从项目或任务中的短暂休息也可能是在受教育（或学习），例如读一些与工作无关的东西。这些信息有可能在以后帮你解决另外的问题。

作者接着列举了一些管理者们在不鼓励计算机游戏或网络冲浪的情况下建议所采用的提高员工效率的方式：

1. 给员工有意义的工作。
2. 承认/赏识员工所完成的工作。
3. 给员工为了最好完成工作所需要的工具。
4. 批准员工休息。
5. 给予员工尊重。

作者还举了一个例子，说有个复有创造力的同事把键盘上的F1~F12都附加了新功能：

F1 Accurately reflect what’s in the building’s vending machines.

• F2 Display the current traffic report for the area.
• F3 Make every piece of software on your machine work exactly as advertised.
• F4 Play your favorite music to lower your blood pressure.
• F5 Bring up your favorite picture of the beach or of the place you plan to retire.
• F6 Show a running clock on how many hours you have left until you retire.
• F7 Show you where your kids or pets are (but be careful, this might not relieve stress!).
• F8 Automatically delete all emails that were sent “Reply All.”
• F9 Delete all meetings for the day, sending emails of regret to all attendees.
• F10 Show what your 401K balance was two years ago instead of today’s value.
• F11 Automatically start dinner/ESPN/CNN/soap opera (programmable to suit individual preferences).
• F12 Advance time to five minutes before quitting time on Friday of the current week.

作者最后指出，作为管理者，需要关注如何现实的鼓励员工发挥他们最大的效率，还需要决定如何来优化工作环境。只要求生产效而没有适当的管理支持和资源将适得其反。作者认为，不时地准备一块蛋糕（不管什么原因）可以鼓励团队和沟通。

By the way：作者是美国能源部国家核安全管理局的CIO。

作者首先介绍了在软件集成和软件开发中涉及的术语/技术浩如烟海，但是开发者却只坚持某种技术，而必须使用其它技术来解决问题。这种现象在开发语言领域也是一样。开发者总是使用自己喜欢的语言，而非解决问题最优的语言，会造成设计方案的不优。

作者指出在日常开发中了解和使用多种编程语言可以带来显著的好处，因为没有任何一门语言适用于解决所有问题。而语言的存在也主要是由于它适于解决某些特定方面的问题（在解决某些问题方面比其它语言好），因此，不断有语言出现和消亡。在编程语言设计和开发中涉及许多需要权衡的因素，因此，这为许多不同的方案和变体预留了空间。

作者指出，大部分单一语言开发者倾向选择用于通用目的的语言（像Java、C++等），而不是特定的编程语言。通用的编程语言可用于解决更广范围的问题，但它们通常都是提供的折中的解决方案，不是太好，也不是太坏。当然，一些单一语言开发者尽力去挖掘语言的高级特性，来将语言的能力发挥到极致，但这些程序员仍然受制于这门语言实际的限度。

作者指出语言的选择对开发效率是一个重要因素，选择正确的语言所带来的开发效率的提升是巨大和值得这么去做的。作者以对XML的处理为例阐述了此观点。通用语言，例如Java在处理XML方面没有专门设计上的支持，这使得开发人员在使用通用语言处理XML方面忍受这种不匹配，来进行拙笨的开发，造成非优的解决方案。在这种情况下，为了提高效率，他们通常采用一些代码生成技术，把XML构造块影射为静态编程语言的构造块（通常是类）来尽量缓解这种阻抗，即便如此，这种方式仍然是十分脆弱的。因为把高度灵活的XML构造块转化为严格的静态的数据类型很容易造成彼此版本的不匹配。XML文档的任何改变都需要新的代码生成、重新构建、....这使得通过代码生成获得的一点点好处又被不断维护带来的成本所抵消。相比之下，Python、Perl、Erlang等语言都提供了XML处理模块，甚至还带版本化功能。更好的像ECMAscript for XML (E4X)和Scala，提供了对XML字面量的支持支持，开发人员可以直接在语言语法中写XML。消除了阻抗，带来了更简化的代码和更清晰的功能。

作者指出，选择适当的语言所带来的效率的提升还体现在对代码的维护上。作者援引Fred Brooks在《人月神话》中引用的的研究发现说，所需开发和维护的工作量与指令的数目（可以理解为代码行）是指数关系，而且这与所采用的语言无关。假设这个指数值是1.5的话，那么如果代码行是原来的3倍的话，那么就需要5倍的开发和维护成本，如果代码行变为原来的5倍，就需要11倍的开发和维护成本，如果代码行变为原来的10倍，那么就需要32倍的开发和维护成本。选择正确的语言，不仅可以减少代码行，更快的提供解决方案和对需要的响应，这个过程可以变为积极的循环，更少的代码带来更好的缺陷和更容易的增强（维护），这又使得用户更高兴，提供免费的广告宣传和反馈，进一步促进软件的发展。

作者指出，多语言编程的一个问题就是如何使它们协同工作。这可以分为两类。如果是用于分布式应用集成（即不同的应用用不同的语言），那么网络本身就通过协议提供了一个中立的方案，可以通过网络消息等。如果不是分布式应用，当前的主流开发语言，比如微软的CLT（公共语言运行时）所支持的语言越来越多，命令式的、动态的、函数式的，或脚本的。类似的，JVM也从一个单语言平台演化为一个可以支持许多语言的平台，包括JRuby、Scala、Groovy、JavaScript、E4X、Jython和其它的。而且，在JVM上，这些语言都容易学，因为都是基于字节码，这些语言可以与Java进行互调。因此，JVM提供了一个非常好的方式来为应用的不同部分选择最适合的语言。

作者还指出目前阻碍多语言编程的因素主要有两个：一个管理因素；另一个开发者认为学习新语言难度很大。对于第一个因素，管理者通常认为只采用一种语言易于管理，因为大家都用同样的语言，可以容易的替换开发人员，而且某个开发人员写的代码，大家也都能看懂，避免陷入只有少数人才能看懂和维护的局面。作者认为这种管理者对软件开发和维护所涉及的成本没有充分考虑。在一个JVM或CLR基础之上，选择合适的语言可以减少代码规模和开发维护的工作量，从而降低系统的总成本，而且，较小的系统需要更少的开发者，这又是一个巨大的成本减少。对于第二个因素，相比通用语言来说，那个特定的语言，像Lisp、Python等都很简练，核心概念并不多，初学者可以很快发现它们更具有生产力，而且，以往语言的经验可以帮助你学习新语言。如果你掌握的语言越多，你就能更容易的学习一门新语言，也能发现解决问题的最好方式。

最后，作者以“毕竟，难道我们真的认为我们已经学到我们所需要的最后一门（终极）语言了码？”结尾。

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

欢迎您对自己所在的开发组织对于多语言编程、融合的实践和经验发表看法，谢谢！