.NET开发人员，对于动态语言(Dynamic Languages)应该持什么样的态度

小鱼儿 2021-11-06 01:26 208阅读 0赞

#### .NET开发人员，对于动态语言(Dynamic Languages)应该持什么样的态度 ####

最近似乎有一种类似混乱的观点提出，说.NET的未来是转向Dynamic Languages，你看LINQ就是基础，C\# 3.0, VB9 的某些特性无非是很久之前许多Dynamic Languages的特性，而且Dynamic Languages多方便、多强大.....&%^$\#@@!!\#@\#  
我则认为这是继Java vs. PHP vs VB vs. C\# 之后的新版本，形式上更先进了，但是鼓吹"动态语言的世界即将来到“本质上会混乱那些正在奔跑或止步创造的年轻人。我不能说Dynamic Languages不好，但我希望.NET平台的开发人员对动态语言有一个自己的看法－那就是不要盲从和轻信。  
  
首先这需要你有两种判断，  
  
第一，认识到Dynamic Languages 有怎样的好处，有怎样的弱点。C\#很好，但它也有弱点，Dynamic Languages 有强大和过人之处，但它也有缺点.  
Mike Champion的文章 [”Beyond Dynamic Languages“][Beyond Dynamic Languages]，描述了一种完全动态的情况Dynamic Meetings、Dynamic Design、Dynamic Testing以及Dynamic Debugging 的情景，虽然有些夸张，但是他提出了使用动态语言为的是什么，它比静态语言的优势在那里？－－开发效率  
**Sure, they make some of your programming tasks a bit easier to perform, but how much time do you spend programming anyway? Most developers produce on average one line of quality code per week. It’s not that they are lazy; it’s just that the ‘coding time’ turns out to be a small fraction of the overall product cycle.**  
  
所以，想像一下一个资深.NET的开发人员，盲从意味着他今天要使用一种并不熟悉的编程语言试图体验新的动态语言的开发效率，这似乎有些可笑(但不能否认，有时候我们真的会看来某篇文章和报道之后去安装和尝试某个动态语言，而这些尝试和体验离我们当前正做的事情可能离题太远，但不可否认，我们还是去做了这个尝试)，而Mike的观念中，编程的效率来自许多指标和Measure的计量模型，扩大动态语言的好处，是因为我们的经验里，认为开发效率是编程和项目中非常重要的依据吗？--我知道，更多的人的回答是－NO ！  
  
第二个判断是有关编程语言的，提到动态语言，很多人会先联想到Ruby /PHP+/Python 的某些COOL的发呆的语言特性。  
Erik Meijer(达人一个) 有一句非常有趣的话："Static typing where possible, dynamic typing where necessary."  
  
其实这说了编程语言世界中一个三分天下的局面：静态的C\#/Java 等等在两极的一边，Python/Ruby这样的动态语言在另外的一极，而VB或其他的语言会介于两极之间，发展自己的特色。所以我认为未来的天下不会只属于动态语言。  
可以引用最近发生的一件事情， [A conversation with Anders Hejlsberg about the May 06 preview of LINQ][] ，Anders Hejlsberg阐述了自己的看法，认为SQL\# 不是创新，将数据查询和操作集成到编程语言中也不是innovative，他也不想让C\#变成动态语言。你会说，LINQ所做的和dBASE/Foxpro有什么不同？  
  
**”You get to write programs in the dynamic language style (without explicitly declaring and mentioning types) yet your programs are still strongly typed, such that they can be compile-time type checked and take advantage of tools like IntelliSense, statement completion, and code refactoring. “  
－Even if the overall idea is not new, I do think the way we've implemented it is both new and innovative.**   
  
这里还有两个关键的信息：

*  1。C\#/.NET率先和明确的发出这样的信号，.NET的编程语言/Framework要将数据查询和操作集成进来，并且更好支持未来XML、对象和各种数据的操作和查询。我想，Java, Python或者Ruby没有明确的显示这个信号，他们说我们有更多更COOL的动态语言特性，但Dynamic Languages != data/query integration 我想，data/query integration 以及 compile-time type checked and take advantage of tools like IntelliSense, statement completion, and code refactoring.加在一起提供的开发和编程效率远远远远大于动态语言Feature 提供的编程效率和开发效率  
    
 *  2。我之前说的一个[大的.NET平台关的问题][.NET] －.NET Framework的一个优点也渐渐成为它可能的一个缺点，那就是除了C\#之外，VB、J\#甚至动态语言的Iron Python .NET Framework都要支持，以Anders Hejlsberg的智慧和能力，再开发一个动态语言不是没有可能，但是对于整个多种语言的支持，多个版本的策略方面，单纯地拥抱动态语言是不现实的。而Ruby/Python语言的创始人没有这个负担和包袱。从另外一个横向的角度来看，无论静态语言、动态语言它们都会遇到data/query integration的问题。Anders Hejlsberg似乎试图从Framework的角度解决一批静态语言有关动态语言特性的问题，同时也要很好的平衡C\#与VB以及众多.NET Framework编程语言之间的发展空间。改变不会扼杀VB下一个版本的发展，同样也不会强制其他的语言都站在静态语言的一边，我想，这个需要很大的智慧和策略。

显然，目前.NET平台下的开发人员的境遇是静态编程语言和动态语言折衷下最好的一种策略和选择，我想，也是现在所有编程语言中先进性和开发/编程效率都比较高的选择之一。不过，我认为这也可能会引起了纯粹的Dynamic Languages 专家或社区的一些愤怒，因为他们可能认为.NET变相的展现了动态语言的特性，它"表里不一"  
  
当你不盲从和轻信之后，我相信你会正确的迈向下一步－坚持你自己的选择。  
Anders Hejlsberg表示了他的选择和态度；同样很多人崇拜的大师Martin Fowler在最近的文章 [EvaluatingRuby][]也表示出他对Ruby的坚持和态度。什么是你的态度和坚持？另外有趣的是文章引出了相关的一个问题 ["Are you sure you want to be mainstream?"][Are you sure you want to be mainstream]  
  
**Are you sure you want to be mainstream?** 这是让任何技术开发人员和技术投资者头痛和非常容易引起思考的一个问题。如果用这个问题结束有关动态语言和静态语言的争执，我想，最后的问题也许是-你要否能够坚持你自己的选择?

转载于:https://www.cnblogs.com/drunkyong/archive/2006/06/05/418127.html

[Beyond Dynamic Languages]: http://blogs.msdn.com/mattwar/archive/2006/04/28/585910.aspx
[A conversation with Anders Hejlsberg about the May 06 preview of LINQ]: http://weblog.infoworld.com/udell/2006/05/12.html
[.NET]: http://www.dotnettools.org/Blog/article.asp?id=124
[EvaluatingRuby]: http://martinfowler.com/bliki/EvaluatingRuby.html
[Are you sure you want to be mainstream]: http://www.loudthinking.com/arc/000584.html