的类型被确定,就不能转化的语言。实际上所谓的貌似转化,都是通 过中间变量来达到,原本的变量的类型肯定是没有变化的。 弱类型语言
则反之,一个变量的类型是由其应用上下文确定的。比如语言直接支持字符串和 整数可以直接用 + 号搞定。当然,在支持运算符重载的强类型语言中也能通过外部实现的 方式在形式上做到这一点,不过这个是完全不一样的内涵 通常的说,java/python 都算是强类型的,而
VB/Perl/C 都是弱类型的. 不过相比于动态/静态语言的分类,强类型/弱类型更多的是一个相对的概念。 6。如果采用动态语言,单元测试上的
工作量要比静态语言的多很多 robbin 回这一条。其实你忽略了一点,当使用类似 RoR 这样的框架的时候,应用代码量是 很少的,所以相应需要测试的部分也很少,比使用静态类型语言需要测试的部分少了很多。 另外,缺少单元测试没有你说的那么恐怖。我们现在就没有写单元测试,ruby 代码都已经有 6000多行了,编程也好,排错也好,一样很轻松,哪有你吹的那么恐怖。 7.商业系统的复杂在于组织上交流的困难,一个大公司,内部有个人能把商业流程搞得一清 二楚就不错了,这个人还能把过程给
软件人员讲清楚那简直是可遇不可求的事。这样用 ruby 反而有优势了,可以快速开发,促进交流,开发出个模型出来给商务人员看看,用用,自然 交流起来就容易多了。 现在一个开发人员的开发效率比以前高多了,主要原因是因为开发语言和编译器的进步,这 个趋势,只会继续下去,不要抱着过去的教条不放,java 也是在不断改进的,加了 reflection, 加了 assert,加了泛型,下个版本,也要加脚本支持了。
8.其实静态类型语言,除了性能方面的考量之外,最大的优势就是可以提供静态类型安全, 编译器可以检查你的每一个函数调用是不是书写了正确的名字,是不是提供了正确类型的参 数。这样一个系统,配合自定义类型的功能,可以让很多错误(比许多人想象的要多)在编 译时就能被发现和定位。 9.我在 slashdot 上类似话题的讨论上曾经看到过有人抱怨动态语言,那个哥们是从事银行系 统的, 大概有10万行的 python 代码, 最后因为细小隐错不断而觉得无法维护, 貌似要转到 java 平台。(如果把 slashdot 上近两年来关于 ruby 和 python 的帖子和评论看一边,大概还能够找 到这个跟贴) 从这哥们的描述来看,他的主要问题是没有单元测试或者单元测试没有达到语句覆盖或者更 强的弱条件组合覆盖,从而导致某些非正常流程发生时,流经这些未被测试的语句导致语法 错误而最终整个程序都挂掉.对于业务系统来说, 这是非常严重的事情。 就像我前面说的那样, 我自己的
程序就曾经不止一次死在 logging 语句上,因为最初我也不测试这类语句的可通过 性。
至于单元测试有没有用,三五人的项目几千行的代码是看不出来的。其实,作坊式开发照样 能够做出很多东西来,5年前国内的开发方式基本上是没有单元测试的,照样也能玩得转。 但是,就我自己的体验而言,虽然我并不遵循 TDD,但单元测试是足够详尽的,而这个测试 网给我的置信度(尤其是在修改代码和较大规模重构时)是之前不可想象的。我估计上千行的 程序,就能够在渐增式的单元测试中尝到好处。 10.编译器对程序员的帮助到底有多大,这个还是要应人而异的。编译器能查出来的很多都属 于打字错误,拼写错误。对于 robbin 来说,即使没有编译器,检查这种错误也是小菜一碟。 可是对于经验不是很丰富的程序员来说,情况恐怕就大大不同了。毕竟程序员经验方面差异 的一个重要方面就是 Debug 能力和经验的差异。 对高手来说仔细读上两遍程序就能发现的错 误,对一些新手来说可能会花上一两小时,这种情况我在实际项目中碰到很多次了。