脚本不脚本

    最近在看Python,可惜前有古人,后面也想必会有一堆来者,难免不和以前喜爱的JavaScript,C#比较一番.于是遂有此篇.各位看官,您只管一眼扫去,切莫往心里去,我不能误这个子弟.

 "Lambda"

    这里说的Lambda统指一切能够作为"参数传递的'函数'".这里函数还打了一对单引号,因为C#对应的是Delegate原因

    JavaScript: 无法让人释怀的First Class type. 弱类型, First Class对象,正如引用里的链接回答的:"能够从函数中返回,能够传递给函数,能够在运行时构造".而JavaScript相较Python的就是拥有多行执行,相对来说容量比较"大", 缺点也不是没有, 引用对象的绑定依据环境而变化,不过这也是脚本环境的通病哈,这时就需要构造一个闭包环境来帮助我们帮定相应的引用对象. 当然还有一个是关键字冗余,写多了难免觉得有些多余.

var divs = $("div");
for(var i = divs.length; i > 0; i--) {
    divs[i].click(
function(){
        alert(divs[i]); 
//also alert(this)
    }
}

 

 

    Python: 相对来说只能执行一行代码,自动返回,不需要return关键字.

    C#: C# 1.0给出的方案是delegate ,让delegate作为函数的包装,在方法中传递. 随后C# 2.0的匿名函数就已经很相似了, C# 3.0给出了满意的答案,一个"=>"进一步简化了delegate关键字冗余,而且随之而来的匿名类型,Linq将生产力推向一个高峰.

 

Functional Programming

    注意,这里所指"函数编程"不是在讨如如何在这三门语言里进行"函数化"代码的编写,而是记录一些三门语言对于函数式编程提供的一些类库,辅助函数等软环境.老赵的引文编程语言的发展趋势及未来方向(3):函数式编程  大家可以前去看看. 函数式编程相对于命令式编程,命令式处理只要包含几个分支判断,循环处理,重在如何解决问题. 而函数式则不同,重在解决什么问题.

    JavaScript: 提供了强大的元编程能力, 无论是first class的function,还是函数对象的toString方法,都为函数式编程提供了基础,而函数式编程则又带来了诸多优点.二者日相彰益.不过一些基础设施明显不足,没有提供一个良好的可枚举对象方案,对集合对象的操作倍感乏力.

Array.prototype.map = function(func) {
    
for(var i = this.length; i > 0; i--) {
        func(
this[i]);
    }
}

 

    Python: 完美的函数式编程,无论是map, zip 等等各种内置函数,还是各类可枚举类型, 元编程等等都是更胜一酬. 不过代码方面强制缩进作为程序是否正确的标准, 代码好看了,程序却显得有些古板, 不个性(恩恩,个性)

 import sys,  operator

= range(5)
map(
lambda x: sys.stdout.write(x), a)
reduce(operator.add, a)

 

    C#: 不提1.0,2.0. C# 3.0 有点老树新开, 加入F# 后,C#的函数化跟着也上升好几个档次, 相较于前两者的弱类型脚本语言,强类型的C#肯向脚本化靠拢,而且提供了一个不错的脚本化环境. LINQ 为C# 对集合的操作提供了强大的增益(相对于1.0, 2.0).

 

 模式

    我们都知道设计模式为我们要解决的问题提供了成熟的解决方案,模式已经或多或少的成为了我们开发的必需品.

    JavaScript: JavaScript的原型链不就是职责链的完美实现么.

 代码

var A = function(){ 
            
this.helloA = function() {
                              alert(
"Hello A");
              };
         },
    B 
= function(){
          
this.onlyB = function(x) { 
                      alert(x);
          }
     };
B.prototype 
= new A();
= new B();
a.helloA();

 

 

    Python: yield 实现了枚举器,各个可枚举对象同样都是如此,装饰器, 模块实现了单例, 继承方式又有点像原型链(__metaclass__属性).设计模式可谓在Python中发挥的淋漓尽致.

    C#:  Event 实现了监听者模式, IEnumerable 枚举对象...

    在语言的层次上是否需要这么多的"模式"作为标准还没有定论,不过可以明确的是越来越多内置的"模式"为我们的开发极大的带来了便捷,这也是各位能够感同身受的.

 

    好了,各位看官,我将三门语言从三个语言的角度谈了一点自己的想法,这三个角度不全面,相反,还有些片面,不过,这里是我个人给出的一个答案,而且还不是标准的.您肯定还有一些不吐不快的,能不能拿出来一块分享呢?

    注:这里只是比较语言的区别,并没有优劣,他们各有千秋,python和C#不会跑到客户端去代替JS,C#和python互相也没什么好代替的.所以,在这里声明一下.

posted @ 2011-01-14 12:12  Dreampuf  阅读(2208)  评论(2编辑  收藏  举报