C++与C#之辩证:圣人与巨人比较

最近看了一些C#和.NET的文章和例子代码什么的,感觉入门了,这里发些牢骚,还准备一个水桶装大家的口水,并用这些口水蒸包子。


做 C++ 11年,有些感觉,感觉语言不外乎语言(佛家曰:看山不是是山),很是自诩。做了这么久的C/C++,竟然是:蓦然回首,伊人却在灯火阑珊处。去年想过自己设计语言,参考了D, JAVA, C#, Ruby, PHP, Python 等等,后来又觉得,语言本身不是很重要,重要的只是使用这些语言的人——程序员的接受程度而已。回过头来看看语言生成的目标代码(看看汇编实现)进行过归纳总结,也有些发现,总的来说,高级的语言生成代码的时候会自动给程序加上一些实现,例如构造函数的调用,原来在C的时候要构造起来得显式调用,到了C++则由编译器安排;又如模板,就是用一些特定的语法告诉编译器,生成按一定规则预先做一些代码;再说委托,最为本质的就是this指针委托的时候预存、调用的时候放入EAX寄存器。

所以撇开语言语法,我们可以看到,高级的语言会自动给程序加上一些实现,也不外乎如此——这就是看山不是山的初级境界,希望以后能回到“看山还还是山”的更高境界咯,嘎嘎。

现在回到正题,C/C++与C#(或者Java)的比较就是圣人与巨人的比较,不具备可比性。你是想继承圣人的衣钵呢,还是想站在巨人的肩膀上?悉随尊便!

再看一点,你希望未来的语言为你——普通的程序员做些什么呢?有没有简单实现复杂逻辑的的语言啊?结果是,没有,如果你是总统,可以号召一批人为你做这些,而不能指望语言能做这个。既然复杂逻辑不能简单实现,那么总可以稍微简化一些吧?那是可以的。只是稍微简化一点而已。现在大部分的高级语言并不具体的简化某个领域的问题的实现,而是简化了编程本身。

所以高级的语言只能少许简化最终目的问题的解决,而大部分只解决了一些编程本身的问题。简而言之,语言是为程序员度身定做的,越高级,程序员越舒服,自学成才的和喜欢利用别人成果的人越倾向选择这种;而一开始就看到最终解决问题的复杂性的人(戏称学院式程序员, academic programmer)则刚好相反,他们会选择语言的特性来简化最终问题实现的,而不是简化编程本身的语言,这样的语言或许非常难学,例如LISP,CLIPS(C语言产生式处理系统)。

现在看来问题有点清晰了,最终问题的解决被分成2个步骤。第一步编程语言,第二步用此语言解决最终问题。而这2步按照目前的科技水平来说,存在一定的矛盾,就是语言本身的进步会约束使用语言的自由度等因素进而对最终复杂系统的解决产生负面影响,因而对第二步有阻碍作用,难怪外国有风潮倾向于面向语言编程的呢。


对于迷雾中的初学者,也是非常难以选择,这里我推荐一种选择方法及其晋级路径:
[] 如果觉得自己有天分的,能很好的驾驭复杂问题的人应该选择自由度大的语言,路径则是专这样的语言3-5年后涉足其他高级语言补充并积累最终问题(不是解决问题的方法),再学习底层以便更宽广的认识自己所学。往继承圣人的衣钵方向发展。
[] 如果觉得自己天分不足,又想使用别人成果的,就站在巨人肩膀,选择相对高级的语言,何况这些语言(C#,java)有非常庞大大的类库支持呢。路径则是学好相对高级的语言,认识API,从API设计者角度看问题,多看看搜集最终问题并进行归类,往平台架构方向发展。

谢谢阅读!
posted @ 2007-09-25 15:52  yesry  阅读(6167)  评论(32编辑  收藏  举报