精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2005-06-15
再有就时,现在动态注入已经是一种趋势,包括java在内,也是在很多地方应用了动态注入的机制,使调用者不必关心具体的实现类,同样也无法通过编译器在编译器检查。
|
|
返回顶楼 | |
发表时间:2005-06-15
如果你真的认为static type checking那么重要的话,可以去找PyChecker.python可以通过嵌入库的方式来进行type checking.
健壮性与是否是强类型语言没有直接的关系。Robert C. Martin 和 Bruce Eckel 表达过这样的观点, Robert C. Martin: The more you depended upon the unit tests, the less you depended upon the type safety of Java or C++. Bruce Eckel: The benefit of simpler, clearer expression of concepts is simply not worth the danger. Even if that benefit is a productivity increase of 5 to 10 times over that of Java or C++. Python,给你带来的是高效率的编码方式,同时也意味着测试与迭代的更为简便快捷。你可以去观察C++ unit与Java Unit 。你会发现写一个C++ Unit 简直就是折磨,尽管只是copy 几段macro.为什么?是什么解决了Java Unit的问题,这是值得思考的。 所有的选择,总是trade off,问题的关键是我们trade off的依据是什么?是我们的想象,还是来自实际的经验证据? 就如很多C++的程序员会指责Java的性能问题,是的Java总是有性能问题,但是这足以成为gc的取舍的依据么?按照我现在写C++程序的习惯,遇到一个可能会引起性能问题的地方,总会想这总比Java好多了吧,于是性能问题就不存在了........ |
|
返回顶楼 | |
发表时间:2005-06-15
Trustno1 写道 健壮性与是否是强类型语言没有直接的关系。Robert C. Martin 和 Bruce Eckel 表达过这样的观点,
Robert C. Martin: The more you depended upon the unit tests, the less you depended upon the type safety of Java or C++. Bruce Eckel: The benefit of simpler, clearer expression of concepts is simply not worth the danger. Even if that benefit is a productivity increase of 5 to 10 times over that of Java or C++. Python,给你带来的是高效率的编码方式,同时也意味着测试与迭代的更为简便快捷。你可以去观察C++ unit与Java Unit 。你会发现写一个C++ Unit 简直就是折磨,尽管只是copy 几段macro.为什么?是什么解决了Java Unit的问题,这是值得思考的。 这正是我想要的答案,权威的话还是要重视的,准备实践一下看看再说 |
|
返回顶楼 | |
发表时间:2005-06-15
其实,这个世界上有一大群称之为C程序员的怪物,成天与void * 和 char c=257;这类东西打交道。所以没有了type check 不是天要塌下来的事情。
另外,现在还有一种叫做Type inference 的东西,兼具static type和dynamic type的优点,这点ajoo可以来谈谈。 |
|
返回顶楼 | |
发表时间:2005-06-15
其实同很多人相信的不一样,python这样的语言正在完成一些非常巨大的项目。
弱类型和健壮的代码并没有本质上的冲突,关键还是看你怎么用。而要能用好,则最好能够理解python对象在内存中存在的形态。 其实现在很多人对于程序在内存中究竟是怎么运行的不了解,所以才会有很多问题。 |
|
返回顶楼 | |
发表时间:2005-06-16
还有一种有趣的事情就是,用什么语言写代码就如同用什么语言说话一样,当你English很流利的时候,你其实可以感觉到你的思维方式是往英国人的方向靠拢的。写程序也是如此,如果你有机会频繁的在两种以上的语言之间的切换的时候,你就会有这种体会了。所以每一种语言都有自己的思维范式,不同思维范式下看待问题的结果都是不同的。
|
|
返回顶楼 | |
发表时间:2005-06-16
不做类型检验 不限制语法 也许使我们有更多时间来做单元测试.
可能积木因此搭的更高 更稳固. |
|
返回顶楼 | |
发表时间:2005-06-16
这个我是深有体会阿,所以最反感的一种观点就是号称学(用)什么语言都一样。
既然这篇帖子被移到了这里,还请有经验的人谈谈是否在开发中用python之类的东西做过大东东,似乎现在看到的例子都是国外的。 Trustno1 写道 还有一种有趣的事情就是,用什么语言写代码就如同用什么语言说话一样,当你English很流利的时候,你其实可以感觉到你的思维方式是往英国人的方向靠拢的。写程序也是如此,如果你有机会频繁的在两种以上的语言之间的切换的时候,你就会有这种体会了。所以每一种语言都有自己的思维范式,不同思维范式下看待问题的结果都是不同的。
|
|
返回顶楼 | |
发表时间:2005-06-16
国内现在很少有机会用python这样的东西做大项目的。
我知道的最大的项目是联通用的email系统。 |
|
返回顶楼 | |
发表时间:2005-06-17
一种语言包打天下看来不太实际。
我也认为静态类型适合大规模的程序,而动态类型则适合script。 静态类型虽然有迅速纠错的优点,但是,缺点也是罄竹难书。 书写往往繁琐(type inference可以弥补这点,但是继续提高了语言复杂性),灵活性降低,语言复杂度也剧烈提高。 为了弥补静态类型造成的灵活性缺陷,人们又惊讶地发现可能需要类型的类型——c++的concept check,haskell的kind,然后还会有类型的类型的类型etc。 而无论怎么绕,也达不到动态类型的灵活性。 绕一圈回来,人们发现,靠,折腾个啥,还不如就简简单单不弄这妖蛾子呢。 于是动态类型又吃香了。简单,根本不用考虑那天书般的higher-order logic(就是类型系统,证明type-safe数学上可不是个简单的事,至少对我如此),写起来也简单,而且如果高兴,我还可以写很多变态灵活的代码(比如fixpoint),满足了程序员廉价的虚荣心。 不过虽然unit test可以部分弥补动态类型出现的类型错,但是我还是觉得它对于大规模的开发还是不友好的。 理论上,ut并不能完全检查出所有的类型错误,(比如,老爷我先循环一百万万次,然后取个随机数,如果随机数小于0。1,就1/"abc",你ut来查一下看?) 这就对一些可靠性要求很高的应用造成了一定的阴影。 所以,最适合动态类型的应该还是scripting |
|
返回顶楼 | |