上次myan说对python的gp技术提不起太大的兴趣但是我觉得python的Mix-in技术可以实现gp功能，而且可以实现的更好

[SnowFalcon]

[cber]

由于python不会，这次准备做个看客:-(

[SnowFalcon]

上次myman对python的GP没有什么兴趣。那我今天就写上一段代码，看看是否能够提起myman的兴趣。
代码很简单用冒泡排序对一组数据进行排序，虽然python有自己的sort函数但是我想自己写一个
可能更加好理解也更加能够提起myman的兴趣
代码如下

class UpSort:
def sort (self,List,CompareFucntion):
"对一个列表依据自定义的比较函数作升排序"
for k in List:
for o in List:
if getattr(self,CompareFucntion )(k,o)==1:
temp=List[List.index(k)]
List[List.index(k)]=o
List[List.index(o)]=temp
class DownSort:
def sort (self,List,CompareFucntion):
"对一个列表依据自定义的比较函数作升排序"
for k in List:
for o in List:
if getattr(self,CompareFucntion )(k,o)==0:
temp=List[List.index(k)]
List[List.index(k)]=o
List[List.index(o)]=temp

class MySort:

def __init__(self):
#定义原始数据
self.li=[5,8,45,2,68,90,12,67,23,89,29,38,0]
def mycmp (self,p,q):
"自定义比较函数"
if p>q:
return 1
else:
return 0

def excuteSort():
#为MySort装配UpSort功能
MySort.__bases__+=(UpSort,)
#生成MySort对象
obj=MySort()
#对原始数据作升排序
obj.sort(obj.li,"mycmp")
print obj.li
#为MySort删除UpSort功能
MySort.__bases__=tuple(list(MySort.__bases__).remove(UpSort))
#为MySort添加DownSort功能
MySort.__bases__+=(DownSort,)
#对原始数据作降排序
obj.sort(obj.li,"mycmp")
print obj.li

if __name__ == "__main__":
#执行程序
excuteSort()

执行结果
[90, 89, 68, 67, 45, 38, 29, 23, 12, 8, 5, 2, 0]
[0, 2, 5, 8, 12, 23, 29, 38, 45, 67, 68, 89, 90]

这段代码可能些的有写罗嗦，其实类MySort可以写一个upcmp和一个downcmp，然后传入sort函数同样可以完成功能我只所以要这些写无非要突出python的Mix_in的特性。在c++或者java中无论你用继承还是用gp一旦类的定义完成将不可能更改它的自己的语义，也就是说他们是静态语义的

譬如 用gp c++这样写
template <class T>

class DownSort {

DownSort()
{
..........
}
};

template <class T>

class UpSort {

UpSort()
{
..........
}
};


DownSort<char*> Ds;
Ds.DownSort()
UpSort<char*> Us;
Us.DownSort()

class DownSort {

DownSort()
{
..........
}
};



class UpSort {

UpSort()
{
..........
}
};

如果用继承
Class Sort :public DownSort,UpSort
{

}


但是在PYTHON中间的实现完全靠PYTHON的Mix_in.MySort类一开始没有任何SORT的功能，当我用Mix_in特性为MYSORT上加上一个DOWNSORT然后生成的对象就具有DOWNSORT功能，当我把DOWNSORT卸载掉然后加入UPSORT功能它又能加上UPSORT功能。这样的Mix_in的特性当然在C++或者JAVA中都可以用继承来实现但是继承就带来了结构上的臃肿和冗余，可能我要DOWNSORT而不要UPSORT的时候在C++或者JAVA中无论如何都要为一个类定义两种功能而PYTHON你可以随时装配。PYTHON就好比是一个可拆卸的自行车，用GP的思想实现各种各样的算法然后用过Mix_in特性装配到你需要的地方。而c++或者java只能是要多少装多少的重型卡车。PYTHON及能够实GP的现数据与算法的分离又降低了继承的层次性。
另外Python的动态语义特性能够比c++的函数指针能更好的处理gp中的抽象。
在sort函数中python通过系统函数getattr的来识别由CompareFucntion传入的函数字符串比如我传入"mycmp"然后getattr就能够得到mycmp的运行实例后面加两个参数就能够正确的运行函数
def sort (self,List,CompareFucntion):
"对一个列表依据自定义的比较函数作升排序"
for k in List:
for o in List:
if getattr(self,CompareFucntion )(k,o)==1:
在stl中相同的功能是这样处理的
sort(vectro.being(),vector.end(),mycmp)
他通过函数指针来处理
这样做的最大的好处在于可以避免冗长的switch case或者if else语句

另外python同样可以模拟c++的stl譬如我把上面的程序改成如下的
方式和c++中的一样除了没有用template以外
def sort (List,CompareFucntion):
"对一个列表依据自定义的比较函数作升排序"
for k in List[:]:
for o in List[:]:
if apply(CompareFucntion,(k,o))==0:
temp=k
List[List.index(o)]=temp
List[List.index(k)]=o


def upcmp(p,q):
"自定义比较函数"
if p>=q:
return 1
else:
return 0

def downcmp(p,q):
"自定义比较函数"
if p>=q:
return 0
else:
return 1


def excuteSort():
li=[5,8,45,2,68,90,12,67,23,89,29,38,0]
sort(li,upcmp)
print li
sort(li,downcmp)
print li

if __name__ == "__main__":
#执行程序
excuteSort()

[eternalee]

看看

[SnowFalcon]

如果说到效率，那么PYTHON的一个考虑重点就在于效率。然而它提高效率的方法并不和C/C++和JAVA相类似。对于PYTHON来说效率恐怕不是问题，至少不会比C慢。

[SnowFalcon]

另外，既然认为GP是一种编程方式或者编程思想，那么我们就应该允许它用不同的方式去实现他。
不必拘泥于C/C++还是PYTHON是TEMPLATE技术还是MIX_IN技术。问题是从ARTS的角度那种实现更加优美从utility上来说那种更加实用?
PYTHON的高效是公认的，如果说从那些效率较为严格的领域，比如数值计算，三维图形(例如OPENGL)，图像处理，大容量的CGI/WEB网关都能胜任.当然如果你要比10的几次方循环谁来的快
那么PYTHON也不会输给C/C++.
另外效率绝大多数不是取决于程序本身而是取决于编程人员的设计，编码，TUNING等等各种问题.
我以前专门作过C和JAVA的PERFORMANCE TUNING，我甚至碰到过有的人写出的C程序比JAVA还跑的慢。

[myan]

to SnowFalcon:
谢谢你特意为我的一句话写了这么多材料 :-)

其实如果谈到兴趣，我本人对于Python也非常感兴趣。谁让Bruce Eckel说Python应该成为每个人都学会的语言呢？不过学习还没有开始。（书倒是买了两本，兵马未动，粮草先行）所以对于你提供的代码，看了个半懂。凭着我的半懂，我明白了你对于Python的GP如此欣赏的理由。说实在的，我也挺喜欢这种做法。所以如果你希望我对Python的GP感起兴趣，我很高兴地告诉你，你的目的达到了。

不过也是凭着半懂，我觉得Python的GP跟STL，还是存在着很大的不同，基本思想是不同的。因此，我继续保留我的另一个观点，就是我认为，开拓GP发展之路的主战场在C++这一边。由于我现在工作非常紧张（要是完不成任务，那就太没有面子了，更别提可能有的奖金 :-( ), 所以恕我不能就这个问题与你展开深入的讨论。希望过一段时间有空了，能再聊聊。

[myan]

投桃报李，我也贴出一段bubble sort程序，是在STL框架中的实现。

#include <algorithm>
#include <iostream>
#include <vector>
#include <iterator>
#include <functional>

using std::vector;
using std::sort;
using std::copy;
using std::swap;
using std::ostream_iterator;
using std::greater;
using std::less;
using std::iterator_traits;

using std::cout;
using std::endl;

//prior是获取单向迭代器下一个位置的函数，标准库中没有，
//但是已被纳入建议，下一版C++标准当中将会成为标准函数
template <class Iter>
inline Iter prior(Iter i)
{
return ++i;
}

//通用的bubble_sort
template <class ForwardIter, class Compare>
void bubble_sort(ForwardIter first, ForwardIter last, Compare cmp)
{
bool changed = true;
ForwardIter end = last;
ForwardIter i, j;

while (changed) {
changed = false;
i = first; j = prior(i);
if (j == end) break;

while (j != end) {
if (cmp(*j, *i)) {
swap(*i, *j);
changed = true;
}
++i; ++j;
}
end = i; // 最大(小)元素已经在最后面，所以可以缩小搜查范围
}
}

template <class ForwardIter>
inline void bubble_sort(ForwardIter first, ForwardIter last)
{
typedef typename iterator_traits<ForwardIter>::value_type T;
bubble_sort(first, last, less<T>());
}


int main(int argc, char* argv[])
{
int a[10] = {4, 76, 12, 3, 7, 222, 65, 73, 36, 91};
vector<int> ia, ib;
ia.assign(a, a + 10);
ib.assign(ia.begin(), ia.end());

copy(ia.begin(), ia.end(), ostream_iterator<int>(cout, "\t"));
cout << endl;
bubble_sort(ia.begin(), ia.end());
copy(ia.begin(), ia.end(), ostream_iterator<int>(cout, "\t"));
cout << endl;
bubble_sort(ib.begin(), ib.end(), greater<int>());
copy(ib.begin(), ib.end(), ostream_iterator<int>(cout, "\t"));
cout << endl;
return 0;
}

[SnowFalcon]

谢谢myman
有没有qq号马或者email便于我们联系
你在上海么？
如果在上海也可以给电话
空的时候我们电话里聊

[myan]

可惜我在北京，不在上海。我的email是[e-mail]，刚到联想三个月，目前是底层程序员，为Pocket PC写Win32 API程序，在项目里偷偷用一点STL，不过好像同事中间没人可以交流。Python已经移植到了WinCE平台上，可惜我没有for CE的Python, 否则早就开始学习Python了。

欢迎来信交流思想。

[SnowFalcon]

up wait myman

[SnowFalcon]

有for palm得python，for ce也有http://starship.python.net/crew/mhammond/ce/
去看看

[tangtao]

呵呵，我也来凑个热闹！！
我对python只是略知一二（看过一本语言入门）。
不可否认，python是我见过的最好的脚本语言，他的语法、语言定义以及对OO的支持比以前的脚本语言要完善不少。但我仍然认为这种利用脚本语言的动态执行语句的方式来模拟GP和C++的GP没什么可比性。脚本语言的动态语义这个概念本身并不新颖，以前的脚本大多也支持（如php,javascript,甚至更远点的foxbase）。利用这个语言特性可以实现比静态语言灵活得多的功能，但是他的效率肯定不会高到哪儿去。
C++的GP对效率的考虑恐怕是第一位的。所以我认为C++的GP和python这类脚本语言的模拟GP确实没有可比较的价值。

[babysloth]

不管怎么说，得先把别人名字写对，明明是myan偏写个myman，就像好好的GP这只老虎被画成了……

[ripper]

讨论一下，照tangtao(skywalker)的说法要支持那些特性才算支持OO呢？C＋＋支不支持OO呢？或者说是“更加OO”的java才算支持OO？

OO是interface，要靠不同的语言去实现，他们的实现也不完全一样。GP是concept，也应该有不同的实现吧。

[SnowFalcon]

我的理解是gp应该是对目前oo模型的一种修正或者说是加强但绝对不是oo的衍生物。由于oo本身的定义上的缺陷，但是没有强有力的工具去解决他。因此目前的绝大多数oo模型已经走到了一个奇怪的方向越来越偏离我们现实世界的模型和我们通常思考问题的方法。而GP正好能够解决这种缺陷把oo从新带回原本想要实现的初衷。至于详细的情况，我还正在和myan讨论有结果以后我整理
tangtao你的名字和我以前一个网友很像也是c++的专家以前经常在mirc出没。
编译型语言和解释型的语言往往是怎么看的问题是怎么去看平台的问题。如果把OS看作平台
那么c/c++就是解释型的二进制码就是类似java的bytecode。如果把vm看成平台那么解释型语言就是编译语言。而且现在的os和vm已经在逐渐趋于结合，.Net就是一个例子。vb,python，perl乃至java都已经迁移到了os。到了那个时候你能够说在.Net上的c不是解释
的吗？vb不是编译的吗？据我的一个参加.Net开发的朋友说他们内部已经在CLR中加入了template的功能也就是说vb perl都能够使用tempalte，但是问题是从市场角度看vb perl的程序员是否能够接受的问题。所以什么叫gp与编译和解释并没有关系，采不采用template只不过是这种语言的使用者是否能接受的问题。
而且编译期完成类型的确定和检测不一定是非要template不可,com中的varaint是一个巨大的union可是他也能实现编译期的确定和检测.甚至可以把variant扩展到对象或者函数一级照样
可以实现template的功能.

[SnowFalcon]

Sorry myan(现在对了么？-:) )
GP非要template么？离开了template GP就不能存活？
如果回答是"对"的话，那我希望有一个恰当的理由而不是说不用template写gp就不舒服，template的语法本来就很复杂很难令人舒服。

[SnowFalcon]

另外Python从2.2开始已经开始支持Iterator和Adaptor，可以到www.python.org上去看看

[tangtao]

可能我的观点有些偏激。
但我坚持认为由现在C++社群所鼓吹的GP思想只对编译型语言有着重大意义。要在编译期完成类型的确定和检测，并支持template、template argument deduction、specialization以及运算符重载，只有一门语言支持以上这些，我才觉得它支持GP。

[plpliuly]

严格的讲：解释型语言和编译型语言有着本质的区别。解释型语言是解释器边解释边执行，而编译型语言是将代码编译成目标代码，然后执行。
希望SnowFalcon不是基于哲学来讲这个概念，那我就当我什么也没说。

[ripper]

那么‘java’＋‘x86平台上的jvm’‘和C＋＋’＋‘任何x86平台’的oo那？那个更oo？

我想运行在jvm和x86cpu的不同对语言的影响不会波及到oo与否那么高的层面