主题：【文摘】SWT……内幕？ -- upson

这种书没有个十年八年用Python的实战经验，可难写。

我对Python的认识，只能算皮毛吧，离出书可还差得太远太远了。

好让我们有站在巨人肩膀上的机会。

我跟作者谈过，他比较固执，把ruby，grooy什么批评的一无是处。那哥们市场意识不行，一脑子精英想法。

我觉得脚本语言现在最大的问题就是一堆精英都喜欢，但是丝毫没有考虑到一般用户的感受，所以社区都忙着设计新的语法功能或者golf式的框架，但是极少有人去研究各种辅助工具和框架来屏蔽普通开发人员的应用曲线(不是学习曲线），这点是java成功的地方。

即便是Python，现在感觉也或多或少的在把核心语言本身复杂化。

说到辅助工具和框架，这个应该是FOSS相比于proprietary最弱的地方了。做辅助工具和框架必需有能力和时间去抠细节。没有稳定的资助，FOSS的程序员无法做到这点。

不过有一点,IBM搞swt并非完全出于市场因素,当时的swing确实有一些很难解决的问题,比如它的事件机制.swing和swt的区别本质上就是原生控件与自己绘制控件的区别,这种争论由来已久,从smalltalk开始就有了.只是思路的不同而已.

原生控件就是将主机窗口系统实现的控件诸如按钮,列表框之类的API薄薄封装一下,统一一下,供宿主语言调用,其跨平台的能力,不过就是API级别,说到底,那些控件本来就是由主机窗口系统来实现绘制的,譬如在windows上,就是微软的代码在绘制,而不是swt的,在linux/gtk+ 上则是gtk+在绘制..这样当然就是原生的look and feel了,但是问题是要统一不同风格不同窗口系统的API绝非易事,灵活性也极受限制. 而Swing这样的思路很符合sun的审美哲学,那就是什么都自己来:) 理论上说GUI程序设计,只要你能控制每个像素点的绘制（setpixel()/getpixel())，那么谁都可以实现一个控件系统，swing就是这样的思路，因此当Java2D提供了比较高级的像素绘制能力后，swing就在此基础上得以用“纯Java”实现。。。好处是非常灵活，用swing理论上可以做出任何匪夷所思的外观效果，如果精于计算机图形学，做出比vista/os x 更炫目的东东，我绝对会觉得理所当然。。对你的自由完全没有任何限制。只是这样一来，什么都是自己绘制，自然就不太可能直接获得原生的look and feel了，只能模拟。毕竟，windows 原生应用程序之所以能给你同样的“windows”味道，很大程度上是因为它们用到的大多数公共控件实际都是底层的同一套windows的代码在控制。。。swing这种思路就

完全不一样，它自己绘制。这只是思路的不同，跟是不是Java毫无关系，你把C语言写的gtk+应用移植到windows上去，也会面临同样的问题。

至于孰优孰劣，这个问题仁者见仁智者见智，我就不多废话了

只是swing会给大家造成一些错觉，觉得它太丑陋什么的，这个其实不是事实，它只是一套很简单通用的规范而已，没什么限制，用它来写东西，美，丑，性能都在个人能力。。。

另外，我不太喜欢阴谋论 ：）

关于ruby ,python

恰好我前面几年做过的两个公司，一个是用ror 做web2.0，一个是用zope/plone做内容管理的

对比一下，会有很多有趣的结论

swing当时确实有缺陷，但是这个缺陷并非不可修订，至少从理论上来说，jdk的规范只限制了接口，ibm自己的jdk实现完全可以从底层解决事件问题。而实际上，当年我用oracle和ibm的jdk跑swing应用就是有差别的，oralce某个版本的jdk，一跑某个应用就死机，这说明底层的实现思路是有差异的。而现在的jvm，swing的事件处理接口并没有变化，但是问题已经基本解决了。

ibm从一开始就希望自己能控制java，所以他的websphere只能在他的jdk上跑，这是很bt的事情。

特别是zope能否扩展做一些通用性质的企业应用。