发信人: wintereagle()
整理人: wenbobo(2002-11-26 13:56:33), 站内信件
|
这封我对myan的回信，详细说明了我对gp,oo,开发工具，软件实现的关系。
另外我对c/c++目前的现状发了一顿牢骚，但是没想到后来却被myan说的体无完肤。
梦魇：
你好。收到你的来信已经好几天了，我迟迟没有动笔给你回信。因为我需要更多的时间和
收集更多的资料来理清的思路。
即使是今天我写这封信的时候我对我自己的想法还没有太大的把握。
你上次的来信中具体的描述了GP和Template的实现和优点。你说GP不是oo的补充，我觉得
不正确。但是我以前说GP是oo的补充，也不对。 你在讨论GP的时候将GP和template对编译
器处理的混在一块讨论，把编译器编程的优点赋予了GP而推导出"基于Template的GP更加先
进和优越". 我觉得这样的一种思考方式不正确。你曾经也说过GP不一定要template
来实现。我认为GP是一种设计模式和oo的模式在同一个级别，而编译期处理是一种编程实现
模式。就像我们不能把java中gc这种功能的优点算到java的oo模型上一样。我们只能说java
的gc功能将能够增强java中oo模型的使用性和实用性而不能说由于有了gc所以java的oo更加
优越。
你熟悉karl.Popper的理论，那我想你也应该熟悉karl.Popper的世界3的理论。我有这样
一种猜想就是:我们也可以用世界3的模型来说明软件设计学（但是我这个世界3和Popper的世
界3并不一样)。
世界1:现实世界的需求
世界2：设计模型和模式（例如GPD,OOD,Design Patterns ,等)
世界3:实现模型和模式（例如oop,Template,GC，Mixed_in）
对于世界1我们可以这样来理解，世界1中存在着这样三类元素
1.一系列的基本元素，他们是组成世界1中其他事物的基本元素可以把他们理解成对象。
他们有独立性，独立性可以描述一个基本元素和其他基本元素之间的差别
是A就是非B。如A=Book那A!=Desk。
他们具有衍生性，衍生性可以将符合基本元素特性的一些列事物看作是基本元素的衍生便于
抽象和归类。
A=历史书àA=书
2.相同元素之间的相互作用关系，他们使得相同的基本部件之间的相互作用关系抽象化，成
为构件世界1的又一个基本元素。
他们有对相同的基本元素有广泛的通用性和单一性，如BookNameBySort可是适用任何Book及
其衍生物但是对于Desk和Desk的衍生物却不适用。
3.不同元素之间相互作用关系，他们是使得相对独立的基本元素之间能够互动形成我们
需要的应用。
例如，Book on Desk,
世界2 我们可以这样来理解他们，他们是一系列的描述工具。我们可以用他们来描述世界1中
的三中基本元素便于我们更好得理解世界1。你可以看到世界2中的内容我没有说OO或者GP而
是说GPD(Generic Programming Design),OOD(Object Oriented Design)。
因此我对我上次的观点"GP是OO模型的补充特别是对多继承的补充"持否定的态度。
GPD,OOD仅仅是设计模型和模式的内涵而非就是设计模式和模型这个范畴的本身。
我想更加精确的说GPD是对设计模式和模型的一种补充。
世界2中的描述工具并不一定和世界1中的元素们一一对应。仅仅是我们选用最合适成本最低
的描述的工具来描述世界1。仅有OOD不能够有效的描述完整的世界1，用他来描述元素1OOD非
常适合但是用它来实现世界1中的元素2会出现不必要的冗余，繁琐。仅有GPD也不能够有效的
描述完整的世界1，因为用它来缺乏对世界1中的元素1，3的描述能力。 是不是有了GPD和
OOD就能够完整的描述世界1，我不知道。我只是知道到目前为止只要GPD和OOD就足够描述世
界1了。
世界3，他们是一些列的实现工具。我们可以用这些工具来更具世界2中的描述来近似的实
现世界1的情况。 同样在世界3中，实现工具未必要和世界2中的描述工具一一对应。例如我
们可以用OOD来描述世界1，但是在世界3中我未必要用oop的方式来实现我可以用面向过程的
方法来实现仅仅是用面向过程的方式我要定义更多的数据和结构。选取什么样的工具仅仅依
据实现成本而非实现工具本身。
同样实现世界2中的GPD可以用很多工具来实现，比如Template,oop,Mixed_in等等。
我认为从技术和效率上来说c++的Template和python的Mixed_in显得更为优越或者说的通。
Template，能够比OOP的动态类型鉴定来提供独立的算法模型和更加高效代码。而Mixed_in
从动态改变类的继承树方面降低类层次结构和独立算法模型。用模版Vector<T>可以适用任何
对象，而不必为每个对象都建立Vector算法。用Mixed_in我们可以在任何时候为任何对象继
承Vector类或者删除Vector类。这两种技术有异曲同工之妙。只不过一个可以对c++的编译
器编程，而另外一个是对python的解释器编程。但是从效率上来说Mixed_in还是稍逊一筹。
从经济学的角度或者说从实惠的角度来说，我仍然认为Template不是一个好产品。他也不可
能胜出。我先撤远一点，现在有很多人把混沌和复杂理论搀和到经济学中。他们认为由于人
们的习惯和先前的投入的成本过多会产生”路径依赖”，“网络效应”,”锁定”效应而使得
市场失灵而使得高质量好的产品被淘汰而次一等的产品占领市场。他们经常津津乐道的一个
例子就是VHS录影带和Beta录影带的故事。VHS录影带的录像质量没有Beta的高但是现在市场
上家用的录影带全部是VHS。他们的解释是VHS录影带在投入市场的时候作了更多的广告和市
场推广，而Beta没有。使得用VHS的人越来越多，大家都是采用VHS的录影带和录像机。即使
想用Beta的人也因为他录制的录影带没有办法给周围的人看，所以他们也只好改用VHS。虽然
听起来很有道理，但是这种理论是完全错误的，至少他们所提供的例子是错误的。VHS录音带
之所以被Beta用的广，在于VHS除了录像质量不如Beta以外他能够录制两个小时而Beta最有
45分钟的节目而且价格是Beta的1/8。对于普通家庭来说，录像质量并不是首要的而是能够花
最少的钱能够录制最长的时间。要录制一般的电视节目就必须用去VHS只要一盘带子而Beta要
两盘带子而且要花费比VHS多16倍的价钱。之所以VHS更加能够得到普通消费者的青睐而Beta
只能用于转用于电视台里面录制高清晰的电视节目，是因为从实惠的角度讲VHS 是一个好产
品，而Beta却是一个次等的产品，虽然Beta比VHS有更好的录像质量。
话在说回来从实惠的角度上讲我觉得Template和Beta录音带一样是一个次等的技术。
Template的首要目标是效率其次才是GP编程。但是效率对于一种技术来说仅仅是一个方面
他并不起决定因素。Tempalte的缺点在于语法的复杂性。大多数的用户未必都会性能要求很
高，他们并不是作学术研究的它们需要对口袋里的银子和性能进行衡量。提高性能，必须要
提高成本。这是无可避免的。对于大多数的性能要求不是太高的应用的程序开发（如Desktop
应用），有两种方案一种就是在编码时采用c/c++语言,template但是付出的成本是昂贵的人
工开发周期的延长，得到的结果是实际性能要比用户能够感觉的到的要好，第二种方案是采
用容易语言编码缩短开发周期和人工但是需要付出性能不够高的代价，但是他可以用节约出
来的成本的一部分来把程序优化到用户可接受的程度。最终在性能优化上面两者都提升了成
本，而结果两者得到效果在用户这边看来是没有任何差别的。但是高昂的人工开发商承受不
起，过长的开发周期用户的等待不起。在供需两方面来说牺牲一些性能都是很值得的。市面
上大多数应用例如Mis系统都是如此，甚至大型的商业应用采用Java,perl的也越来越多。另
外高端的应用应该是c/c++的领域但是现在越来越多的用得都不是c/c++方案。如电信行业。
我们公司目前一直在和电信打交道，我们给电信作的方案是100%的pure java.我们了解下来
其中主要的原因在于电信行业竞争越来越激烈，电信提供商如果错过一个业务的发展会丢失
很大一块市场份额。而Java应用的开发要比c/c++节省40%的时间和30%的成本他们电信运营
商宁愿用这些省下来的钱去买高档的服务器也不愿意等5-6个月的开发周期。不仅仅是我们这
样做，连IBM,Lucent目前主推的Call Center或者电信平台都是基于Java的。另外一个高端
领域:Web服务领域c/c++市场在快速的萎缩而性能较低的方案asp,perl,jsp却统治了90%的市
场。
为什么这些年来大家都宁愿舍弃高性能的C/C++而大量采用编程方便但是低效的解决方案。我
想这是应该是c++的设计者应该迫切考虑的问题。因此从我的角度看Template从技术角度来说
是一种创举但是从实惠的角度来说的确是一种次等的技术。
另外在Python中还有一种称为FP的设计方式函数编程(Function Programming)
例如Python中定义了一个函数
map(fuc,List)他的作用是
fuc为一个参数的函数fuc(arg1)比如
Def fuc (arg1)
arg1=arg1+1
List是一个连表[1,2,3,4,5,6,7,8]那么map的作用就是对List进行遍例把每个List的元素
作为参数传入fuc进行运算。得到的结果为[2,3,4,5,6,7,8,9]
类似map的这种函数还有很多比如reduce,filter等等。FP这种东西看着像GP但是感觉上又不
是不知道因该算什么好。
谢谢
Ian.King |
|