主题：【文摘】SWT……内幕？ -- upson
我对Python比较熟悉，对Ruby不了解。您对这两种动态语言怎么看？
一直都用来做些辅助的小东西。
动态语言相对于静态语言来说，他的优势在于精简和语法上的一些灵活的特殊结构。某位如果有幸维护俺写过的某段so 长的代码的人就会看到俺在注释里面高呼叫，为啥不是python，因为用python做也就几句话完了。但是这也带来一个副作用，就是不够规范，不容易象java那样大规模的协同开发。举个例子，在java 里面，架构搭建好以后，一个大牛和菜鸟写出来的代码不会有太多本质的差别。这就是java语言可以大规模工业化的先天优势(这点c#，c++都有比较大的差距）。
而当初我学习ruby quiz的时候，则发现一个问题，可以有几十种实现，代码风格也千奇古怪的，从所谓一句话的golf风格到死硬的java风格都有，这样易读性和可维护性会是个大问题，特别是大项目和考虑到普遍新手的情况下，也就是说动态语言开发效率的提高，在某些情况下，是以牺牲某些后期的成本为代价的。而现行ide工具的发展，已经可以部分弥补静态语言在编写效率上不足，而动态语言这块，一直缺少优秀的ide支持，打了不少折扣。这一块python相对还好一些，因为语法够简单，又以缩进的方式强制规范了代码。btw， 以我的经验，对于团队开发，代码规范化远远比代码技巧更重要。
python和ruby则是动态语言里面的两个极端。
python足够简单，基本上翻一翻书上手就会，他也不是纯oo的东西，从入门的角度考虑，更容易为人接受，这也是python生命力所在，另外从发展历史看，python相对来说更加成熟，很多问题都已经有了相当成熟的解决方案。python很适合用来编制一些小工具和辅助软件，这样即充分发挥了脚本语言开发效率的优势，又不会产生太多的维护问题。而对于企业级别的应用，python目前在某些方面也有比较成熟的平台可以去推动，比如zope，但是整体来说，因为专业程度比较高，不会是太主流的。而最近受ror刺激，随后虽然也出了些东西，但是缺少天才程序员的推动，没什么大的反响。一句话吧，就是通用的框架级别的东西不够份量，吸引不到太多的眼球，注定只能在某些特殊领域才能发光。
而相对来说ruby就复杂很多，实际我认为从语法上看，ruby的复杂程度要超过java和c#。 ruby的作者本身开发ruby的原因就是因为python太简单，不够pure oo， 所以从头实现了一个相当复杂的脚本语言。ruby充分吸收了python的语法动态方面的特点，又加入一些很好玩的特性，比如 closure这样的东西和某些oo方面的高级特性。但是真正把ruby推到目前这种火热状态下的原因是ror。长期以来java阵营一直缺少一个高效易用的total 方式的企业应用框架，而ms的。net虽然是一个相对易学和相对高效率的开发平台，但是因为封闭性，一直为广大精英阶层和unix阵营所不耻。 ror的成功在于从框架级别去封装应用的复杂性，再充分利用ruby语言动态简洁的特性，就象一颗原子弹空投进入企业应用市场（这块可占了整个软件市场的80%），降低了企业应用开发的门槛，把所有的大傻都振了一边，然后这才有人反应过来，原来非ms的解决方案，也可以做的这么简单高效。这种震撼的2面，一边是吸引了大量的人投入ruby的学习过程，另外一边是java阵营本身开始进行反思，agile迅速成为主流。
但是就我看来，因为ruby语言本身的复杂程度和学习曲线，考虑到可以预计的很长一段时间，软件业仍然无法解决人力资源短缺的问题，这2个因素直接决定了除ror这样良好封装的框架为核心的企业应用以外，短期内ruby很难有更多的机会成为主流的开发语言。我曾经跟某人说过，如果java学不好，就更不用说ruby了，因为更复杂。除非有更多专业性质的成熟框架出现，全面的降低应用开发的门槛。企业市场，相信很长时间内，aigle后的java和。net还会主流很长一段时间。当然借助ror的热风，如果能够吸引到足够多的java 精英转投ruby，未来ruby提早成为主流也为可知。对于精英来说，复杂总是更有趣的东西，所以这个角度看， ruby会更好一点。
ror并不是ruby的成功，而是一种解决问题的思路的成功， 我在某个项目按ror的一些思路和结合java5本身一些特性封装完成的一个框架，在开发效率和易用性方面同样不输给ror（前提是准对当前项目而言）。而java阵营也存在大量的类似开源方案。未来，竞争还会更加复杂。换句话说，如果python社区抢在ror之前推出一个同样级别的应用开发框架， 现在amazon上最热卖的肯定是python。
另外，在没有得到好的商业支持，实现ide级别的refactor ，代码profile等功能之前，动态语言很难大规模进行开发，尤其是大中型项目，很长一段时间内，动态语言还不会成为主流，只会在特点场合适用。动态语言的真正大规模应用，我可能更看好的是一种变通，即groovy（我更喜欢这种c like风格的脚本语言）， jruby这样能整合传统静态语言和动态语言的方式出现，也就是依赖vm的脚本语言。ms也在做同样的努力， jython的原作者早已经完成了。net版本的python，另外还有若干个可以跑在vm上有趣语言。
还可以发现的一个趋势是传统静态语言的大量动态化特性的引入，或者未来，这个分界会越来越模糊。
我已经脱离开发一线一年多了，这一年可能有大量的新东西出来，以前有个上海人写过一个judo的脚本语言，号称第一种4g 的脚本语言，刚出来也很吸引眼球，归根于商业和应用上缺乏操作，现在已经很少人知道这东西了。所以趋势，还是很难说。
核心区别到底是什么呢？难道仅仅是定义数据类型时候的不用自己写清楚吗？还有哪些区别呢？仅仅因为这个区别就导致难以大规模协同开发企业级框架吗？我觉得不至于。
浪费您一点时间还请指教一下，谢谢！
真是难以置信。
因为类型不是预先知道的，意味着无法做编译时检查，所以ide的自动化实现难度很高，同时比较难开发一些工具做refactor，profile和一些相关维护工作，而这些要求在大规模项目开发里又是必须的，如果不借助工具，对新手来说是相当麻烦的事情。
另外动态语言的类型动态化不能简单理解为需要先申明再使用这样的概念，类型的动态化，可以更加容易的实现一些相当复杂的功能，比如python，连类的定义都是可以动态的做出来的。而现在流行的meta 编程，aop，函数式编程，web service等等，在动态语言里面，因为类型动态化的因素，都更加容易实现。 这样的灵活性，带来开发效率改善的同时，对语言的编写者有更高的要求，新手很容易制造问题或者引入大量潜在的问题，而又因为缺少profile等分析工具，不能很容易的查找问题。虽然引入tdd这样模式可以尽可能克服一些问题，但是对于一个团队来说，毕竟需要时间。动态语言因为自身的特性，不容易象java那样规范的写代码，流水制造，千人一面，在缺少有效工具前，这是我认为不太适合做大规模协同开发的原因。
当然我这个前提是假定在人力资源比较紧张的情况下，越是上规模的项目新手越多，如果有足够的资源和培训，就不是问题了。比如现在很多大牛依然用编辑器+宏做开发，这些问题在人家来看，根本不是问题。我没正式使用脚本语言大规模开发过项目，这是从我个人编写一些小工具时碰到问题和一些java程序员转做ror提出的一些看法。
其实前2年也有朋友批评我现在做事太依赖于工具，但是立场不同，他是从资深程序员的角度考虑问题，我是从项目管理者和组织者的角度看问题，能用工具解决的，我绝对不会放给人做。而且因为工具帮助，其实脚本语言的开发效率的提高，对我现在来说，看到的不明确。
我最近可能有机会使用脚本语言做某个项目的开发，或者结束以后我会有不同的看法，呵呵。
实际上专业软件，基本都是由具体的专业技术人员开发的。工科生一般都需要掌握2门以上的程序开发语言。
不过对于专业技术人员来说，因为基本素质比较高，使用动态语言应该更有开发效率方面的优势。
我曾经参加做过一个Python项目。规模其实并不大，顶峰时七个程序员。用C实现底层的和对性能影响大的部分，用Python去做Web界面，把各个部分整合到一起。
项目开始之初，Python部份的进度明显快过C部份，但是等到了C部份越过了那道坎，Python难于维护的问题也跟着凸显出来了。到最后，进度上两部份基本打个平手。
而在后期维护和re-factor上，做Python部份就感觉比较吃力。没有编译器做类型检查是动态语言相比静态语言的最大缺陷，在缺少可靠的API文档的情况下，很多时间给浪费了。原来指望程序员遵守一定的命名规则来指明变量和参量的类型，但是没有相应的检查机制（比如code review），又要赶进度，最后反而出现了被参量名误导的情况。
在物理等基础学科研究和金融分析等行业很流行的
只要不是意气用事，不会导致跑题吵架的，争论就会对大家都有好处。
但是做到这点对程序员有一定要求，另外refactor和profile这部分的问题没工具始终很头痛。
豆瓣就是用一个人用python来做的，做的也挺好的，脚本语言还是比较依赖于个人能力的。
UT和TDD的帮助其实不过是提供了一些使用API的例子，只能算不是办法的办法。要是为赶进度而不做API文档，UT和TDD多半也难免被砍。
用动态语言对开发团队的“契合”的要求比较高，大家要是长期共事，看对方的代码还能猜个八九不离十，半道加入的新人就惨了。
我也用Python做过一些程序，当然不是企业级那种规模的。
开发中发现，当超过某个门槛（比如，Class达到一定数量）之后，Python会变得非常难维护，特别是维护别人的代码。一个是因为会
碰到不知道在那里定义的变量，二是以为没有类型检查，会出现一
些莫名奇妙的错误，而最糟糕的是有时候这些错误无法再现，至少
是不知道如何再现。
要是能有本书讲述如何正确的用Python编程就好了。
要是还没人写过，看来是个空白，自己写一本？
其实Ruby也不新，出来也20来年了吧。现在ROR火了，跟着学的人就多了。
所以Judo也有起来的可能，就看能不能与时俱进。一句话，只要活着就有翻本的可能。