选择C#还是Java.docVIP

选择C#还是Java 1. C#的语法糖 在之前，每当别人问起我，某个C#的新语言特性的时候，我总会说，其实就是这么一回事，他不过是一个语法糖，没什么稀奇的，你可以看一下Reflector反编译出来的代码。 可是现在当我仔细思考之后，发现其实语法糖更多地不仅仅是为了我们使用上的方便，而且是代表了一种编程模式以及思维模式的转变。 从最简单地说起，我在之前的文章说过一点，面向过程的语言的核心不在于函数，而在于处理事情的过程，而函数则完全是为了代码的规范，以及可维护性才出现的。但是当我们把若干个函数整理成了我们的类库之后，我们除了使用上方便之外，更意味着我们需要提高我们的逻辑层次，将原本的细粒度逻辑粗化。 我看到了在winter-cn的文章中举了这样一个例子，把大象放入冰箱分成几步，第一第二第三，Ivovy老大回复了这样一句话，语言的发展是让这些都变成一步：把大象装入冰箱。我非常赞同，我认为这就是未来语言的发展方向。 在我之前的文章《基于自然语言的软件工程与程序设计》中，我谈到未来语言的发展方向是基于自然语言的编程，还谈到了一种理想的状况，就是会说话的人就会写程序。即使我们不把眼光放得这么远，我认为，只要了解业务逻辑的人就会编程，这个是完全不过分的。 接下来，我们看一个在C# 3.0 中的关键字：var。在之前，很多人说var最大的作用是为了让懒的人可以不必去打字打出类型。其实我个人更认为当var关键字和我们强大的Visual Studio工具结合起来的时候，就在倡导我们用一种团队思维的角度去看待问题。 当我们调用底层提供给我们的接口，或者使用其他类库返回给我们的方法时，我们不需要了解他的具体类型，我们只需要用var来得到该类型，然后用强大的VS开发工具的智能感知去得到我们需要的属性（或方法）即可。 至于像Lambda表达式所提倡的FP思维，我就更不多说了。 总之，Firelong眼中说，C#语言越来越臃肿的语言特性，然后应该越来越从简，我个人认为，这不是在抹杀C#的进步，更关键的是在抹杀一种编程思维的进步。 2. 语言，还是语言 在语言产生之初，语言之争似乎就从未停止。无论是C和C++。还是Java与C#。从来都是各执一词，然后难分胜负。 我不是一个牛人，无法像Jeffery Zhao一样来举出各种各样的理由来反对Java，或者反对其他语言。至少在我目前的阶段来看，我不是一个语言方面的攻击者。 我只能从经济学的角度去分析：每门语言，每门流行的语言，在市场上占有一定份额的语言，必定有着他的优势所在，否则他必定会被市场所淘汰。而每门语言也必然有着他的劣势，和不适用性，正是这样才催生了其他语言的发展，从而产生一种平衡的关系。 在这里，我只说托管语言。从某种程度上，至少从我目前的程度上，我认为，托管语言来开发桌面程序的确是不大合适的，相对于C++。（在此强调，我并没有过太多桌面程序开发的经验）针对当前大多数的商业商品来说，无论是旧版的飞信，还是概念版的QQ，采用托管语言无疑都是失败的，而我们看大部分成熟的桌面程序，还是采用C++来开发，这确实也能说明一定道理。 而著名的《鬼泣4》采用C++和C#做交互来共同开发，也在一定程序上说明了C#在UI上的薄弱性。（只是看新闻传说，未经证实） 总之，我个人认为：不要轻易地去抨击某一门语言，每门语言都有着他的适用性，你的项目因为C#而失败，只能说是你项目不该选择C#，而不能说C#无法满足你的项目，就说C#是失败的。这样的逻辑明显就是不对的。 3. 语言与设计模式 在之前的文章中，我抛出过这样的一个观点：设计模式实际上是牺牲了语义的自然性，来换取软件的可重用性和可维护性。 对于C#这样一门面向对象的语言而言，根本还是要从面向对象来出发，那么面向对象的核心是什么？每个类都有章可循。 但是，在很多的时候，我们为了扩展性，重用性，可维护性，不得不求助于GOF或者其他的设计模式，我个人认为，设计模式是凸显了“语言”的无助。 因而，在语言的层面上融入设计模式，我个人认为，这不是一种错误，相反，这却是语言发展的必然，至少是基于面向对象语言发展的必然。到面向对象语言发展到极致的时候，应该是一种我们不需要借助设计模式，只要依靠语言提供给我们的语法（或者是”语法糖“）就足够完成我们用其他的设计模式可以完成的工作，这才是面向对象语言发展的大成。 再进一步地说，没有任何一门编程模式是银弹，可以解决我们的所有问题，无论是面向对象，面向过程，还是FP，一种发展逐渐完善的语言应该是将各种编程模式于一体，提供给程序员一种极高的思维抽象，这才是未来语言的方向。