sgissb1

sgissb1

V2EX 第 32435 号会员,加入于 2013-01-16 14:51:24 +08:00
来自蓝翔的网虫,菜鸡一枚。
根据 sgissb1 的设置,主题列表被隐藏
二手交易 相关的信息,包括已关闭的交易,不会被隐藏
sgissb1 最近回复了
13 小时 32 分钟前
回复了 u2gign 创建的主题 分享发现 这是真的吗?本打算买个 k40,看到这个有点犹豫
也希望 JC 同志管一管限制养狗的区域中有人养大型犬烈性犬的事情,反诈这个事情我们看到了!
上次打 110 ,说我们小区有业主养类似高加索这种犬只,特么一股不耐烦的样子,还说话和怼嫌疑人一样,就这样我们小区出入点还有公安联网的枪机,一大坨,看上去就带人脸识别能力的。。。。
13 小时 39 分钟前
回复了 MaMimi 创建的主题 分享发现 为什么有些文档的作者这么人上人
两个原因,因为伸手党太多了,出了问题就是有一定的懒惰思想,总想着别人帮他解决掉,或者最好包圆了。
另一个是“大佬”不在少数,说话做事很多时候只考虑自己的“立场或地位”。

反正看看就好,无所谓的事情了。
@nbndco 成功达成共识,不容易。感谢认同 ^_^
五年高考三年模拟,黄冈试卷,奥数习题册,蓝猫三千问

从中学到幼儿,我觉得 200 左右就可以搞定了,不算奇怪,替家长鸡娃,没啥毛病。当然如果是没有娃的同事收到,你可以让他送给亲戚的小孩,毕竟快过年了,也不方便问人家小孩的成绩之类。
7 天前
回复了 fy1206 创建的主题 职场话题 公司裁员了
@hhjswf 这个可不好说哟,如果公司经营问题,那就正常咯,你说正常不正常。
但如果公司经营没啥问题,就非要干掉一个或若干个部门的人口数量,这事吧,大家慢慢琢磨。
7 天前
回复了 fy1206 创建的主题 职场话题 公司裁员了
@fy1206 两个原因:
1 ,换能效比高的人。引入竞( nei )争( juan )机制,优( juan )胜( dao )略( dui )汰( fang )
2 ,管理手段,一群人在一起时间久了,就会形成小圈子,圈子建立时间越长就越稳固,老板想要推动什么事情,就很有可能容易出现阻力,破局一些有形和无形组织(具体可以参考体制内一些常年没有人员变动的部门,具体理论解释正在管理学原理里面)。
@nbndco 我觉得讨论的有偏了,我们讨论的焦点在于两个:抽象成本、性能;会引出这个的原因,在于你提到语言特性会影响(决定?)这两个因素,我提出的是,我认为主要因素在于人,语言特性是次要的。

首先我还是不认为某个语言特性就决定了他的性能,人的因素比较大,结论的原因在于:
理论和工程实践很多时候就不在一个视角上,我并不了解你工程实践中大多数是什么情况,但是我的情况是,不管是 x86 汇编、c 、c++,横向对比(特定语言中),人的因素远远大于语言特征。

另外你说的 c++标准库的这些东西,我看上去感觉你是想阐述程序设计中的问题,比如你提到的抽象成本问题。这方面,我是认同的,但是问题来了,这又会导致什么性能问题呢?在 tr1 特性或者说 c++11 出来之前,类似智能指针、作用于锁、安全对象和非安全对象等等就已经有不少实践了。我能看到的是,其他语言在这些方面上提供很多丰富 runtime api 来完善这些,但不代表他们的实现就是最优的,或者说,不是第一个版本的实现在当时主流硬件+软件环境就是性能最优,也是需要多次迭代来实现。

实践这么久,写代码,就是谁做得多问题,是语言 runtime 一侧多做一些抽象和设计,还是使用者这一侧多做一点。
@sgissb1@nbndco 原因是逻辑和模块的设计实际上未必和性能挂钩。

这句话我更正一下,没写清楚。

我是想说,语言是语言,程序设计是程序设计。性能的好坏更多是程序设计所致,语言不是决定因素。
@nbndco 我不太认同你的观点。原因是逻辑和模块的设计实际上未必和性能挂钩。

真的能挂钩在一起的,我觉得更多是程序设计上的问题,我不认为有哪种语言可以做到绝对的灵活而且性能还能做到厉害到没什么语言可以打败的。

越简单就性能就是越好,越复杂就是性能很难做好。
首先 c 本来就不是面向对象,就没有太强的抽象能力,需要抽象能力的就要用 c 的近亲 c++(这里只谈论 c 和 c++)。那么很多时候都在说,c++的一些性能不如 c ,不是因为语言所致,而是模式所致( c++是部分面向对象,必然会有很多额外的开销,c 就不需要)。
go 接触过几天,rust 不了解,但据说语法各方面和 c++有一些相似。其实在我看来,你也可以去修改一个开源的 c++编译器,让编译出来的 release 代码做到最精简版本,你看性能好不好。另外 c++的开发维护难度高,还真不一定是模板问题,多数是 c++语言特性过于复杂,中二 c++程序员太多(过于自认为很了解 c++,搞出一堆问题来,不用模板,就一个继承和多态,在真实的项目中就能玩倒一片人)。

回到程序设计上来说,在程序设计的规模复杂度渐渐变大的时候,有时候会感到性能变差和维护变难。这个事情需要分两头看(排除写代码的人能力问题的话),一个是程序设计所致,另一个所谓的语言特性。

前者呢,可能是认为有一的变慢速度,比如一个事务,本身就要保证可靠性,那么一个巨大粒度的事务必然会比小粒度的慢。比如错误的使用多线程,导致竞争问题等等。
后者呢,比如一些代码需要编译成中间语言,运行的时候需要再做一次翻译,或者第一次运行需要翻译等等。

现在很多流行的语言高性能语言,说到底,就是把程序设计下沉到编译、解析层面。比如 go 的协程,就尽量的规避了中二程序员对线程在工程实践熟练度不高上引入的性能可能地下问题,然后由语言特性来包装起来,本质内部其实是固化了一定的程序设计模式在里面,简化和让程序员的程序设计模式更为确定和减少范围,以此来综合性的获得性能收益。所以 go 的早期版本里面为了解决调度、内存池、同步问题,自身的 runtime 里也有不少相关的 bug 在一点一点修改。

就像在 iot 或者低功耗设备里面,如果要用 python 、go 等等非 c/c++语言是完全可行的。但在一些特定功能或者模块上,用起来性能就有可能不如纯 c 的。为什么?一位内这些语言已经囊括了一定的程序设计模式,c 本身在这块会比他们更轻量级。

所以我还是觉得,本质还是程序设计的问题。过分强调某种语言如何如何我觉得没什么必要,关键在是好不好用,使用场景是否恰当,我记得这也是《设计模式》这本书里提到的一个重要观点。

我主要写 c++,但我也常常写 shell 和 python ,其实在很多地方,我就觉得 python 比 shell 、c++用起来更方便,shell 权限性大一些,c++太重。有些时候 python 性能不够的一些个人小服务,我会试着拿 go 来写,尽管 go 、的一些库的编译和依赖问题有时候让我比较抓狂,但奈何用起来方便,快捷。

真正商用场景,还是需要看哪一种语言用起来更合适,因为大家都有自己的特点。我以前也很喜欢推崇 c/c++,甚至觉得 vc 的方言版本就比 gnu 或者其他编译器的方言版本强的,但工程实践这么多年得到的经验,还是适用才最重要。
其实用啥语言不重要,重要的是开发者敲键盘时,输入的代码逻辑和组织结构。

go 语言世界里,有不少项目是太过依赖语言特性了,这也导致了软件工程的表现各不一样。语言之争也是这么延续下来的,以前说 XX 语言好坏,那是硬件受限比较大,现在硬件都已经快不少了,软件基础设施也迭代不少了,互联网 ctrl+c ctrl+v 水平也在稳中趋升。还真单纯的纠结语言问题就没啥意思了,除非是某某语言创始人。
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   3461 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 8ms · UTC 01:19 · PVG 09:19 · LAX 17:19 · JFK 20:19
♥ Do have faith in what you're doing.