.NET系列 之 借鉴的两种方式和不同结果

前段时间爆发了两个厂家之间的口水战，如火如荼，甚至出现了逼着用户选择一个的情况。从某种意义上说，都有不对的地方。一个是山寨大王，一个是牵强附会，各打五十大板。今天就借着这个事情来说说山寨的问题吧。

前面两篇文章，如果有同学一直在看，可以得出一个结论，微软的.NET技术很大程度上取自Java的JVM。这一点是毋庸置疑的，即使是微软也从未否认过这一点，毕竟有案可循可以考证的第一个商业化跨平台方案就是JVM。微软在考察和学习了JVM的长处的基础上，推出了.NET Framework这个石破天惊的技术。算是山寨吧。

还有一个山寨大王，不说大家也知道，呵呵。有啥好的就买过来抄过来，反正是据为己有然后再打击致死。看见好的就买，这个事情微软也做，做的多了去了。

只是微软为什么没有被枪手以外的人称作山寨大王呢？因为他们会在复制的基础上取其精华去其糟粕，青出于蓝而胜于蓝。看到JVM的长处，也看到了短处。所以微软允许自家的C#称霸的同时，也允许其他任何厂家来补充.NET生态环境。比如COBOL,比如Forth,比如FORTRAN,等等。这一点就要比只是闷头自己做东西的Sun高明很多。毕竟你一门语言再怎么样也有其劣势。比如C#好用，快速开发。那么就必然对高性能环境支持不是很好。再一个，C#毕竟作为一个3GL,不是DSL,很多时候还是有劣势的。而如果微软只允许C#一家独大的话，那.NET就变成了一个Java的翻版。要用就是Java，其他语言都弱势的一塌糊涂。如果要接入JVM的框架中，就要自己再来一套环境什么的，所以我愣是没搞明白Scala要怎么用。但是微软没有这么做，微软允许大家来百花齐放百家争鸣，也造就了今日丰富多彩的环境。正如前文所述，有计算的交给FORTRAN,COBOL,要动态就交给Python,诸如此类吧，反正貌似除了以J++和J#形式存在了一段时间的Java和有法律纠纷的Delphi以外，其他语言基本上都可以找到.NET的编译器。

这可不仅仅是有选择，选择多这么简单的事情了！

你完全可以在升级平台时轻松非常多，轻松的简直不可同日而语。假设个场景吧。之前有个系统，构建于COBOL,这个语言在银行系统里非常常见。现在要升级到新机器新平台了，原有系统处理不了这么大的业务量了，总之是要升级了。然后原有公司掏出代码说，哝，代码在此，您自己看着办。

如果我说，要转型到Java下，这些代码就全是废柴鸟。您得看懂了才行，只有看懂。或者重新开发。

如果我说，要转型到.NET下，那代码请拿来，找个COBOLer来，用新编译器搞一搞，问题会解决的非常多。这些业务代码还是可以用的，只是架构设计上要动一下。

一边是经过验证的，十几年几十年实际环境验证的代码;还有一边是根据业务重新开发的系统，不管是人还是环境都不一样了。

如果你是甲方领导，你会选择什么技术？选择第一个，您要节省的可就不仅仅是时间了，还有非常非常多的事情可以省去了。毕竟这些代码都在实际环境中跑过验证过。新系统要出问题，就是调用出问题，原代码出问题的可能性几乎不存在。

选Java重写，那可爽了- -#,反正我是不干。

有童鞋要说，上哪给您找代码去啊？我们得要求重新来过。那感情好，莫非当.NET阵营里这么多专门做科学计算的语言里的那么多函数是摆设？就算抛开这些语言，C#的组件式开发也比纯Java码代码快啊。毕竟找个C#程序员来，你用的控件他基本都用过。即使没用过，用几次也就差不多了。而J2EE的自定义控件多如恒河泥沙，谁知道你用的是哪门子控件？

先说到这里吧，下次会说到开源和不开源的一些问题。也欢迎同学们点题，如果我能写，会一篇一篇的来写。