乾坤一笑 阅读(1003) 评论(48)
源于和pAnic在七猫的《C++的衰落和JAVA、C#的崛起》的评论中的讨论。我觉得自己总结的不错,以后可以再回头看看,看看想法有没有变化:

我做C项目最大的感受是:
C的劣势在于:
1) 没有名字空间,项目超过100w行后很痛苦(尤其是函数的extern和该不该.h中的声明);
2) 移植多家厂商代码时,统一类型很痛苦(<--- define和typedef 混在在一起用,每个厂家都有自己的类型定义方法,冲突的很厉害,又没有namespace的约束);
3) link编译器不稳定很痛苦——不出问题则以,一出问题基本上解决不了(<---多半也是由前两条导致)。

评论列表
清风雨
re: 对用C做开发时"C的劣势"的总结
我觉得你举的只是C表象上的劣势。
而C真正最本源的劣势则在:没有提供和约束进行大型项目开发的指导思想和理念。
C的做法,无疑在开发相对较小型、简单的项目方面,可以获得相当的效果。
因此,才有C++的诞生。
一笑
to 清风雨 //re: 对用C做开发时"C的劣势"的总结
"小型、简单"? 晕!你见过几个C的项目就有此结论?井中观天,让偶可发一笑哦~ ;)
Diviner
re: 对用C做开发时"C的劣势"的总结
我们这里代码不如一笑的多,不过倒是经常碰到一个函数链接到另外一个同名的函数里去了。
清风雨
re: 一笑
确实有大言不惭、坐井观天的意味。
不过,C的面向过程话思想,利于大?C的组织形式利于大?
个人皆谓之否。
一笑
to 清风雨 //re: 对用C做开发时"C的劣势"的总结
宇宙万物,皆有原子组成,原子利于大? 抑或宇宙不大?
小明
re: 对用C做开发时"C的劣势"的总结
C++的namespaces也不怎么样,不如Java的package来的清晰。

在C里面要想避免冲突,就应该学ACE,所有的函数都加上ACE_开头,学Lua,所有的函数都加上Lua_开头
Diviner
re: 对用C做开发时"C的劣势"的总结
ace现在已经加进namespace了,我觉得c++的namespace还是可以的。
小明
re: 对用C做开发时"C的劣势"的总结
C++namespaces不如Java package的地方,对于分层支持不好

比如Java的自带库中,所有io相关都放在java.io.*下面,所有socket相关的,放在java.net.*下面,C++倒好,全部放在std下面,大杂烩。

虽然namespaces也可以做到std::io::*,std::net::*,但是似乎没有多少人会这样用,不知道为什么?可能是::打起来比较累的原因:-)
清风雨
re: 小明
在设计领域,java确实很多地方思想、方法都very good。我也一直觉得java这些方面要比C++、C、C#要好!

不这样用的原因,在于:
package对java就像原生的一样,但是namespace对从C++而言,就像辅助一样。
周星星
re: 对用C做开发时"C的劣势"的总结
第三点我没有看懂,第一二点我是100%同意,英雄所见皆雷同呀^_^

to 清风雨:
C语言的项目一般都很大,我见过数次需要编译二个星期以上的大型工程。
不过你说的也是一个初学者常见的问题,但这个问题与C无关,而是在于使用者有没有用“指导思想和理念”去开发C工程?越更高级的语言越强迫你去使用某一种或几种“指导思想和理念”,然而低级的语言也并没有设置你使用这些“指导思想和理念”的障碍,你自己不用并不能怪语言。举个例子:
小学老师(高级语言)对你上课不听讲会采取一定的惩罚手段来强迫你听讲,而大学老师(低级语言)则不会管你听不听。
对于低自觉性的人,也许小学老师比较适合他;
对于高自觉性的人,大学老师就比较适合,因为他可以采取听课的行为(和小学老师期待的一样),也可以做他认为更有益的事(这一点是小学老师的行为所做不到的)。

to 小明:
你错误理解namespace,using namespace XXX只是一个可以的引入方法。所有的函数都加上ACE_开头,和调用时,所有的函数都加上ACE::开头,有什么区别?
我个人觉得namespaces比package更科学,namespaces的约束只在于使用者,而package已经限制了实现者,从接口上说,使用者应该只关心到自己,也就是所谓的接口最小依赖原则。
小明
to:周星星
我怎么就错误的理解namespaces?
我说在C中,为了避免冲突,建议库函数,结构等最好都带上唯一的前缀。因为C中也没有namespace.

package比namespace更合理,因为namespace冲突的可能性还是有,而java的package都很长,比如com.vckbase.io.*,基本上不可能和别人冲突。

C++要实现这样的,必须
namespace com
{
   namespace vckabse
   {
       namespace io
       {
       }
   }
}

java多简单,
package com.vckbase.io.*;


至于你说的
"我个人觉得namespaces比package更科学,namespaces的约束只在于使用者,而package已经限制了实现者,从接口上说,使用者应该只关心到自己,也就是所谓的接口最小依赖原则"

我没看很懂.package这个也算是限制实现者?

package提供层次清晰的源代码结构,namespace只是避免冲突的一种无奈的解决方案。
zuilang
re: 对用C做开发时"C的劣势"的总结
作为一个初学者对下面的观点不是很认同:
不过你说的也是一个初学者常见的问题,但这个问题与C无关,而是在于使用者有没有用“指导思想和理念”去开发C工程?越更高级的语言越强迫你去使用某一种或几种“指导思想和理念”,然而低级的语言也并没有设置你使用这些“指导思想和理念”的障碍,你自己不用并不能怪语言。

你的意思是说使用c的人应该自己有自己(或约定)的“指导思想和理念”?c没有提供“指导思想和理念”不正是它自己的“缺点”吗?怎么又“与C无关”?难道要使用者自己添加一个(例如oo)?那么它就不是c了。c的确没有设置障碍,你可以自己把它变成c++,汇编更好用。

zuilang
re:**
星星,编译二个星期以上的大型工程是怎么编译的啊?让我开开眼界?挺佩服你们这些高手的
清风雨
re: all
个人感觉,大多数问题,大家的意见还是趋向一致的。而很多分歧点只是在我们各自的喜好,看问题的角度。

比如“周星星”认为没有提供约束不是错,同时也认为了这种理念是重要的;而“zuilang”和我则认为,必要的约束需要提供,这就是一种理念。
再“周星星”认为package对提供者有约束,同时也认为可见性约束很重要;而“小明”和我则认为package在可见性约束和管理上更甚namespace一筹。(顺便,将接口约束在一个namespace和将接口约束约束于一个package,本身也是殊途同归的事,都是为了可见性管理。)

所以,我个人觉得,很多问题,我们应该注意重的和重心得到表达即可,一家之见就不甚重要了。(^_^)
周星星
re: 对用C做开发时"C的劣势"的总结
re 小明: C++禁止你写长名字空间了吗?
namespace是基于符号的,而package是基于包的,符号比包依赖性更小。

re zuilang:
“你的意思是说使用c的人应该自己有自己(或约定)的“指导思想和理念”?”
--- 我没有这么说,而且我强烈反对这一点,不是使用c的人应该“自己有自己的”,而是对于一个特定的方案应该“自己有自己的”“指导思想和理念”,当然不同的方案有可能其指导思想和理念是相同的。
不是说 甲 应该以 a 思想为指导开发他的所有程序,乙 应该以 b 思想为指导开发他的所有程序;而是说 对于 a 需求 和 b 需求 应该使用 A 思想为指导, 对于 c 需求 应该使用 B 思想为指导。
我的观点有两个:
a. 任何一种指导思想和理念都不是适应所有一切需求的,所以不同的需求应当采用不同的指导思想和理念。
b. 语言不应该强制程序员使用某一些指导思想和理念,更不能限制程序员使用某一些指导思想和理念。

“c没有提供“指导思想和理念”不正是它自己的“缺点”吗?”
--- 我一直没有明白你为什么认定它是缺点?

“道要使用者自己添加一个(例如oo)?那么它就不是c了”
--- 难道C的定义就是“没有OO”,我很奇怪你是什么时候接触OO的,我记得我在高中上第一节C语言课时就提到过面向对象的开发方式,老师还推荐了一本面向对象设计的C语言书籍,当然我并没有去看过,而那时Java还没有出生,C++这个名字还没有几个人听说过。
再者,有了面向对象的C语言,它也不是C++。

“编译二个星期以上的大型工程是怎么编译的啊?”
--- 我没有说你“井中观天” ^_^,事实上我也不知道它是怎么编译的,我甚至不知道那套编译工具(不是编译器)是各个公司自己写的,还是买的一套标准程序。但常见的,半天之内就能编译完成的我知道:下班后由源代码控制器自动调用编译器来编译,这样第二天上班时就可用了。但对于需要数天的,我猜想应该有它分段编译的优化吧。联想到对C++工程的编译优化,因为C++工程编译几个小时的也非常常见,把理应聚合的模块先不聚合,而是通过接口联系起来,这样一来,平时的编译就可以从几小时锐减到几分钟,在一切代码编写、测试、修改完成后,再去掉接口,该聚合的聚合起来,编译一下(时间很长),然后发布给客户。
周星星
re 清风雨:
你的“很多分歧点只是在我们各自的喜好,看问题的角度。”我同意。 就比如7cat《C++的衰落和JAVA、C#的崛起》中的例子,7cat用C++,我也用C++,但他希望C++标准中应该有的,却是我认为不应该有的。归根结底在于我和他所做的东西不一样,自然对标准库的需求也不一样。
清风雨
re: 周星星
1.不太赞同你回复“小明”的认同,这里的依赖性并不是那么重要,甚至恰到好处(当一个质级改变后,细微的量差别,并没有什么实质影响)。而更重要的是你的“符号”怎么解释?何以谈依赖性比package小?

2.也不赞同你回复“zuilang”的几点:
a.这个有点过于笼统,而且哲学的范畴,就不多言了。
b.语言应该提供对某种思想的体现和支持,内建的支持比附加的支持,获得的好处是不言而喻的。比如:用汇编去提供OO,那就是一个很吃力的事了。
c.在一个竞争的情况下,提供适合顾客的服务,必然就是它在竞争顾客上的优势,而没有就是劣势了。

3.这种大型工程,为什么还存在? —— 一定曾度是因为历史原因。就像你什么时候举个例子,汇编写的大项目一样。—— 但是,就普遍现象而言,汇编仍然不适合编写大型项目。

你回复我的,在7cat的这个问题里,C++所涉及的领域,它应该提供它对这个领域的支持(或更好的)。不是吗?我提供了支持,对我的顾客而言,不是受益了吗?不需要的这个服务顾客也没有不利影响。
清风雨
re: 对用C做开发时"C的劣势"的总结
顺便:什么叫不利,不适合。不是说它不能,而是说这样做代价相对较高、太高,不合算。
周星星
re 清风雨:
1。 眼光要长远点,一个不合理的方法也许在当前并不表现出恶劣的后果,但事物总是发展的,为什么当初不按照合理的方法来做呢?这个例子我不想举,而且我相信每一个程序员都为此而后悔过。比如我就是,我很喜欢采用一些不合理,但看上去很简单的方法,直到日后某一天需要扩充时才发觉设计的不合理,并为此而不得不重构。

2。 以OO来指导汇编开发并不麻烦,并不会比以OO来指导C++或Java开发来得麻烦,你说那话的根源在于什么才是OO,这是个大问题,如果细细研究C++和Java,会发现这两者中的OO并不是同一个东西,不仅仅是细节上的问题,甚至从目的性上就出现了分歧。
有的人认为有了class关键字的才是OO,有的认为对象后面加上一个点再加上成员方法的才是OO,如果这样认为,那么C/ASM是不可能有OO的,但问题是OO并不是这样定义的(也没有什么明确的定义),OO开发方式早在C语言时代就非常流行于C语言开发中了。

3。 这一点你就错了,为什么你认为它是历史原因造成的,而不是现在工程的需要?一个语言能不能编写大型项目主要(注意这个限定词)取决于这个语言本身机制的稳定性,假设消息机制有亿分之一的出错几率,那么在只包含一个模块的工程中这个工程出错几率是亿分之一,可以忽略不计,但在包含一亿个模块的工程中这个工程出错几率可能是1,等于一个无用的工程。
所以使用Java/C#的工程一般都很小,因为它们包含有不能保证100%正确的消息机制和内存回收机制;C++语言本身虽然没有任何bug,但其编译器实现是复杂的,所以一般用于中型的工程上;而C/ASM可以用于大型工程,但为什么ASM的工程也不大呢?这是因为C语言也能用于大型项目,且其比ASM开发简单。
其实,我觉得你的根本问题是没有见过真正的“大工程”,有人说他公司的ERP项目(Java)包括3千多个功能模块,确实很大,但也只是体积大,甚至在真正的“大工程”面前连体积都算不上大。不可否认,OO或者其他等设计方法对于比微小工程大一点的工程是有帮助的,但遇到真正的大工程其作用就像一滴水对于海洋的作用,没有这一滴水海洋也不叫小溪,多了这一滴水海洋还是叫海洋。

“顺便:什么叫不利,不适合。不是说它不能,而是说这样做代价相对较高、太高,不合算。”
--- 这句话我完全赞同,但我不知道你是不是想反对我某个观点。我对那些初学者的建议就是,千万不要用任何一个典范往需求上套,这样做的结果就是每一个都行,但每一个都未必是最合适的。正确的做法是根据需要的不同而选用不同的编程典范(当然现实是多个典范一起作用,互辅互成)。
小明
re: 对用C做开发时"C的劣势"的总结
oo出现就是为了缓解随着项目越来越大而出现的软件危机的,但是周星星却认为OO只能对小项目有用,对大项目基本无用,这真是对OO的莫大讽刺啊。

即使class可以不用,但是封装的oo基本思想还是有用的吧。

清风雨
re: 周星星
论述非常精彩!^_^

1. 眼光长远的说法好!不过,太远了也会适得其反。

2. 以OO来指导得说法也很好,但,就同样的采用OO指导而言,用C++/Java等,不是比C和ASM更方便,更快捷?要不怎么会有你有以前反对的“C++就是Objective的C”呢?

3. 我先认错(因为,我确实这里没有实际的了解现在的C大型项目,而是自以为然,而且也对你这里的大,我习惯用“超大”)。接着的一段论述相当精彩,不过,很多工业软件都是用java写的,为什么UNIX是用C写的,我们可能需要查找一些更具体的原因,比如:性能因数、历史原因。另外,你的“比ASM开发简单”道出一定的真理:为什么简单?
按你的意思,C不利于“小工程”,那为什么C不利于“小工程”呢?,或者,“中工程”,同样也有个原因。不知道你怎么看这个原因?(我想你不会告诉我是一笑写的那1和2)

4. 我说的顺便,是我一开始觉得你和一笑对“不利”的理解有点偏差,担心我们做无谓的讨论,而旁观者又被我们误入“偏途”。
周星星
re: 对用C做开发时"C的劣势"的总结
re 小明:
我不想在大和小的定义上和你争论,你说的“大”也许只有0.1mm,而我说的“小”也许有10km。
封装是OB的一个基本特性,但封装的定义是什么?或者说封装于哪一层?这取决于实现者。

re 清风雨:
1。只有让历史去证明了。

2。“以OO来指导得说法也很好,但,就同样的采用OO指导而言,用C++/Java等,不是比C和ASM更方便,更快捷?”
--- 不可以这么说。C++/Java是在语言层面提供了一些OO的支持,但这仍然是细微和低级的,当然,如果你的工程认为这些就够了,那么当然可以说比C/ASM更方便,更快捷。然而,对于大工程而言,这些内建的OO支持是微不足道的,需要在上一层次,甚至更上一层次上进行OO化(只是举个例子,未必一定是OO)。
“要不怎么会有你有以前反对的“C++就是Objective的C”呢?”
--- 是因为C++是多典范的,C++并不是一个只能面向对象的语言,说C++是一个面向对象的语言那就错了。

3。“很多工业软件都是用java写的”
--- 我不知道,而且第一次听说Java可以编写工业级别软件。
“为什么UNIX是用C写的,……,比如:性能因数、历史原因。”
--- 即使撇去性能因素历史原因,UNIX也不可能用Java编写,因为,(记住这一点吧):用Java编写UNIX比用C编写UNIX更复杂,更耗费开发时间。 我们常说Java简单,那只是局限于某一个特定的领域(比如MIS,比如WEB),并不是在所有领域中它都是简单的,如果存在这样的语言,那么其他语言基本上就可以淘汰了。
“你的“比ASM开发简单”道出一定的真理:为什么简单?”
--- 为什么简单还用说吗?当然,这里的“简单”也并不是指一切情况。
“C不利于“小工程”,……”
--- 我本没有说C不利于小工程,C适合任意大小的工程,我说的是C适合大工程。但结合实际,你说的“C不利于小工程”也对,因为对于小工程,Java/C#也合适,同时对于程序员而言,它俩比C语言更容易掌握(不仅仅是指语法)。
Diviner
re: 对用C做开发时"C的劣势"的总结
3。“很多工业软件都是用java写的”
--- 我不知道,而且第一次听说Java可以编写工业级别软件。

有很多的,我在上海时一家公司核心部件就是用的java(那家公司行业市场份额在美国是第三)
一笑
re 清风雨 re: 对用C做开发时"C的劣势"的总结
C本身没有语言上做不到的限制,这就决定了他能做大小工程,做各种功能。但是用不用C做项目,还要考虑生产效率等多种原因。

至于产品规模和产品品质,如果软件工程把握的好,用C没有任何问题的。如果你了解CMM,了解CMM 5.0,就明白我说的这番话。
一笑
to 星星://re: 对用C做开发时"C的劣势"的总结
我用的那个链接器很有问题。如果他链接出错了,就报一些八不沾边的错误,或者压根没有提示信息。有时候链接success了,烧上版本竟然跑不起来!(<==后来发现跟大小有关系,删掉一些源码就可以了。)
真不明白,难道做linker比编译器还难?
乾坤一笑
re: 对用C做开发时"C的劣势"的总结
我想起上次我写了篇blog《C语言的异常机制》,结果有人说“这不叫异常机制”,有人说“这个太简单,异常很复杂”。哎,我当然没法子几分钟写个能够大规模的C的异常库出来,也不会把商用得代码贴到blog上来,但是这并不等于说用C就写不出来,事实上如果我没有看到过源码也不敢在这里卖货。井中的朋友如果没见过请买一本David R.Hanson写的《C Interfaces and Implementations - Techniques for Creating Reusable Software》(中文名叫做《C语言接口与实现》),书中具有C异常库的一整套源代码,另外据说书上的代码在某个ftp上也有下,身旁有书的朋友翻翻前言吧。
这次讨论OO就又是这样。C语言虽然没有在语言设计中就强迫用户使用OO,但是用户如果用OO的思想去设计,也未必用C写不出OO的程序。(举个C写的OO代码的例子,和C++做对比的,看看吧。here!)君不知最早期的C++,或者说C++的前身Pre C已经完成了OO的功能,而它是要先编译成C代码,再用C编译器继续编译成目标文件的。如果C写不出OO程序,又怎么能把OO程序转化为C程序来编译呢?另外,除了C++外,还有很多派生于C的OO语言,只不过C++很有名气罢了。
另外,程序设计方法论未必OO压倒一切。工控中有基于梯型图设计的语言,如PLC语言;也有基于状态机的语言(强制建模为状态机,把所有事务都看作状态机模型)。在具体的领域内,会有更适合的方法论。比如嵌入式系统的驱动设计,就是控制电路,反复按一定时序读写IO口,有何OO可言?诸位大多都是(国内)计算机科班生出身,耳睹目染的就是WIN平台,就是VC,就是Java/C#,所做的工作有大多跟用户界面打交道、做业务的居多(比如数据库项目、ERP、B/S等)、做界面的居多(满脑子都是窗体、按钮、对话框),就根本没用C做过大型开发,没做过底层开发,没做过工业级的项目,难免会过度崇拜OO,会认为其他设计模式一无是处。这个没关系,见得多了也就识得广了,识得广了也就不说偏激过火得话了,我相信时间、经验会改变认知得,没必要今天决出胜负高下来。
把OO紧紧的绑定在语言内部,就注定这种语言红得快死得更快(java已经走过高峰了,C#的新陈代谢速度比java快)。庆幸C没有紧紧绑定某种方法论,否则能不能活过30年还真不得而知呢!~
flyingleaf
re: 对用C做开发时"C的劣势"的总结
把OO紧紧的绑定在语言内部,就注定这种语言红得快死得更快


说的好。路过,支持一下
Diviner
re: 对用C做开发时"C的劣势"的总结
C的使用范围已经很小了...
小明
re: 对用C做开发时"C的劣势"的总结
据说美国军方使用的是Ada语言,而不用C,Ada有严格的类型检查,比C++/Java都要严格。美国军方开发的应该不是小软件。

引用:
把OO紧紧的绑定在语言内部,就注定这种语言红得快死得更快

怎么说呢,不管什么时候走路都是不会被淘汰,但是这个不是我们拒绝使用任何高级的交通工具的理由。汽车有一天也会被淘汰。

flyingleaf
re 小明
怎么说呢,不管什么时候走路都是不会被淘汰,但是这个不是我们拒绝使用任何高级的交通工具的理由。汽车有一天也会被淘汰

//我怎么说呢?如果什么时候能够不走路了,那才牛比呢。
Diviner
re: 对用C做开发时"C的劣势"的总结
我同意小明的看法,要是担心淘汰的话而不去学习某种东东的话比较那个。
周星星
re: 对用C做开发时"C的劣势"的总结
我不反对7cat的看法:
只要它存活的时间大于你需要使用它的时间,那就值得学。

所以俺不介意 在MIS/ERP上使用Java/C#,因为一个MIS项目维护时间再长,也长不过Java/C#的存活时间。
但俺不会在96年去学dbase,不会在97年去学Foxpro,不会在98去学VB,不会在99年去学dephi,不会在2000年去学Java,不会在2001年去学C#,……,因为它们“辉煌”而短暂的一生比不上我的编程生涯长,虽然它们其中每一个都比C简单,但把它们都学会的性价比 比不上 学一门C。

不用OO举例子,因为OO太简单了,学一下即使没多大用也没有耗费多少时间。
pAnic
re: Diviner
呵呵:
有些人担心自己被淘汰所以拼命学习最新的东西(事实上这些“最新”的东西多半都是很久以前就有的,比如C#在2001的msdn中就已经存在了)。
还有一些人担心学习的那个“东西”被淘汰而对其不屑一顾。:)
一笑
to jason //re: 对用C做开发时"C的劣势"的总结
请你仔细看完那个链接中Explore More中的例子及左边导航栏里面的链接再发表评论。~
乾坤一笑
to jason //re: 对用C做开发时"C的劣势"的总结
偶还是贴出来吧,现在现在肯踏踏实实看完(看懂)人家文章再发言的人太少了。
前面那篇就是封装(不知道你对“封装”两个字是怎么理解的,封装是OB的概念不仅仅是OO的概念,一个初学者都知道C在语言层面都支持封装)。下面是继承和多态:http://www.eventhelix.com/RealtimeMantra/Basics/ComparingCPPAndCPerformance2.htm
乾坤一笑
re Diviner & pAnic //re: 对用C做开发时"C的劣势"的总结
《射雕》中七公教郭靖降龙十八掌,教黄蓉逍遥掌等。郭靖只会一掌一掌的劈树,心无旁怠。七公说自己纵横江湖多少年到最后才知道花拳绣腿都没用还是一掌一掌劈的实在。翻回来想想做技术,现在的编程语言成千上万种,各家公司又都有自己的Framework,全部涉猎谁能样样精通?少之又少吧。对于初学者而言,一门都学不精,就贪多硬嚼,难上加难,白白的把自己的时间和精力浪费掉,不是自戕又是什么?
小明
re: 对用C做开发时"C的劣势"的总结
羡慕"一笑"只需要守着c就可以混饭吃的生活

对于大部分开发者来说,不得不学习"花拳绣腿"来混饭吃

而且我相信学习是一个循环反复的过程,就像一个螺旋式的上升过程,也许练过花拳绣腿才能体会"野球拳"的精要。简单的"一掌一掌"很难达到高境界。

最近看到学习的四个境界:
不知道自己不行
知道自己不行
知道自己行
不知道自己行

很有意思。
我想我还是处于"知道自己不行"的境界。

周星星
re 小明:
不要羡慕别人,表面上看来是生活决定了选择,其实是选择决定了生活,有的人之所以认定为前者,只是给自己的不如意一个可以怨天尤人的理由而已。
比如你,从“守着c”的“守着”两个字就可以看出你个人认为C不行了,而VB\Java\C#等才是正道,于是你选择……,选择带来的结果就是……。你给自己开脱的理由就是“因为C不行了,所以上天迫使我选择……,而结果就是……,因此我可以埋怨上天”,但上天说过C不行了吗?你一定说"Yes",我不想争论。
(我知道你是在暗讽,但我假装不知道)

如果你的螺旋式过程是上升的,我诚心恭喜你,虽然螺旋多走了冤枉路,但结果总是上升的嘛。
但我比乾坤一笑悲观多了,我认为软件开发在这10年中从未变化过,因此对于个人而言,也就无“上升”之可能。我认为在这十年中,只有三类人,一类是坐在原地乘凉的人;一类绕着固定圆圈气喘吁吁的狂奔并以为自己与时俱进的人,傻乎乎的幸福感洋溢在他们脸上;第三类人就惨了,他们像第二类人那样癫疯着,却喊道“跑不动了,跑不到了,软件开发是年轻人干的活儿”,他们还出书立传,比如《30岁之后程序员何去何从》。

讲个故事:
一群人睡着了,其中一人梦话中说了一个字“屁”,其他人在梦话中齐声喝彩“好闻”,很久后有几个睡得不太死的问道“屁在哪儿?”,于是大家又陆陆续续的回答“没有屁吧,因为我没有闻到”,于是“屁”的故事结束了;
接着,其中一人梦话中说了一个句“大便”,其他人在梦话中齐声喝彩“好吃”,很久后有几个睡得不太死的问道“大便在哪儿?”,于是大家又陆陆续续的回答“没有大便吧,因为我没有吃到”,于是“大便”的故事结束了;
历史就这样往复着……………………。
为什么大家会对一个根本不存在的馅儿饼表现出强烈的占有欲,使之看上去就像真实存在一样?
我不想说“三人成虎”,也不想用《大腕》中的台词“广告做大了,假货就是真货了”。我想说
人人都知道“脑白金”是骗人的,但脑白金每天的销量仍然很高,几乎每个电视台有它的广告;
CCTV3已经报道了“吸油基”是从头到脚在骗人,但CCTV8每天还都放着它的广告。
俺们程序员是不相信“脑白金”“吸油基”的,为什么?因为你们比三姑八婆见多识广呀,你们应该去相信“跨平台之脑白金”和“吸油基.net”。
小明
re: 对用C做开发时"C的劣势"的总结
哎,又一次被周星星强奸了民意。
你确实擅长"推理",但是以你的脑袋来推理我的想法,你也太自以为是了。

在我看来,C没很多神奇的地方,跟Pascal,Fortran区别最大的还是语法上面的不同,为什么要神话C呢?要是C是完美语言的话,世界上为什么还有那么多C++/Java/C#其他语言呢。

实际上,在我的工作中,C/C++/Java/Perl/VB我都使用过,我并不认为除了C以外,其他都是bullshit. 你要是硬认为其他语言不过是"脑白金",我也没办法。

还有,你说
我认为软件开发在这10年中从未变化过,因此对于个人而言,也就无“上升”之可能
于理不通,即使是从未变化,但是对于个人来说,想掌握它也不是一朝一夕能做到的,为什么不能说上升?



周星星
re 小明:
你一定要说C不行,那我在上一篇就说了“我不想争论”。

在我看来,C没很多神奇的地方,跟Pascal,Fortran区别最大的还是语法上面的不同,为什么要神话C呢?
------ 各个语言的创造者都是吃饱了撑的,只是语法不同,好在你没有说只是26个字母不同。比如Fortran,为什么工程数学一定要使用它呢?如果只是语法不同的话,是不是可以用一个工具把fortran代码转化为C代码,然后用C编译器去编译呢?

世界上为什么还有那么多C++/Java/C#其他语言呢。
------ 
a. 用你的话说就是“存在就是合理的”,就如同"脑白金"一样,存在就必然有它的道理,当然,我已经解释过无数次了,存在就是合理,但未必对所有人都是合理的,比如脑白金的存在对"屎欲卒"骗钱就是合理的,对某些不上当,也不想利用它去骗人的人就无存在的道理。
b. 这种辩论是无意义的,因为我的意思是C并不落后,而你一定要把“C并不落后”解释为“其他语言没有存在的意义”,汽车不落后,所以火车就不应该被发明?
事实上我用得最多的就是C++,事实上我在这里并没有攻击过Java/C#,我说了“跨平台”和“.net”只是一个比喻义,前者不想说了,后者非常有意思,为什么.net?因为.net!这叫群什么意识来着

我并不认为除了C以外,其他都是bullshit.
------ 只是一个比喻,比如我用的最多的还是C++。
我想说的是要“不看广告看疗效”,不要被一层虚假的外表所迷惑,怎么个死法都没事,千万不要被“皇帝的外衣”给捂死。
yuzek
re: 对用C做开发时"C的劣势"的总结
关公战秦琼,有意思
little_white
re: 对用C做开发时"C的劣势"的总结
呵呵,鄙视C语言的人,觉得C语言不行了的人。
呵呵,是自己不行了吧??
unknow
?!测试一下发贴
执行效率<=====================================>开发效率
                            <-|->
                          |
       你想往哪一边滑动依赖于你对工具及目标的理解程度
totoro
re: 对用C做开发时"C的劣势"的总结
看了一圈,公说公有理,婆说婆有理。都不知道在争论什么。晕
zelor
re: 对用C做开发时"C的劣势"的总结
我以前只知道星星是C++粉丝,没想到也是C粉,呵呵。
“我认为软件开发在这10年中从未变化过。”这话深得吾心。醍醐灌顶啊。

总有人认为C已经死了,可惜在代码规模达到100W行的时候,只有C还存在着。
seraph77
re: 对用C做开发时"C的劣势"的总结
星星是强人,呵呵

我本身是个菜鸟, 不过现在刚加入的公司做的项目好像蛮大.
9400多个文件, 总有三四百万行吧..用的是C语言
看啊看啊,看的我晕乎乎....

也许C并没有oo(其实我真不大了解oo,因为我从未做过C++的项目,java那是根本不会),不过我觉得,只要你愿意,你可以用C捏出任何东西来. 想分几层分几层,想用几个状态机用几个状态机,想封装成啥样就是啥样...
一段内存空间,五六个模块各自有不同的实现...看得我目瞪口呆....
Abbey
re: 对用C做开发时"C的劣势"的总结
没想到大家争论得如此厉害,我也来插句嘴吧。我毕竟不是专业的IT人士,没有写过大的项目,所以我的井底之见有不对的地方,还请指正。

就我个人感受而言,开发语言只是我们实现目的的一个工具。就象砸核桃,有的人喜欢用石头,有的人喜欢用铁锤。石头的优势是随处可得,使用方便。铁锤嘛,就说它比较硬,不会被核桃磕碎吧(我这有种本地产的核桃,砖头也敲不碎)。使用何种开发语言,完全是个人喜好或者工作要求。没有必要去争论哪种语言更强,只能说哪种语言在进行某一类开发时更具优势、更节省成本。某一类语言也不可能就包打天下,要不然也不会出现当今N种开发语言百花齐放的局面了。当然您要批驳我“存在即是硬道理”或者说语言设计者想出名、想挖空心思挣钱也可以。

作为软件开发,比开发语言更为重要的是它的设计方法,也就是软件工程的内容。现在见到的软件开发的资料,99%都是讲的OOD的内容,我想这便是误导大家的原因了。正如一笑说的“程序设计方法论未必OO压倒一切……”,不同的软件需求,决定了应当采取不同的设计方法。OOD并不适合也不可能解决所有的问题。

同时,个人认为也应该注意到在具体的设计个例上,在实现应用的过程中,如果能更多地利用语言的优势,应该能更大程度地减少项目开发成本和维护成本。这一说,就又转回OOP了,Framework的确省了不少事。

所以这两年,我努力地想定位自己的发展方向,学习的内容也大多是软件工程方面的知识,Design Pattern和ReFactory是我期间最大的收获。就我目前的情形,C++/C#适合于我目前的数据库应用。毕竟学习语言通常是一件触类旁通的事,只是每一种语言的精通程序不同而已。

所以我想说,开发语言可能会过时,但软件开发的思想总会在历史上留下其浓墨重彩的一笔,甚至长期存在。语言为实现设计思想提供了工具,设计思想推动语言发展。

最后总结一句话:实事求是、因地制宜,仍旧是软件开发、程序设计的一条根本原则。

发表评论
切换编辑模式