ruby的优点和缺点

动态语言的优势
动态语言的优势有很多，归纳起来主要有以下几个方面：

1. 生产力。动态语言在开发效率方面有着无与伦比的优势，这也与动态语言“优化人的时间而不是机器的时间”这个理念相吻合。利用传统的静态语言要开发几周的功能和特性，使用动态语言也许几天甚至几个小时就可以实现。不仅如此，动态语言在开发原型系统和常用工具方面的开发效率也非常高，尤其值得一提的是原型系统。更快地让原型系统运转起来，不仅可以尽早验证一些假设，也能够更好地与迭代开发相结合，更及时地与需求方进行沟通，帮助需求方挖掘和了解自己真正的需求。开发效率可以说是动态语言最为吸引人的地方，这也被认为是将来开发语言的前进方向。这些年随着敏捷开发的盛行，越来越多的开发者意识到，原来动态语言的特性和敏捷开发的价值观也相当契合：缩短反馈时间，对变化的响应能力更强。所以许多动态语言团队选择了敏捷开发的实践来组织团队。我们在实际开发的过程中，以两周为一个迭代周期，基本上1-2个迭代就可以完成一个系统的开发和上线，而原型系统的开发通常能在1-3天内完成。

2. 代码量。曾有报道说，用Ruby on Rails写同样的项目，代码量大概只有Java的1/10。且先不说这个说法是否有夸张的成分，但就实际来看，动态语言的确从代码量上来说，要比 Java/C/C++等传统静态编译型语言要少的多（当然语言的表达能力与动态静态关系并不大，静态函数式语言的表达能力也很强），可能几千行的项目就算得上是个大项目。例如，我们开发的系统中较为复杂的消息网关，生产代码行数大概在7000行左右；而订阅服务系统的生产代码行数不到3000行；借助于Xapian的 Python-bindings，我们的搜索引擎系统代码行数只有800行左右。代码量少的好处非常多：首先，这意味着将来需要花在维护上的代价更低；其次，因为代码少了，犯错误的机会也就少了，因此代码量少还意味着BUG的减少；再次，代码量的减少也有助于优化系统，有句话说的好，“There is no code faster than no code”。开源项目Nebula Device有一个设计哲学，就是“每一次Release要比前一次代码量更少”，窃以为高论也。

3. 测试。因为动态语言很容易实现反射等动态特性（JUnit也是等到Java支持了反射以后才出现的），因此测试也更为容易实现。Python和Ruby的标准库中都带有unittest的框架，这几乎可以让你无成本地使用单元测试来加固代码。因为动态语言本身不具有编译过程，因此犯下某些低级错误的几率大大增加，也为重构带来了重重困难。没有单元测试的重构如同梦魇一般，动态语言尤甚。因此，在开发语言以动态语言为主的开源项目中，单元测试总是占有相当大的比重。还有建议称测试代码与生产代码的比率（Unit Test To Code Ratio）要达到2:1以上。另外，动态语言的测试环境更容易搭建，实现Mock也更为简单。

4. 原生数据结构。现在主流的动态语言多为脚本语言发展而来，而在这些语言中，集合、列表和词典这样的数据结构都是原生的，而静态语言的数据结构往往是通过程序类库来实现的。比如Python就提供了set、tuple、list和dict等原生数据结构，同时还提供了大量操作（如数组分片等），让这些数据结构使用起来非常方便。原生数据结构使得对数据的操控融入到了语言的语法当中，让程序更为易读，这也让基于代码的沟通更为顺畅。

5. 简单易学。动态语言的语法相对简单，学习成本看似也比较低。有人举例说，Python和Ruby写个Hello World只需要一行即可，这是很多静态语言所达不到的（把多行代码写成一行的不算）。当然你可以认为这只不过是句玩笑话，不过单就语法而言，动态语言的学习门槛要比很多静态语言要低的多。可是，开发不仅仅只是语法而已。很多动态语言的初学者，能够用动态语言写一些简单的小程序小工具，却很难构建起庞大复杂的商业系统，究其原因，主要是还是因为系统设计和面向对象的功底欠缺所导致的。如何设计，如何抽象，如何重构，这些能力与语言无关，而是个人的修为。正如陆游所言，“功夫在诗外”，这些能力也不是一朝一夕、通过学学语言就能够轻易练就的。当然，动态语言的各种特性（如Duck Typing）也使得在静态语言中不得不使用的设计模式可以很自然地表达，这些差异也增加了动态语言学习的隐性成本。

不足之处
任何事物都具有两面性，动态语言也不例外，虽然优势显而易见，动态语言的不足之处也有很多。这里列举一些我们在开发过程中所遇到的问题，以及一些初步的解决方案，来供大家参考。

1. 运行效率。运行效率低下使得动态语言饱受诟病。“跑得太慢”这顶帽子已经在动态语言的头上扣了许多年。甚至有Benchmark表明，在某些应用场景下，动态语言的运行效率和C/C++、Java等成熟的静态语言相比，相差数十倍甚至上百倍，这也为动态语言的普及埋下阴影。不少开发者因为运行效率的问题，纷纷表示 “对动态语言很失望”。其实我倒是觉得大可不必纠结在这个问题上，原因有两点。第一，很多动态语言的应用场景使得运行效率的重要程度大大降低。就拿 Ruby on Rails来说，在Web开发这个应用场景里，数据库的响应时间无疑是最大时延，与之相比代码运行时间就微不足道了。而且通过Cache和优化，基本上可以消除代码运行效率低对项目的影响。又如我们的消息网关系统，最耗时的部分就是网络通信和文件I/O，而这两部分动态语言和静态语言相比并无明显劣势，运行效率的问题可以完全忽略。第二，如果遇到很耗CPU或者很耗内存的运算，完全可以通过C/C++实现的扩展来解决。无论是Python还是Ruby，都支持采用C/C++编写扩展。通过这些扩展，可以极大地提高运行效率，从而弥补动态语言在运行效率上的不足。

2. BUG难于发现。动态语言由于没有构建的过程，因此很多错误只有等到运行时才会发现。而这些错误很可能是些低级错误，比如拼写错误、没有import相关的类库，或者括号不匹配等等。如果每次修复这样的BUG都要通过去测试环境中部署来验证的话，则会浪费了大量时间。因此动态语言往往需要充分的自动化测试套件，才能够确保代码基本可用。另外，使用动态语言的时候，一个良好的代码静态检查工具也是很有必要的。它不但可以纠正一些低级错误，而且还可以帮助你发现代码中的Bad Smells，大大提高开发效率。对于Python来说，Pyflakes或Pylint都是不错的选择；而Ruby也有众多工具可供使用。测试充分的代码也更容易重构，在重构动态语言项目时要万分小心，因为动态语言极容易犯错，稍不留意就会引入新的BUG。保持小步前进的步伐，每次修改后都执行测试，最好再通过持续集成环境来帮助发现测试失败的情况，这样重构起来才能得心应手。

3. 专业人员少。不少使用动态语言的公司都会遭遇一个问题，那就是使用动态语言的资深开发人员很少，不但很难招聘到靠谱的员工，核心人员的离队也会对公司造成很大的损失。这是因为完全使用动态语言进行开发的公司少的可怜，只有极少数的开发者能够参与其中并获得相关的开发经验。绝大多数的动态语言使用者还处在爱好者阶段，跟着Tutorials写写Demo，或者随手写个Utils等等。因为高水平的动态语言开发者的确是可遇不可求，因此寻找有经验的开发者也许要花上不少的时间和成本。当团队有了较为有经验的开发者以后，就需要通过内部培训、结对编程等手段，帮助公司里没有经验的开发者迅速积累经验，逐渐成为动态语言方面的靠谱人才。其实，对于动态语言的圈子，还有一个有趣的说法：因为学习动态语言的人往往都是在其他领域有了很深的积累后，在有余力的情况下才接触动态语言的，因此往往相对都比较靠谱，动态语言的圈子反而能够帮助雇主们甄选出一批高素质的开发者。

4. 不够成熟。动态语言的发展历史虽然不比静态语言差到哪里（比如Ruby和Java就同为1995年始创），然而由于其较为小众，因此无论是虚拟机的实现上，语言本身的机制上，还是相关的配套工具上都算不得十分成熟。例如，Ruby虽然以其优美灵活的语法为人所称道，但也因为其虚拟机效率低下和内存泄露问题所为人诟病，使用 Ruby on Rails的网站往往需要加配监控程序，一旦发现某个VM内存超标立刻重启；Python的虚拟机虽然还算稳定，但长久以来一直受GIL（Global Interpreter Lock）问题所困扰，完全无法发挥多核的优势，这在家用PC都早已多核的今天的确是个不小的问题（事实上Ruby也存在GIL问题）。不过，虽然官方实现不够成熟，现在已经有很多逐渐成熟的其他选择可供使用。比如JRuby就充分利用了Java成熟的虚拟机和Ruby优良的语法特性，还可以允许开发者使用Java背后庞大的类库。通过multiprocessing或Stackless Python，甚至手工将任务切成多份，分发给多个进程运行，都可以规避掉GIL的问题，更充分地利用系统性能。当然，随着时间的推移，动态语言的实现将会越来越成熟，不但MRI逐渐完善，MagLev和Rubinius等一系列优秀的Ruby虚拟机也开始登上舞台；Python 3000甚至打破了向后兼容性，试图将Python以前的设计错误全面改写。回头去看Java等一批成熟开发语言的发展路线，有谁没有经历过不成熟的青春期呢？