锁定老帖子 主题:静态类型语言的优势究竟是什么?
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2006-11-14
floating 写道 robbin,你在开发JavaEey时有没有做一些严格的建模工作?比如现在重要的class是不是基本上在设计阶段都考虑到了?还是你认为用RoR就应该遵循RoR提倡的Agile方式进行开发?
没有,边开发边设计,一边添加表上去。RoR本身也有比较强的DataBase Migration功能,强调了数据库表设计的敏捷化。 RoR就是feature驱动的,我觉得比现在主流的工业语言来说,更加贴近用户需求,更加强调反馈速度,迭代次数。这和现在主流工业语言的架构驱动确实感觉上很不一样。 |
|
返回顶楼 | |
发表时间:2006-11-14
高级动态语言的一个优势就是开发速度快,容易部署。
而缺点就是它们在某些方面很擅长,但不是所有领域。 我们不可能用Python和Ruby写一个Eclipse出来,也不能写一个VS2005出来。GUI是高级动态语言的其中一个缺陷吧(虽然也有一些GUI库)。 值得关注的是可以在Eclipse/VS2005上开发调试Python/PHP/Ruby代码,而反过来却不能。 |
|
返回顶楼 | |
发表时间:2006-11-15
Elminster 写道 exception specification 可以是类型的一部分的。 其实静态类型语言,除了性能方面的考量之外,最大的优势就是可以提供静态类型安全,编译器可以检查你的每一个函数调用是不是书写了正确的名字,是不是提供了正确类型的参数。这样一个系统,配合自定义类型的功能,可以让很多错误(比许多人想象的要多)在编译时就能被发现和定位。 类型一直是个有趣而富有争议的话题:一方面静态语言在动态配置,Agile开发,DSL的浪潮中显得有些力不从心;另一方面有些底层系统的开发者认为现在的强类型静态语言的类型检查还不够'强', 比如Tim Sweeny(Unreal 3D引擎开发者)在The Next Mainstream Programming Language的演讲中问大家如下的C++代码可能会有什么问题: Vertex[] Transform (Vertex[] Vertices, int[] Indices, Matrix m) { Vertex[] Result = new Vertex[Indices.length]; for(int i=0; i<Indices.length; i++) Result[i] = Transform(m,Vertices[Indices[i]]); return Result; }; 答案请看演讲稿第29页。 |
|
返回顶楼 | |
发表时间:2006-11-15
cookoo 写道 Elminster 写道 exception specification 可以是类型的一部分的。 其实静态类型语言,除了性能方面的考量之外,最大的优势就是可以提供静态类型安全,编译器可以检查你的每一个函数调用是不是书写了正确的名字,是不是提供了正确类型的参数。这样一个系统,配合自定义类型的功能,可以让很多错误(比许多人想象的要多)在编译时就能被发现和定位。 类型一直是个有趣而富有争议的话题:一方面静态语言在动态配置,Agile开发,DSL的浪潮中显得有些力不从心;另一方面有些底层系统的开发者认为现在的强类型静态语言的类型检查还不够'强', 比如Tim Sweeny(Unreal 3D引擎开发者)在The Next Mainstream Programming Language的演讲中问大家如下的C++代码可能会有什么问题: Vertex[] Transform (Vertex[] Vertices, int[] Indices, Matrix m) { Vertex[] Result = new Vertex[Indices.length]; for(int i=0; i<Indices.length; i++) Result[i] = Transform(m,Vertices[Indices[i]]); return Result; }; 答案请看演讲稿第29页。 你这段代码是 C# 的 ………… |
|
返回顶楼 | |
发表时间:2006-11-15
oops, 确实是C#的,好记性不如烂笔头555
|
|
返回顶楼 | |
发表时间:2006-11-15
robbin 写道 没有,边开发边设计,一边添加表上去。RoR本身也有比较强的DataBase Migration功能,强调了数据库表设计的敏捷化。 RoR就是feature驱动的,我觉得比现在主流的工业语言来说,更加贴近用户需求,更加强调反馈速度,迭代次数。这和现在主流工业语言的架构驱动确实感觉上很不一样。 robbin,那是不是可以认为这样的工作方式对开发人员的素养和开发习惯都有比较高的要求?你能不能推荐一些介绍如何采用feature驱动的方式进行团队协作开发的资料? |
|
返回顶楼 | |
发表时间:2006-11-15
动态类型语言如果没有良好的IDE,调试器,并不合适初学人员使用.初学人员需要有外部工具来限制其不可预料的行为.静态语言有编译器存在,可以很大的限制初学者出错的可能性.有调试器,则可以明确定位错误发生位置.
动态语言大都时候都只有一个解释器,如果开发人员经验不够丰富,那么完全不能胜任开发工作的. Java/C#这类语言,菜鸟和高手都能够完成同样的功能,就是所需时间不同而已. 能够给大量菜鸟使用,并可以堆出一个可以部署的项目,就是静态语言的优势了. |
|
返回顶楼 | |
发表时间:2006-11-15
dongbin 写道 单元测试覆盖到这些语句很难么?实践中遵循TDD,就会在不知不觉中覆盖到所有代码。我根本感觉不到额外的成本。 遵循TDD,就会在不知不觉中覆盖到所有代码?无语中.... 严格的说,TDD中的测试做的是准黑盒的功能性测试,而不是白盒的结构性测试。怎么可能起到覆盖所有代码的作用? 从测试本身来说,单元测试能做的比TDD中所谓的测试要细化得多。但是要做到语句覆盖以上的覆盖率(前面有个弱条件组合覆盖的例子),这个代价和能力不是多数人所愿意付出的。 难道又要开始炒什么是TDD中的T这个冷饭了么? 引用 再说逃离单元测试的覆盖值得那么沾沾自喜么?logger为null是编译器能检查出来的? 拜托,难道你在写java程序的时候真的测试了getter/setter这类方法?如果是的,恭喜你......... 如果不是,赶紧去补上............ 至于logger为null,有两种情况,编译器能够检查出来logger未初始化就使用的错误(当然,如果必要,人为设置为null也可以骗过编译器)。 另一种情况,logger被在语义上合理初始化了,但是全局logger初始化的时候出错,这个时候,出错的是这个初始化的地方,正确的捕获位置应当在调用初始化的点,难道需要推迟到在使用logger来记录信息的位置来捕获? 在前面已经说了,这类logger语句中的错误,基本上不应该在此处被捕获。里面的隐含意义是:如果在初始化失败点被捕获,还有补救的可能,但是在日志记录点被捕获,基本就88吧。兄弟我看了那么多年程序,还真没看到过给logger.xxx语句套上try/catch的。而如果因为logger语句可能的问题而给整段代码套try/catch,那就是最愚蠢的做法了,一死全挺,而且程序死在次要功能上,哭都没地方哭。 引用 另外,无论是编译器还是单元测试都不能保证代码正确无误--世界上没有任何方法或者技术可以做到! 兄弟,没人说编译器还是单元测试能保证代码正确无误啊。没必要自己树个靶子自己打吧。 引用 但是单元测试给我们创造最多的机会来发现错误,而TDD给我们更多利用单元测试的机会。 关键是代价。如果不考虑代价,那么每个项目团队都会去做这件事情。只是大家都不是生活在真空里面。就像robbin这次的javaeye2.0之旅一样。这里面有平衡点,所以才会有这个话题。 |
|
返回顶楼 | |
发表时间:2006-11-15
编译器对程序员的帮助到底有多大,这个还是要应人而异的。编译器能查出来的很多都属于打字错误,拼写错误。对于robbin来说,即使没有编译器,检查这种错误也是小菜一碟。可是对于经验不是很丰富的程序员来说,情况恐怕就大大不同了。毕竟程序员经验方面差异的一个重要方面就是Debug能力和经验的差异。对高手来说仔细读上两遍程序就能发现的错误,对一些新手来说可能会花上一两小时,这种情况我在实际项目中碰到很多次了。
|
|
返回顶楼 | |
发表时间:2006-11-15
BirdGu 写道 编译器对程序员的帮助到底有多大,这个还是要应人而异的。编译器能查出来的很多都属于打字错误,拼写错误。对于robbin来说,即使没有编译器,检查这种错误也是小菜一碟。可是对于经验不是很丰富的程序员来说,情况恐怕就大大不同了。毕竟程序员经验方面差异的一个重要方面就是Debug能力和经验的差异。对高手来说仔细读上两遍程序就能发现的错误,对一些新手来说可能会花上一两小时,这种情况我在实际项目中碰到很多次了。
所以我也强调静态语言编译器对于初学人员的帮助. 如果是robbin这样的高手,说不定就已经能够做到,一次code完,一次编译过,到处运行不需要debug的程度了. 不过吗,世界上还是新手菜鸟多. |
|
返回顶楼 | |