主题：【文摘】SWT……内幕？ -- upson
家园 很多语言都有死灰复燃的可能 其实Ruby也不新，出来也20来年了吧。现在ROR火了，跟着学的人就多了。
所以Judo也有起来的可能，就看能不能与时俱进。一句话，只要活着就有翻本的可能。
家园 judo没可能了 我跟作者谈过，他比较固执，把ruby，grooy什么批评的一无是处。那哥们市场意识不行，一脑子精英想法。
家园 老兄没记错？Ruby的历史应该不长 其实Ruby也不新，出来也20来年了吧。家园 他错，你对 Matz:我开始开发 Ruby 是 1993 年的 2 月 24号， 第一个 Ruby 版本的“Hello world” 运行的时候是同年的夏天。第一个 Alpha 版本发布于1994 年 12 月。
我觉得脚本语言现在最大的问题就是一堆精英都喜欢，但是丝毫没有考虑到一般用户的感受，所以社区都忙着设计新的语法功能或者golf式的框架，但是极少有人去研究各种辅助工具和框架来屏蔽普通开发人员的应用曲线(不是学习曲线），这点是java成功的地方。
家园 请教一下动态语言和静态语言的区别 核心区别到底是什么呢？难道仅仅是定义数据类型时候的不用自己写清楚吗？还有哪些区别呢？仅仅因为这个区别就导致难以大规模协同开发企业级框架吗？我觉得不至于。
浪费您一点时间还请指教一下，谢谢！
家园 不止这么简单 因为类型不是预先知道的，意味着无法做编译时检查，所以ide的自动化实现难度很高，同时比较难开发一些工具做refactor，profile和一些相关维护工作，而这些要求在大规模项目开发里又是必须的，如果不借助工具，对新手来说是相当麻烦的事情。
另外动态语言的类型动态化不能简单理解为需要先申明再使用这样的概念，类型的动态化，可以更加容易的实现一些相当复杂的功能，比如python，连类的定义都是可以动态的做出来的。而现在流行的meta 编程，aop，函数式编程，web service等等，在动态语言里面，因为类型动态化的因素，都更加容易实现。 这样的灵活性，带来开发效率改善的同时，对语言的编写者有更高的要求，新手很容易制造问题或者引入大量潜在的问题，而又因为缺少profile等分析工具，不能很容易的查找问题。虽然引入tdd这样模式可以尽可能克服一些问题，但是对于一个团队来说，毕竟需要时间。动态语言因为自身的特性，不容易象java那样规范的写代码，流水制造，千人一面，在缺少有效工具前，这是我认为不太适合做大规模协同开发的原因。
当然我这个前提是假定在人力资源比较紧张的情况下，越是上规模的项目新手越多，如果有足够的资源和培训，就不是问题了。比如现在很多大牛依然用编辑器+宏做开发，这些问题在人家来看，根本不是问题。我没正式使用脚本语言大规模开发过项目，这是从我个人编写一些小工具时碰到问题和一些java程序员转做ror提出的一些看法。
其实前2年也有朋友批评我现在做事太依赖于工具，但是立场不同，他是从资深程序员的角度考虑问题，我是从项目管理者和组织者的角度看问题，能用工具解决的，我绝对不会放给人做。而且因为工具帮助，其实脚本语言的开发效率的提高，对我现在来说，看到的不明确。
我最近可能有机会使用脚本语言做某个项目的开发，或者结束以后我会有不同的看法，呵呵。
- 复 不止这么简单
家园 我很赞同老兄对动态语言的见解 我曾经参加做过一个Python项目。规模其实并不大，顶峰时七个程序员。用C实现底层的和对性能影响大的部分，用Python去做Web界面，把各个部分整合到一起。
项目开始之初，Python部份的进度明显快过C部份，但是等到了C部份越过了那道坎，Python难于维护的问题也跟着凸显出来了。到最后，进度上两部份基本打个平手。
而在后期维护和re-factor上，做Python部份就感觉比较吃力。没有编译器做类型检查是动态语言相比静态语言的最大缺陷，在缺少可靠的API文档的情况下，很多时间给浪费了。原来指望程序员遵守一定的命名规则来指明变量和参量的类型，但是没有相应的检查机制（比如code review），又要赶进度，最后反而出现了被参量名误导的情况。
家园 其实靠ut和tdd也可以替代编译时类型检查 但是做到这点对程序员有一定要求，另外refactor和profile这部分的问题没工具始终很头痛。
豆瓣就是用一个人用python来做的，做的也挺好的，脚本语言还是比较依赖于个人能力的。
家园 同意。 UT和TDD的帮助其实不过是提供了一些使用API的例子，只能算不是办法的办法。要是为赶进度而不做API文档，UT和TDD多半也难免被砍。
用动态语言对开发团队的“契合”的要求比较高，大家要是长期共事，看对方的代码还能猜个八九不离十，半道加入的新人就惨了。
