我眼中的Python

我眼中的Python

python这种编程语言我很早就听说它了，早在1998年，我在玩Linux的时候，就接触过它，但是我对python的印象仅仅停留在它是一种流行的面向对象的脚本语言的认识上。

zope，基于python的app server，早在2000年我就已经对它如雷贯耳了，但是我对zope的印象仅仅停留在它是一种类似Apache HTTPD Server，AOL Server之类的web server上。

今年ozzzzzz多次向我提到python和zope，听得我耳朵都起了老茧了，dlee又建议我开设python版面，虽然我没有答应，但是架不住朋友们的左劝右劝，终究对python这门语言有了好奇心。

几天前，当我漫不经心的浏览了python和zope的网站之后，我突然有了一种“众里寻它千百度，那人却在灯火阑珊处”的感觉，悔不迭错过了那么多次相逢的机会。

对于软件开发，我和ozzzzzz有一个共识，就是脚本解释弱类型语言在开发效率上远远超过编译强类型语言，从软件开发角度来说，脚本语言具备天然的开发效率上的优势，这是由语言的内在属性决定的。

例如我们可以比较一下Web编程使用PHP和Servlet/JSP，比较一下Windows桌面应用使用VB和VC/Delphi，比较一下Unix环境下面Shell和C/Java，比较一下数据库环境下面的PL/SQL和JDBC/SQLJ。

我虽然使用Java开发软件已经有5年的历史了，但是能不用Java的时候，我一定不会用Java的。如果搭建一个小型的网站，我一定选择PHP而不是Java；如果针对数据库的小型编程，我一定使用PL/SQL而不是Java；如果是桌面应用，我一定选择VB而不是Java；如果是Unix环境我宁愿选择shell，perl甚至PHP，而不是Java。

做为一种严谨的，编译式的，面向对象语言，Java总是给我一种须正襟危坐，须一板一眼的按照OOAD的原则编程，才敢在键盘上敲下字符的感觉。即使编写一个最小规模的程序，我也不能够接受把所有的code塞到main里面的做法。Java似乎以不怒自威的威严使我不敢随意编码，不敢玷污Java的严谨。于是我即使写一个很简单的JDBC程序，也要一板一眼的try catch finally，一层层的处理Connection，PreparedStatement和ResultSet。

诚然，如果开发规模比较大的项目，或者开发自有的软件产品，必须应该按照严谨的方式，此时Java也是最适合的语言。但是我不想活的那么累，很多人也不想活的那么累，于是大家都怀念起来脚本语言的好来。对于小规模的应用，使用脚本语言快速简单完成的事情，当你使用Java的时候，你陷入了过多的层层代码包围中去。于是groovy出现了，bean shell出现了。大家终于明白，编译语言不是软件开发的全部，脚本语言才是最适合程序员的语言。

我喜欢脚本语言，喜欢的没边，Java是我的职业，但是我从来都没有在内心深处喜欢过它的语法，我更加讨厌C++变本加厉的复杂。我钟爱的语言包括小学就接触的BASIC和Logo，毕业以后才掌握的Unix Shell和PHP，Perl，PL/SQL。几乎我接触过的每种脚本语言，我都有浓厚的兴趣和感情，除了VBA是一个例外。

看看Java里面长长的对象，方法和属性命名，看看Java编程冗长的调用语句和愚蠢的对象赋值和经常长达几十行的getter/setter，我会时不时从心底泛起恶心的感觉，虽然我经常也是这种恶心感觉的制造者。但是恶心归恶心，我知道Java有它不可取代的作用，PHP有它无法弥补的缺陷。大部分脚本语言，包括perl，PHP，PL/SQL，VBA都不是真正意义上的面向对象编程语言，即使包括了部分面向对象语言的特性，这注定了脚本语言不能够承担大型项目的开发，甚至也不能够充当良好的可复用的组件存在。

所以我很遗憾，我欣赏PHP脚本语言的开发效率，我也欣赏Java的面向对象的能力，我欣赏PHP的低部署成本高可靠运行，我也欣赏Java App Server带来的开发复杂运算的强大能力，但是鱼与熊掌不可得兼。

直到我看到了python和zope，我终于找到了梦寐以求的东西，兼有脚本语言开发的高效率，兼有低部署成本的易用性，同时又有完备的面向对象的强大支撑能力，同时又具备完善的强大的app server支持。最令我生气的还是plone，这个运行在zope之上的软件，你可以称之为portal，或者称之为cms，或者其他的什么名词，但是我知道它几乎可以实现任何网站想要实现的功能。默认安装下，这个东西很像confluence，一个Java的商业的cms，但是比confluence功能强大的太多，可定制性，可开发性又强的太多了。plone在默认安装情况下你就可以把它当做cms来用，比较类似***nuke类软件(PHPNuke, PostNuke, JBossNuke,...)，通过插件的扩展，你可以让plone里面集成了forum，blog，wiki的功能，再加上plone本来就支持的WebDAV，功能强大的基于文档的权限控制，多用户多组的管理，你可以在很短的时间内实现一个全功能的门户网站。可笑的是，我从去年到今年一直在考虑把JavaEye建设成为一个集成forum，blog，wiki，cms功能的网站，甚至雄心壮志的想要做一个这么的软件产品来，但是现在我发现plone已经漂亮的实现了这一切，最令我沮丧的是，ozzzzzz在听过我的软件产品计划之后提出一个用关键词来组织网站内容的设想，结果我发现plone已经这样做了，我能说的只有惭愧！

我只能感叹自己没有在一年之前就发现plone，否则的话现在的JavaEye将完整的使用plone来架设。更令我惭愧的是，当我刚刚意识到zope/plone的价值的时候，上海已经有人成立了专业的zope/plone解决方案的软件厂商，并且拿下了好几个大型的客户，(http://www.zopechina.com)。有时候我们真的不能把眼睛盲目的盯着大厂商强行推广的标准了，应该好好的审视自己真正需要的是什么，并且围绕它构建自己的核心竞争力，否则我们只有永远做IT行业食物链最底层的命运。

ozzzzzz曾经对我说，zope是B/S应用中的VB，快速原型开发中小型企业应用的最佳武器，我现在真切的理解了他的话。我觉得我们确实不能够眼睛光盯着Java/C#不放，也应该了解一下zope/plone，它应该成为中小型企业应用，特别是基于文档管理的企业应用的最重要的解决方案。

zope/plone虽然很好，但是我知道它不会如Java/J2EE，C#/dotnet那样在国内成为一种主流的软件开发解决方案。原因就在于国内的软件开发行业长期处于国际分工产业链的底层，缺乏创新意识和开拓的精神，而往往满足于跟随跨国公司的标准，啃啃人家剩下的肉骨头。位于食物链顶层的厂商，例如MS，IBM，Sun，BEA，CA，Oracle等等，争夺的是标准。他们是规则的制订者，制订好了规则，放大家进场，他们负责收费，钱收的差不多了的时候，他们又重新竞争，制订新一轮的规则，继续坐地收费。很多时候，市场的真实需求并没有被真实的体现，真实的需求被顶级厂商掩盖了。他们创造了一个市场需求，有了市场需求，就有钱赚，赚的差不多了，就摧毁这个市场，然后创造下一个市场需求。因此本质上来说，IT行业就是几个寡头在博弈，不管谁赢谁输，我们都是输家，我们只是人家的筹码。大家可以回顾一下这些年软件技术发展的历程，寡头厂商制造了EJB市场赚大发了，寡头厂商了制造了ERP市场赚大发了，寡头厂商继续在制造着SOA，等着继续收钱。我们不能够被满天飞的技术迷惑了，我们不能被人卖了还替人家数钱。

所以多多关注一下我们真正需要的技术吧。

呵呵。同感同感。
我一般写小东西也不喜欢用java，太累。拿python，ruby，perl写挺好的。
不过说实话我不是很清楚python这种动态类型语言的高开发效率是否来自动态类型还是这些语言的自身设计。
如果拿它们和支持type inference的静态类型语言（如ocaml）比又如何呢？
smalltalk也是动态类型，但是并没有python, ruby那么流行。

对了，java的getter/setter，你是不是指java bean？说实话不觉的这是java语言的问题，只不过java bean的制定死板了一些而已。

写小东西我也用java，我觉得这不是java的问题，是你能不能接受哪种写法的问题，我看了有些号称写的非常经典的php页面动则上1000行，实在有些乱。

java设计的初衷不用理会，他是OO语言也不用理会，我怎么方便怎么写，小程序直接在jsp中看见sql也没什么，对于需求经常变动的程序我只对jdbc做最简单的包装。

ajoo 6：00就起床上网了？。。。。

jbaggio:  //hand!  java也不是一定只能按规矩用的。

robbin:我发现你特别适合向杂志投稿，就是那种鼓吹某种技术的文章，读了总是让人很心动。介绍Python的文章我也读了不少了，就你这篇，让我颇有了一点真的去试一试的想法:D

庄表伟
python根本就不需要学习，很多国外的人都是用1个小时左右学完这个语言的。唯一的让c体系下的程序员感到别扭的是python用缩进来表示语言块。
真正需要学习的是zope这个东西。

jbaggio
ajoo在北美。

不太认同这句话，zope还是倾向与文档性的，早期或现在，zope 都被视为cms,在很多基于数据库应用的b/s应用中还是不太适合的

有一段时间内我非常喜欢python,在asp中使用python是种非常有意思的体验， asp的许多缺点好像都不存在了，可是，由于调用com速度太慢，最后还是放弃

语法倒是可能很快学会，但是api熟悉就需要过程了。可以肯定的是，我用java搞完肯定更快。

好久没来，发现变化真大。

to o6z：
自从那天被你和陈岩洗了一下脑袋，人就俗气了很多，好多技术都麻木了，以前热衷与表示层得那些冬冬，都懒得去看，理由就是我看不见好处，与此同时我花了更多得时间。就flex让我孜孜以求，我相信它是一个能让webapp产生质变的技术，昨天搞了一晚上没有弄到flex builder的d版，很是不爽，打算先忍着手写脚本。

我以前和robbin说，我喜欢ms的开发模式，但只能在java上开发，毕竟人在曹营。

顺便说一下，以前看flex的白皮书，上面写的运行结构中，flex运行时有个服务器层面，我还写了帖子说，flex runtime server要钱怕是需要一个普及的过程。后来一试，那个runtime server是个逻辑概念，就是一些dtd和jar。可以直接跑在sevlet容器上，那样非合法使用就会方便许多，普及就很容易了。

robbin对上面的话，闭上一只眼睛好了。

Python这东西么，动态性有利有弊,利大于弊。
我现在倒是希望它在接口签名能加上一些静态检查，否则太容易出错，而且有些代码有Badsmell之嫌。
例如这样的代码

class A:
   def do(self);:
          print a
class B:
    def do1(self);:
          print b
class C:
    def do(self);:
          print c
def doSomething(xx);:
          xx.do();

因为现在Python 无法在签名doSomething上做类型检查
所以对这种代码
doSomething(C())
要么到处try.....Exception
要么

def doSomething(xx);:
      if (type(xx);==A); and (type(xx);==B);
              xx.do();

这明显和open-close原则相违背。这种情况在C++可以完全避免，在Java中大部分可以避免，可是在Python里绝对无法避免。3年前我看到过一份Rossum 在Python conference 2001上的slides，他提到过python Static Typing的问题，甚至他在python中提出了类似C++template那种概念。而且2年前SIGs里面也有一个小组专门研究Static Typing的问题，但是最终这个小组在2002年秋关闭了(不过在www.python.org的Retired Sigs上应该还有一个这个小组的relic).原因是这种想法受到比较多的反对声音，很多人希望Static typing是一个optional的syntax sugar，而不是一个语法上的必要元素。现在很多人包括Rossum都认为用Document String 来实现Static typing更好一些。Document string有些类似于Java中的annotation。所以我希望将来的Python至少应该有一种optional得机制可以为必要的接口签名加上类型检查。不过你可以去浏览一下Python Enhancement Proposals，目前还找不到这个提案的影子。想来要Python社区接受这样一种特性还是需要花一些时间的。

python中国好像用的少啊，资源，服务，老板的喜好，都没跟上，单单说一种语言有多好，怎么评定呢？比如，我要用python，别人不会，我一走，程序没有人维护了，谁都不乐意，所以最好用扫大街的都会的东西写，这样大家才放心。。。

如果没有质变的东西产生，我会原因用以后的技术解决问题，显得有些不求上进的样子。。。。。