项目事故和安全语言

  有个从表面上看起来很奇怪的事实是：司机戴安全带比不带安全带时发生的行车事故要多。不带安全带时，司机死亡率比较高，但是带了安全带时，司机死亡率是降低了，但是行人死亡率却提高了。

  不带安全带时，司机需要谨慎缓慢的开车，带了安全带，司机却会 更快，更放肆地开车。
这个方面的资料 可以看下 Automobile Safety Regulation and the Incentive to Drive Recklessly:Evidence from NASCAR 和Automobile Safety Regulation

  编程语言，从一种不安全语言(比如c/c++)发展到一种相对安全语言(比如C#)时,语言上安全程度提高，并不因此能够大量的减少项目事故，只能减少对开发人员威胁程度而已。而对于客户平均威胁程度却是提高了。

   安全性高的语言，就像司机有了安全带一样，使得原本那些担心做不好而使得自己饭碗不保地不合格开发人员更加-------放肆了。

  同样的项目 用c/c++开发，开发人员知道c/c++极易出错，开发速度故而缓慢，谨慎。尽量避免在开始就出错。项目运行时，初期出错。小错误还好，如果是系统崩溃之类的错误，有麻烦的是开发人员。

  用C#开发，则因为C#和.net平台有各种各样的保证机制。相对不容易出错，比如c/c++中最麻烦的内存，资源回收和指针问题。项目运行初期也很难发现.等运行一段时间之后，出错了很有可能就需要重新设计了。

  开发语言虽安全，请各位"新人司机"缓慢，谨慎驾驶。

观点有新意，有意思。
从某种角度来说，在对一个改革或新工具作评估时，应该考虑进这个因素，才不至于被推销员蒙晕了。一般来说，能提高数倍生产率的工具，在考虑了成熟度、稳定性、学习曲线、和本文中的开发者思想放松的心理因素后，可能提高的只有50%了。虽则仍不错，但如果预期不准，可能带来信誉、士气等问题。

不知道类型系统专家门是否有这方面的统计数据和研究论文，不知道研究的结果是不是：

有个从表面上看起来很奇怪的事实是：用静态类型系统编写的系统比用动态类型编写的系统bug率更高。用动态类型编写的程序，发生类型错误的情况更多一些，而用静态类型编写的程序，发生逻辑错误的情况更多。

我觉得你说的不对。

如果像Java这种运行在VM上面，没有指针操作，比较安全的语言，即使内存泄漏，我都不会有太大担心，大不了重起JVM呗，有JVM作为一个安全的保障，不会危及操作系统。但是C/C++就不一样，这些东西一旦内存泄漏，就根本找不回来了，不重起整个操作系统，根本就没有戏，可以说危害极大。

其实很多Java开发的大型系统都有或轻或重的内存泄漏问题，即使很多大型企业的关键应用都是如此。但是很多大型行业应用，往往在晚上都会停掉AppServer进行备份和数据维护，因此只要你能够保证24小时连续运行内存泄漏不超出物理内存限制，也就不是什么问题了。

但是C/C++开发的系统，内存一旦泄漏，由于没有VM的安全保障，只能等待重起操作系统，但是对于这些行业应用来说，重起操作系统根本就是不可以接受的，你想，光是重起小型机操作系统，往往都要半个小时，你能受的了？

另外我带过一些人做Java，也做VC开发，我就发现他们写Java程序，基本不出大的问题，但是写起来VC程序，到处都是内存泄漏，程序都不堪一用。

你不能指望程序员在使用不同的编程语言的时候，自己提高警觉，这是不现实的。根据我的经验，做VC开发的人出现内存泄漏问题远远超过做Java开发的。

Jack兄弟，这类比确实很新鲜，可是这也太离谱了吧。

人类很多领域是不容许出错的，一旦出错，后果极其严重，无法挽回。比如，驾驶，建筑，消防，战争 ...

但是，很遗憾（也很幸运），软件开发恰好就不是这些领域。至少在开发阶段，出错是常态，不出错几乎是不可能的。

很多错误不是光靠小心谨慎就能避免的。要靠经验和知识的。

有点意思,从这个角度说东西.
当然是否正确就不晓得了.

你说的这个用c/c++做的系统包含操作系统么?
如果不包括的话,应用程序内存泄露是无所谓的,用不着重起操作系统.

突然想到而已，所以写在这里大家讨论下。语言安全性问题，对于新加入成员影响是不可避免的。而且一定是负面影响大于正面影响。而对于熟手，则可能由于过往经验影响，反而会善于利用。
比如robbin说的 java项目的内存泄露问题，这些都是在已知情况下，而且有解决办法（定期维护重起）。

呵呵 俺做的c/c++程序都是24*7的那种，或者努力实现24*7的,内存泄露，内存碎片啥的，头痛的要死