领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
Bill Burke谈动态语言的现状与神话
作者 Ian Roughley 译者 韩锴 发布于 2008年2月23日
“我是个Java的狂徒么？”——这是个好问题。Bill Burke在他的博客文章“动态语言的现状与神话”中回答了这个问题：
也许是吧，但是我并不这么认为。...我也不相信Java是一切的终结。语言需要优雅的、类型安全的闭包功能，这样才能利用Annotation实现 DSL。它需要一种标准的、非代码生成的方式为Annation添加新行为。它需要一种结构化的句法来简化初始化。AOP支持可能也很好，或者至少JVM 的支持可以让实现类似于AOP的特性更容易些。在JVM和Java EE、Seam、Hibernate、Spring和JBoss AS等产品的API中，更好的Zero-turnaround开发特性会为开发任务带来极大的帮助。
他继续说道：
如果有一种新语言支持下面的这些特性，我倒是愿意放弃Java，但是这种语言必须满足：
尽管当前的动态语言具备了上述的部分条件，但却没有哪个可以包含一切。所以目前为止Java仍然是我的选择，而我也仍然是一个Java的追随者。
- 类型安全，静态类型
- 能够找到一个可与现代Java IDE相匹敌的IDE
- 存在丰富的API和库，可以很容易地构建应用程序
- 存在一个生机勃勃的商业生态系统
- 存在一个活跃的开源社区
文章还中肯扼要地探究了动态语言的一些现实与神话。动态语言的现实状况包括：
- 某某动态语言无法在某些基准测试中超越Java
- Ruby VM不支持内核级线程
- Ruby、Python这些动态语言不是类型安全/静态类型的
- 缺少了类型安全，语言在大型团队中很难具有良好的伸缩性
- 缺少了类型安全，就无法在现代的IDE中进行可靠的重构
- 软件工程师在工作中一定要用最好的语言
- 代码行数越大，意味着错误越多，因此动态语言比静态语言好
- 我使用某某动态语言的生产率高，是因为它的语法更清晰、更优雅、更强大
你可以在Bill的博客上读到每一项的更多细节，不过就其中大部分内容的争论已经由来已久了。最有趣的反倒是回复中的内容。关于动态语言，John Wilson发表了非常精辟的看法：
动态语言不是万能药，但是要想解决某些问题，它们的确是非常适合的工具。在另一篇回复中，Hypothetical Labs将Java的遗产看作是与Bill列出的各个特性相关的问题：
Java曾经对于非专业的程序员也是很友好的，但是它现在已经渐渐地偏离了这个方向（嘿，泛型，我就是在说你！）。在这种状态下，给Java添加任何特性 都不能让它变得更易用。IDE能够帮助专业程序员极大地提高生产力，但是需要程序员花很大力气去学习Idea、Eclipse和Netbeans，这样做 需要极大的时间和精力的投入。
我们建立了越来越多的障碍，使得编写JVM逐渐变得困难。如果持续下去，JVM就会死掉。如果开发JVM只剩下唯一的方式：去雇用昂贵的超级专家，那么一切就结束了。
如果专家们有了什么绝妙的想法，可以在几天之内迅速地开发了一个Jython、JRuby或者Groovy实现，假如这个实现不工作，他们其实并没有什么损失。但是如果这个实现可以工作，它会面临很多问题：速度慢、无法扩展、难以维护（注意，这些问题只有在应用程序成功后才会遇到）。然后你可以通过增加资源来修复这个问题（Twitter的开发者们似乎还没有指出过这些问题）。但是，如果完成实现所需的资源并不容易得到满足，那么能够从理论走到现实的想法就会大量地减少。
问题在于Java社区如何对待语言的变化。所有的变化都要做到向后兼容。由于担心会在某些地方破坏了一些应用程序，人们是不会轻易改变任何语言特性的。理 论上，我可以让自己写于上世纪九十年代的代码运行在最新的JVM上。这有些疯狂。[不！这是Java！-Leonidas] 糟糕的代码（cruft）受制于语言的发展变化，并堆积这些变化，直到语言的某些特性不得不被去除。看看泛型的产生过程以及正在制定中的闭包规范，就可以 知道现实中的单一设计决策对这种语言的发展究竟意味着什么...最后的结果是，语言和核心社区很担心变化。
Enrique Utrilla在一篇回复中提到，支持了Neal Ford提出的关于多语言开发者的观点，以及Ola Bini和Stuart Halloway的语言层解决方法的观点：
恕我直言，这个问题最终归结为三个关键概念间的平衡：生产力、维护的简单性和运行时效率。
也许我错了，但是动态在生产力方面上胜过了Java，就像Java打败c，c打败汇编语言一样。你可以很快地完成某些事情，这很棒，比如，建立原型和证明概念的正确性。
在维护的简单性这点上，Java和类似的语言（包括.NET，Scala和其他任何你喜欢的非动态的、高层的语言）胜过了动态语言。重构对于现代IDE来 说已经司空见惯了，而且大多能在编译时发现错误。然而动态语言只能在运行时才能检查到错误，最糟糕的是，仅仅是有时。
我最亲睐的方案是博取众家之长，提供一个多种语言之间的良好整合。用Java编写各个关键算法，然后用最合适的语言将它们粘合到一起。相对于纯动态语言的 实现，这样做在整体上提升了系统性能。这种方法对于Groovy尤其有用，它同时具备了与Java的相似性和与Java无缝集成的能力。（我承认我并没有 用Groovy写过很多程序，但它已经成为我第二钟爱的语言了）。这还是各个因素之间的平衡。
我认为作为开发者，我们都应该被问到这个问题“我们的社区在哪里？”当开发者在不同的语言和平台之间游走时，会遇到比新手写得好一些代码以及“骨灰 级专家”写的简明扼要的代码么？这些代码都需要重写，以便于软件的维护。语言应该变得足够简单么？这样我们依赖于IDE，并且非专业的程序员也可以做一些 事情，而我们，专业的程序员，就可以关注和扩展新的特性和非功能性需求，比如可伸缩性。我们应该保证向后可维护性么？还是在语言和库设计者没有考虑到的时 候，动态语言的灵活性允许我们添加向后兼容性？由于以前的开发者都纷纷转入到大量新生的动态语言和JVM平台语言社区上来，Java原本生机勃勃的开源社 区会日渐衰落么？
不过，Bill最后说道：我在博客中表达的真实意图不是要去抨击Ruby和其他动态语言，而是要去抨击所有含糊其辞的说法。就这一点来说，希望无论对于动态语言还是Java，都应该是这样的。
查看原文链接：Bill Burke on Dynamic Languages: Rationalizations and Myths
译者 韩锴 毕业于北京工业大学软件学院，现任ThoughtWorks公司咨询师，热衷于敏捷软件开发技术的实践和推广。
动态语言与静态语言并没有谁拥有绝对的优势能够战胜对方
发表人
张 逸
发表于
语言需要互相协作
发表人
Chu Kevin
发表于
Re: 语言需要互相协作
发表人
Yuan Shayne
发表于
Never heard of C#?
发表人
陆 超
发表于
Objective C/Cocoa
发表人
Huang Felix
发表于
-
动态语言与静态语言并没有谁拥有绝对的优势能够战胜对方，我很欣赏Enrique Utrilla的观点，博取众家之长，取长补短，在合理的场景下选择使用合理的语言。
-
之前infoq有一篇文章就讲到，需要各类语言进行配合，常用的静态语言作为基础，动态语言做一些敏捷的应用，而函数式语言可以在在dsl方面发挥更多的作用
-
[quote]
如果有一种新语言支持下面的这些特性，我倒是愿意放弃Java，但是这种语言必须满足：
* 类型安全，静态类型
* 能够找到一个可与现代Java IDE相匹敌的IDE
* 存在丰富的API和库，可以很容易地构建应用程序
* 存在一个生机勃勃的商业生态系统
* 存在一个活跃的开源社区
[/quote] -
nod
混合编程也许是以后的趋势 -
If Bill is not talking server-side application, I think Objective-C/Cocoa on Mac OS X is such a powerful language/framework that not only introduces the performance of C, but also emerges with type-safe language and powerful commercial/open-source frameworks and applications.
5 条回复
关注此讨论 回复