2009/11/26 xrfang <xrfang在gmail.com>:
> 这比喻一半有理。我感觉不妥的地方是拿走路和火车比。应该说是，你手头有一个马达、四个轮子。。。。这些资源，然后和火车比。你的劣势就是一开始要装配
> 车子，当然，你也可以用别人装配好的发动机总成（例如SQLAlchemy），这样你就可以少装一点东西，不过无论如何都是没有火车来的方便。
>
> 但是，有2点考虑：
>
> 1）长远来说自己的车子灵活性大性能高，出了问题自己也可以搞定
> 2）你坐火车的话，你不是乘客，而是列车驾驶员，这样，你要学习怎么开火车，这也是一笔开销。当然对于一个运输公司来说，养一批火车司机比养一批能修小
> 车的自备车驾驶员是要划算一点的。只是，你能经营的可能只是Django线路，或者TurboGears线路，这对公司没有什么，对个人是个选择。
>

今天部门的内部知识分享活动中,刘鑫指出了过往对框架和库对比的问题:
- 混淆了运行期和开发期的不同对象, 进行了不必要的对比
- 库其实都是开发期的代码/dll ... 是不开发者直接面对的
- 框架其实重点是照顾运行期内存对象的,是更加接近用户的
所以,框架多是包装了基些领域知识/经验,形成了内建规范/限制,来确保运行期的对象安定;也从而从整体上降低了应用的开发成本;'

而 web.py 这种更加象库的极轻框架,其实是开发者一伙儿的,
在提供了基础运行期限制后,尽可能的开放开发期限制;
同时,也就没有包含有针对性的领域经验内建,这方面完全丢给了开发者自行决策;
那么,就好比 MFC 和 Notes 的对比了, MFC 一樣可以开发出 Notes 的 clone 来,
但是无法形成基于 Notes 开发的规模效应了,
因为 Notes 包含了 IBM 几十年的领域运营经验...

>
> On 11月26日, 下午4时11分, ubunoon <net...在gmail.com> wrote:
>> 火车的native速度与走路的native速度不是一个等级，自然也就屏蔽了这个规矩带来的不利影响。关于框架，有很多讨论，我在第一次入门MFC的时候，就看到侯先生对于框架的一些摘录与说法，框架，必然限制你进行一系列的扩展或者只能够在某个特殊的地方进行特殊的需求操作，而没有SDK之类直接使用库的快捷性，但框架，也给用户带来更多已经设计和实现的细节处理，从而使得用户摆脱对具体操作的考虑，而集中精神去考虑框架范围下，程序所需要实现的功能。
>>
>> 火车需要铺设轨道，走路，则只需要一条道路就可以，这之间的成本是不一样的，我比较接受MFC中关于学习的一个看法，学些框架，前期的投入是巨大的，曲线是很斗的，一旦学会，游刃有余之时，实现内容便不毫不费事，而学习SDK之类的库，前期学习会非常容易，但是创建成本太高。
>>
>> 2009/11/26 Chen GUO <gcd0...在gmail.com>
>>
>>
>>
>>
>>
>> > 有些“被”规范的东西吧，有它的意义，就好象，走路，什么路都能走，但是开车，只能在平坦的路上走，火车呢，还的要轨道。确实，走路，不受限制，或者说，限制最少，火车确实被限制了，想多转个弯都得坏事，但是从北京走到西藏试试看？还得火车
>> > 框架设计者和使用者，一个是定规矩的，一个是守规矩的，但是要说设计者就怎么怎么理解的深刻，我看也未必
>>
>> > On 11/26/09, 刘鑫 <march....在gmail.com> wrote:
>> > > 2009/11/26 xrfang <xrf...在gmail.com>
>>
>> > >> 嗯，我觉得这种讨论是蛮有意义的。我完全明白Z大说的公司环境下的决策因素。我也完全明白高人们对各种框架比较淡泊的态度，因为他们已经摸透了诸多框架
>> > >> 的"道"。我更明白各种框架的拥趸为什么会"誓死捍卫"他们的框架--因为他们投入太多的心血了。在一个公司环境下，选定一个框架非常有必要，因为这样
>> > >> 可以简化沟通、简化工作。当然，这里的选择就是哪个框架成熟、用的人多（那么就更容易招聘到好的工程师）。
>>
>> > >> 可是，我对建筑（水利）和IT项目的比喻却心存疑虑。我感觉IT项目和别的项目不同。比如建筑项目，工程师和建筑师是截然不同的角色，虽然建筑师也是要
>> > >> 懂力学的。IT项目虽然也"应该"这样，但现实中却...... 另外，我在反对"框架"的同时却非常拥护"库"或者"模块"。比如
>> > >> SQLAlchemy，可以用于webpy，也可以用于很多其他框架。SQLAlchemy是一个库，而不是一个框架。思考一下"库"对外界的接口、框
>> > >> 架对外界的接口，我们会发现，形形色色的库，他们的接口非常类似，不外乎就是函数、类、变量...更底层的说，类也没有了，就是一个"代码快的入口
>> > >> （entry point）"。这些概念是有史以来没怎么变化过的。Internet RFC这些东西，多少年了，只有增加，也没有什么大的变
>> > >> 化....工程学上的"向下兼容"在这里体现得非常好。而如今，框架漫天飞的年代，大家看看，能不能学了一个Django以后，不用学
>> > >> TurboGears了，只要一本TG参考手册就开始写TG程序？
>>
>> > > 每次看到有人指点江山我就想含笑而过……
>>
>> > > --
>> > > 每一个成功都是不可复制的。
>> > > ……
>>
>> > > 劉鑫
>> > > March.Liu
>>

-- 
http://zoomquiet.org 人生苦短? Pythonic!
金山常年招聘Py/C++人才! http://bit.ly/UoTV 简历直投俺就成;-)