西西河

主题:庆祝Python跃居世界第四程序语言 -- 空格

共:💬100 🌺284 新:
全看树展主题 · 分页
/ 7
上页 下页 末页
家园 python3.0 支持嵌入输出,输出格式不受pytho

python3.0 支持嵌入输出,输出格式不受python本身的缩进影响。

家园 不过浏览器太复杂

各有各的标准和实现。比如对于HTML5中的LocalStorage,WebDB各家互有不同。

不过自从JS打败java applet独占浏览器之后的确地位很稳固。而且JS的有些思想(比如基于原型的对象)和“主流”语言大不同很有特色。OReilly那本金斑碟的书是经典~

家园 这应该是经典的MVC应用

程序代码和数据(页面)混在一起是很糟糕的。

家园 VC确实很难,原因很多

VC确实很难,首先C++就博大精深,永远都学不完,永远都不算精。想要上手,至少也得认真学个半年。然后呢,要学习掌握整个Windows编程体系的知识,熟悉200个左右的关键API,再把VC的内部封装法则搞透了,才能开始真的编程,而不是编玩具。这个过程对于计算机专业人员而言我认为起码要2年,还得是认真学才行。

Delphi就不一样了,随便学点就能做很多应用层的东西了,而且是有用的东西。只是想要深入底层搞厉害东西,那这个过程和上面学VC一样,起码2年,因为离开了控件的使用,其内部知识体系其实都是一回事。

家园 mfc是最糟糕OO设计的典型
家园 替C++说几句话

一方面恭喜python,这个我也很喜欢的语言;另一方面,还是替我最爱的C++说几句话。

我主要是用C++的,几种脚本语言包括Python也有在工作中用过一段时间,总体感觉是,用脚本做工具做小应用真快,用C++做的话真憋气,比如遍历一个目录下的所有文件,还得去查API和标准用法,Windows跟Linu下还不同。可也有场景我脚本程序里要写一些比较偏算法的代码,这个时候我就感觉相反,查来查去也没个简单自然的办法操作,把人急死;要是换C++几代码就搞定,多解气。

但是我认为C++不输在语言层面,你要是把C++当脚本用,从来不用什么多态什么设计模式也没什么问题,而且看着也很简单清晰;而C++的主要短处是缺少支持应用的标准库。STL库里提供的东西其实还是偏编程层面,而非应用层面的东西,比如一些容器和算法之类的都是最最基本的东西,往上呢?最多找找boost看看有没有多一点点。像regexp,网络,线程,GUI,大多都是你自个去查API或到网上搜别人的库,找到的东西还经常是一个操作系统一个用法的,有些库还常有陷阱,不熟的人一不小心就中招,更别说像MFC这种很强但更难学难用的东西。还有像容易出错的内存管理,这种这么底层的东西到现在还会去烦大多数C++程序员,而且还是很多C++程序员用以吹嘘自已技术的好材料。还有编译链接这种问题,没啥技术含量也没啥意义,却每次得花时间和精力去弄好。用C++开发应用就像让人造房子的时候给了一个无所不能的工具却什么材料都没,需要先找泥巴烧砖,或去找铁矿烧钉子出来,这让人憋屈的很。

希望C++有天能把应用层面的标准库建立起来,再搞个跟那个TCC一样的东西,可以不用编译直接运行C++,那天我就可以说“整个世界终于清静了”,真是要啥有啥了。

通宝推:铁手,
家园 取决于工作领域

编程领域如今多种多样,很多是做WEB,数据库前端或者企业管理软件,这些软件对性能要求不高,主要是对数据的组织和界面管理。这些方面如果用C++来做等于自讨苦吃。但是很多人据此来宣称C++过时未免目光过于狭窄了。不用说别的,各位每天上网用的浏览器就是C++做的,还有大部分OS的图形界面,PHOTOSHOP/OFFICE这样的主流桌面程序,更不要说主流的游戏软件多数都是C++做的。迄今为止C/C++仍然是软件业的支柱,不能说因为自己每天的工作是刷油漆挂窗帘,就因此说地基和大梁过时了。

很多人说C++过于复杂,这个我部分同意,但是完全没有那么夸张。我想很多人是因为从VISUAL C++(也就是MFC)开始学习C++,因此认为C++难学。这恐怕是学C++最差的入口,因为MFC的设计一塌糊涂,完全是应该被扔进垃圾堆的东西。把C++的几个关键概念,包括指针(来自C),虚函数,模板搞明白了,整个C++也就差不多了,其实并不是很难。

PYTHON一类的脚本语言未来只能还是建筑在C/C++之上,因为性能不够。JAVA号称性能已经赶上C++,却始终未能在桌面程序中立足,我个人感觉JAVA程序在实际应用中还是慢不少,尤其是启动速度。况且JAVA未来前途未卜。其实我倒是希望有另一个更简洁优雅一些的高性能语言能取代C++,像D语言,GO等看起来有前景不过还是太不成熟了。

家园 这句要花

不能说因为自己每天的工作是刷油漆挂窗帘,就因此说地基和大梁过时了。

家园 不知您是否读过这篇文章

这篇访谈改变了我成为一个程序员的想法。时至今日,我仍在想,他说的是真的吗?

  C/C++的思索 C++之父访谈录

  

  

  在1998年的元旦,Bjarne Stroustrup(C++之父)接受了IEEE《计算机》杂志记者的专

  访。编辑很自然的认为他会对于过去七年来使用他创建的语言进行面对对象设计做一个

  历史性的回顾。而在这个专访中,记者获得了更有价值的新闻,但是最后编辑决定为了

  整个IT产业,这个稿子不能发表,但是就像其它被砍掉的新闻,往往还是弄得路人皆知

  的。这一篇适当时专访的完全拷贝,没有被编辑、删改或者做过什么润色处理,也没有

  发布

  过,可能看起来不像常见的杂志文章,但这是实情。你会发现真正引人入胜的地方...

  ...记者: 您在几年前你改变了软件设计世界的面貌,现在再回首往事您有什么感想?

  Stroustrup: 事实上我在你到来之前的这些天里一直在考虑这件事,你还记得几乎所有的人都在写C程序那会儿吗?麻烦的是这些人写得太好了,而且那些个大学也都在努力的传授C编程技术。的确他们是十分的成功——我要特别的指出“成功”这个词——因为这种显著的C程序员的培养效率,这就是产生问题的原因。记者: 这难道是个问题吗

  ?Stroustrup: 当然,你记得大家都在用Cobol语言写程序的时候吗?

  记者: 哦,当然,当时我也一样。Stroustrup: 在一开始的时候,这些人简直象半个上帝似的拿着高工资,享受着贵族一样的待遇。

  记者: 唉,那些日子多么的让人怀念,是吧?Stroustrup: 当然了。但是接着发生了什么?IBM觉得这样不舒服,就投资了数百万来

  培养程序员,直到程序员多得一毛钱就可以雇一打。记者: 这就是为什么当时我撤出来了,工资在一年里就降到人们在说做个记者都比程序员强的地步。

  Stroustrup: 对啦!那时侯相同的事情发生在了C程序员身上了。记者: 这个我明白了,可是您要说的是……

  Stroustrup: 有一天,我坐在办公室里就在想如何能把这件事挽回一些。我想知道如果有一种特别复杂而且难以学会的语言,是否就没有人可以又把程序员们搞到市场的泥潭里去呢?我用了从X10里了解到的东西,,噢,就是X-Windows,真是一个该死的图形系统,只能运行在那些个SUN 3/60的机器里,哈!它具有所有我想要的特征:可笑而复杂的语法,含混的功能描述,还有伪装的OO结构,就算是在现在,还是没有人愿意用那些

  东西,如果你不想发疯的话,Motif才是唯一解决方案。记者: 你是在开玩笑吗?

  Stroustrup: 没有,事实上还有另外的一个问题,UNIX是用C写的,就是说任何一个C程序员都可以很容易的成为系统程序的开发者。还记得一个大型的主机系统应用的开发者通常能挣多少钱吗?记者: 你肯定是知道我当时就是干这个的。

  Stroustrup: 好吧,因此这个新的语言一定要通过隐藏所有的系统调用来和UNIX分离开来,这样可以使那些个就只是知道DOS的人也可以活得很体面。

  记者: 我不大相信您说的这个……Stroustrup: 而且到现在时间也够长的了,我相信有很多的人已经指出了C++是对时间的浪费,我要说的是,这个过程比我想象的要长的多了。记者: 那么您又是如何做到的呢?

  Stroustrup: 那只是一个玩笑,我真的没有想到人们会对那本书那么认真。任何人只要长了半个大脑也应该明白面对对象编程是荒谬而不合逻辑的,而且效率低下。

  记者: 什么?Stroustrup: 再说代码重用,你什么时候听说过有公司重用他的代码?

  记者: 事实上从来没有,但是……

  Stroustrup: 那么我提醒你一下,在早期有很多的例子。哦,有一家叫Menter Graphics的俄勒冈州公司,我认为他们应该是感冒了,竟然在90年或者是91年把所有的代码用C++重写了一遍,对不起,我实在是想不起确切的时间了,我看大家应该从这个事件中吸取教训。记者: 没有人真正的吸取了教训吗?Stroustrup:没有,而且还有很多公司同样的错误,还向他们的股东解释说那3亿美圆的损失是正

  常的,他们就是做了这样的事情。记者: 真的?可是这也只能证明OO方法是能够工作的,不是吗?

  Stroustrup: 也许吧,执行文件是那么大,在一台有128M内存的HP工作站上只是装载到内存中就要用5分钟时间,然后将象毛毛虫爬树一样的运行。事实上我在第一个礼拜就发现了这个缺点,奇怪的是好象没人在乎这个,Sun和HP好象只在乎买出那些功能强大的各种玩意儿,而不在乎在上面跑什么程序。在AT&.T的时候我编了一个“Hello

  World”程序,简直是难以置信,执行文件有2.1M。

  记者: 那么大?是啊,就是从那时候开始的编译程序产生大个的文件的。

  Stroustrup:就是这个样子,如果你不信的话,可以用最新版的g++试一下,你得到的东西不会小于0.5M,而且就在最近也有一些在各个国家的例子,比如在British Telecom公司发生的灾难,但是幸运的是他们把原来的计划废弃了,又重新开始,他们就比Australian Telecom公司幸运,现在我又听说Siemens公司又在造“恐龙”了,他们目前是越来越担心要用来加速执行软件所要使用的昂贵的高速硬件,难道你真的认为那些个多态继承是一种乐趣吗?记者: 噢,但是C++的确是一种可靠的语言啊!

  Stroustrup: 你是真的相信的,对吧?你有没有真的坐下来用C++开发过项目?我来告诉你会发生什么:首先,我会加入足够的缺陷来让那些微不足道的模块先执行,让工作超载,在工程扫尾的阶段,你回发现几乎所有的模块都会有这种缺陷,这是因为人们以为就是应该这样做,因为在C++的教程中就是这样写的。在相同的模块中执行不同对象的相似操作意味着:有一些东西在各个模块中是完全不相同的。当你有了互不相同的上百个这样的模块,就可以把他们集成在一起了。其次,我再说说所谓的数据隐藏,上帝啊,当我听说了有的小组实现了什么对象协同通信,我真的是憋不住想笑!我看,OO方法中的“协同”这个词可以把项目经理的肋条累断。

  记者: 我不得不说着太可怕了!你还说这是用来提高程序员的工资,这太龌龊了!

  Stroustrup: 龌龊?不是这样的,任何人都有选择的权利。我是并不想让事情发展成这个样儿的。不管怎么说,我基本上还是成功的。C++现在已经不行了不是?而且程序员现在还是能挣到高工资的——特别是那些还要维护这些该死的“++”东西的那些程序员。你应该明白如果你去维护一个不是由你开发的C++模块是不可能的。

  记者: 怎么会这样的?Stroustrup: 你糊涂了?还记得typedef吗?

  记者: 噢,当然。

  Stroustrup: 知道要在头文件里发现象’RoofRaised’这样的变量是一

  个双精度数要用多长的时间吗?想象一下要在一个工程里所有的类定义里寻找那些typedefs... ......

  ...记者: 那么你为什么认定你已经成功了呢?

  Stroustrup: 还记得一般一个C程序项目要多长时间吗?一般是6个月。这对于一个要养活妻子孩子的程序员是不够的。如果是一样的项目,但是用C++来开发,会怎么样呢?

  我告诉你:要一两年才能做完!这不好吗?就是一个小小的编程语言选择的决定,语言程序员就不会轻易的下岗了不是?而且那些个大学已经很久没有传授C了,现在是对C程序员的短缺。特别是对UNIX编程熟悉的程序员。在使用了这么多年的“new”以后,而且一直以来一直都不用担心返回值的问题。还有多少程序员知道使用“malloc”?事实上,大多数的C++程序员舍弃了返回值,无论什么样的结果,甚至于返回了“-1”,其实用不着什么’throw’、’catch’、’try’之类的东西,至少你应该知道产生了错误。

  记者: 但是继承的确不是可以节省很多时间的吗?

  Stroustrup: 是吗?你注意过C项目计划和C++的项目计划之间的不同吗?在进行了三次系统功能分解后,要确定所有的东西都可被继承到,如果没有那么说明还是有错,但是有谁在C编程里听说过存储渗漏这个说法?现在你可以在业界的大厂商的产品中发现了!有很多的公司不得不放弃了,并且把工程转包出去,他们知道最后可能象筛沙子似的把内存站用完,他们才不想遭那份罪呢!

  记者: 也有一些工具来……

  Stroustrup: 大多数的防渗漏的工具不还是用C++写的。

  记者: 果把这些东西发表了,我们可能在这个行业里无法立足了,你知道吗?

  Stroustrup: 我不相信,就象我所说的,现在C++已经是在垂死挣扎了。任何公司只要清醒,就会认识到用C++来做项目简直是一场灾难。如果还没认识到这些,那就是活该!有一段时间我使劲的劝Dennis Ritchie用C++重写UNIX。

  记者: 啊?天哪!他是怎么说的?

  Stroustrup: 我不得不承认他的洞察力,我想他和Brian在很早的时候就清楚的明白了我的意图,但是从来没有说出来,他说如果我愿意的话,他可以帮我用C++写个DOS。

  记者: 那么你写了吗?

  Stroustrup: 事实上,我写了,我完成后可以给你一个DEMO,我在机房里的一台4个CPU的Sparc 20上做的,运行得特别的快,而且只占了70M的硬盘空间。

  记者: 有For PC的版本吗?

  Stroustrup: 现在你在开玩笑了,难道你没见过Windows 95吗?我认为它是我成功标志之一,

  记者: 我也总是在想关于Unix++,还是有人在试着搞这么个东西的。Stroustrup: 那是因为他们还没有看到这个采访手迹。

  记者: 对不起,不过依我看,我们恐怕不会刊发这些东西的。Stroustrup: 但是这是个世纪故事,我只是想让我的程序员伙伴们记住我为他们做了什么,你知道这些个日子里C++程序员可以挣多少钱吗?记者: 我所听说的是一个顶尖的C++程序员一小时可以挣到70~80美圆。

  Stroustrup: 知道了吧!而且我打赌他肯定可以挣那么多!!单步跟踪我放在C++里面的那些gotcha,并不是容易的事了。在在项目中使用C++的所有特性即使是有经验的程序员也会感到困惑. 事实上有时侯我也是觉得挺难受的,虽然这个特性是为我的初衷而做的,我几乎喜欢上了这个语言。记者: 你的意思是说你以前是不喜欢的?

  Stroustrup: 我是狠它的!难道你不同意它是挺笨重的吗?但是当那本书的版税源源不断的……我想你能够明白这些。

  记者: 等一下,关于参数的定义,请您一定要回答,您是否真的改良了C的指针。

  Stroustrup: 呵,我也是总是想知道这个。一开始我认为我做了,但是有一天我和一个刚开始学习C++的程序员讨论了这个问题。他说:“他从来就不知道他的变量是否被引用了,所以我还是在使用指针,那个星号总是在提醒我。”

  记者: OK,一般在这个时候我一般是说:“Thank you very much.”,但是现在用在这里好象还是不够。

  Stroustrup: 答应我一定要发表。

  记者: 好的,我会通知您的,但是我已经知道了我的编辑会说什么了。

  Stroustrup: 谁会相信呢?你能把这盘录音带给我拷一个吗?

  记者: 可以

家园 不知您是否读过这篇文章

http://www2.research.att.com/~bs/bs_faq.html#IEEE

家园 这篇文件恐怕不是真的

愚人节的笑话之一吧。

家园 C++过度设计了

C++想兼顾性能和语法的简洁,结果搞出难学习、难实现、易出错的语法标准。

比如说重载。这玩意就为了程序员看起来方便,引入了极其复杂的name mangling机制,这一隐式转换的过程又没有被标准化,弄得各个编译器编译出来的东西互不兼容,C++的库也没有办法向后兼容到C,结果又必须引入export关键字。它看起来使程序员做的事情少了,实际上为了理解到底调用了哪个重载函数他们必须花费更多的时间,也增加了出问题的可能。其实这一过程应当能显式地控制,用类似C1X里面的type-generic macros,把重载的表显式地写在程序里面。

更不要说模板了。这玩意一引入,哪个地方写错一个字符,哗啦哗啦好几页的出错信息。C++标准里面也没有对模板调试的内容,弄得IDE也处理不了,编译器出来的东西也没法读。

光讨论设计上怎么自洽,怎么简洁,不考虑如何去实现它,也不考虑他的客户也就是广大程序员会怎么用,这是设计者的失败

家园 语法是很末节的东西

而且我不觉得C++是在追求语法简洁,而是趋向于引进更多的功能。

重载的潜在危险是对C++诟病的标准论点之一了,但我个人这些年还想不起来哪次因为重载而造成程序混乱,不论是我自己还是别人的程序。所以我觉得,危险有,但是过度夸大了。实际上重载所应用的场合是比较有限的,有些地方,比如数学运算,如果没有算符重载写起来是很痛苦的。

对模版的看法就完全不同意了。调试起来的确不容易,但是从功能上说,正是因为模版,C++老树又发新芽,整个上了一个层次。STL在不牺牲效率的前提下,实现了通用数据结构和算法。而且因为模版对强类型的支持,经过编译优化的通用算法速度可以超过C。JAVA就是在模版上栽了大跟头。

C++就象一大车的工具,有些杂乱地堆在一起。程序员选择的自由度很大,因此如果滥用潜在的风险也大。它改进的空间当然是很多的,但目前及短期内,它所提供的性能与功能还没有其他语言能够完全取代。

家园 讨论一个特性的得失应当看它的机会收益

首先这里有一个各个编译器的name mangling方式的表格:http://en.wikipedia.org/wiki/Name_mangling#How_different_compilers_mangle_the_same_functions

这充分显示,重载的引入不是危害到单个的程序员,而是危害到整个C++社区。它导致:C++的函数库,如果不经特别处理,只能在C++里面。未处理的动态库里面的函数,C不能使用,Python不能使用,甚至连C++自己也只能由使用同一编译器的同一版本编译的代码来使用。微软当年搞COM的一个直接的原因就是C++ ABI层次上的不兼容,否则RPC的方案就足够了。这使得整个C++社区和Java社区那样,他们的成果很难在其他社区推广,而其他社区为了实现同样的功能,只能再去开发一套C的版本。

如你所说,重载的实际使用是很少的。所以让任一函数皆可重载这一设计的代价已经远远超过了它的收益。这一设计只不过是满足学院派对于语言内部自洽性的个人偏好。允许大部分的函数不重载直接出现在名字表中以向下兼容,同时提供特殊的语法来显示地解决重载问题,现在看起来才是最合适的。

同时我并不反对引入泛型。我只是不清楚Lisp里面两三页纸能讲清楚的问题,C++为什么要用好几本书。本来是很简单的一件事,可是有人却试图让所有的地方都适应它,同时为了简洁又不愿意多引入一些可以让它方便化的工具,最后就成了一个备受诟病的极其复杂的设计。

其实泛型完全可以变得更为简单。举个例子吧,我们经常看到极长的尖括号用法。为什么不能缩写一点呢。原因是,最简单的缩写方法是宏,而有些人已经意识形态化地把这个东西批判到死了,重新谈宏方法的简洁有效性,不是扇自己巴掌么。剩下的方法是typedef,可是他们又不允许去typedef一种模板。现在怎么办,他们只能用极其繁复的方法去搞什么"泛型编程",用一种初学者看起来高高在上云里雾里的方法去实现本来很简洁的功能。每次看到这些模板库实现,我都想狠狠地抽一下这些人,他们让很多人为他们的无知和偏执付出代价。

家园 C++的复杂度并不是由于VC/MFC的关系吧

对大多数程序员来说,从gcc开始比VC要更复杂。VC好歹还有部分WYSIWYG的功能,gcc对于大多数小白程序员来说属于学习曲线极陡的编译器。事实上,正是有一个学习曲线相对缓和的多的VC,C++的用户群才能扩大。C++的复杂度本身在于他横跨过程范式,对象范式和Generic Programming多种范式,同时还得保持与C的一定程度的兼容。实际上总体而言,C++属于精英语言,真不是培训班能培训出来的。有个比喻,C++如一把大刀,如果是个小孩子使用,非但发挥不了作用,反而可能伤到自己。C++的传世作品多,但出来的垃圾更多。相比诸如java和c#,跟使用人的水平不是没关系,但其关联程度不像C++那么大。

全看树展主题 · 分页
/ 7
上页 下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河