领导力大挑战
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
该内容已经被标记书签!
标记书签错误,请重试!
作者 郑柯 发布于 2012年2月6日
珠三角技术沙龙组委会成员、发起人之一赖勇浩近期的一篇博客引起社区内热烈讨论。他在其中认为:C++是2012年不宜进入的三个技术点之一;其他两个是:ActionScript/MXML, 线程。
赖勇浩对于“不宜进入”的定义是:
如果你现在不是这三个技术点的专家,并且手上没有使用这三个技术点的项目,进入这三个技术点仅为技术储备,那么就“不宜进入”。
至于为什么不宜进入,赖勇浩认为根本原因在于:
标准化过程中的超长流程,一次次将 C++ 推向深渊。
接下来,赖勇浩首先回顾了20世纪90年代:
其实在 90 年代,计算机的运算能力有限,市场上非常需要一款性能较高、抽象较强的编程语言,C++ 获得了成功,但它标准化的时间过长,造成各种编译器有各自互不兼容的“方言”,成了它的第一个软肋。
然后,赖勇浩又指出:“C++ 在 21 世纪的第一个十年里仍然地位稳固”,其原因在于:“Linux 和 MacOS X 大获成功,在这两个平台上 C++ 都是非常有竞争力的编程语言,C++ 自然水涨船高。”
但是,赖勇浩提出开发效率成为阻挡更多人采用C++的另一个因素:
但随着 web2.0 和 web app 概念的兴起,以及 CPU 的主频进一步提升,服务器端编程语言渐渐地对执行效率不再敏感,而是更在意程序员的开发效率,众多的脚本语言开始蚕食 C++ 的市场份额⋯⋯新兴的贵族是动态语言。面对动态语言在开发效率上的强劲挑战,C++ 社区除了在 2003 年对 C++98 做了小小的 patch,基本上睡着了,完全没有应对之策,哦不,连应用的姿态都没有。
在赖勇浩看来,
进入 21 世纪的第二个十年,⋯⋯在这个十年,我们需要这样的编程语言:两句话其实也可以压缩为一句:需要有更好的并发模型的语言。
- 能充分利用现代 CPU 的计算能力,不仅仅是多个核心,更是巨大的 L1/L2/L3 Cache、超线程等;
- 能够大量减小异步 I/O 的性能提升的同时带来的副作用:异步编程的复杂性以及对可维护性的伤害
上述主要针对服务器编程领域,在桌面和移动领域,赖勇浩认为:
rust 会进入桌面开发,google go 肯定会顺道啃一口。而移动设备方面,⋯⋯编译型语言加脚本的模式就会占大头⋯⋯C++还是前景堪忧。
最后,赖勇浩的总结是:
回首 C++ 的 30 年,展望它的未来,总结起来可能就是:标准化流程拖死人了。如果不是 15 年不能标准化,java/c# 的搅局可能不会出现;如果在 2005 年能够应对动态语言……如果云时代有更好的并发模型……
对于赖勇浩的观点,知乎上有人提出质疑,知名C++程序员陈硕做出了回应,他认为:
C++目前坚守的阵地:服务端基础架构(例如淘宝OceanBase是C++写的),PC客户端的3D游戏(DirectX是提供COM/C++接口),某些嵌入式上的(准/软)实时程序,其他Java/C#/Python未能涉足的领域(会遇到C的抵抗)。如果你正好在这几个领域,我看不出有担心的必要。
陈硕还指出:
C++目前仍然是最快的语言(见 google language benchmark 论文和 shootout.alioth.debian.org/)。如果你的应用领域确实在乎这个性能⋯⋯那么 C++ 仍然是不二之选。
技术博客酷壳的博主陈皓对此次讨论也发表了一篇博客《Why C++ ? 王者归来》,他在其中引用了Herb Sutter的一次演讲,Herb Sutter是Exceptional C++和C++ Coding Standards的作者、ISO C++委员会的主席、C++/CLI首席架构师、Microsoft的软件架构师。这次演讲是C++ and Beyond 2011上的一次公开演讲。
陈皓在文中摘取了本次演讲的幻灯片,并做了一些注释和内容提要。 他首先指出:
为什么C++?因为 Performance per $,也就是说performance 就是钱,这个分成三个方面,
- 耗电,芯片的耗电量,移动设备的耗电量,家用电脑的耗电量都和钱有关系。
- 资源,家用电脑和移动设备上的处理器资源有限,因为要让一般消费者买的起。
- 体验,在更小的设备上会有更好的体验,有更好的体验就可以挣更多的钱。
此后,他也回顾了C++的历史,并借助幻灯片中的一张表格指出:
如果把我们的对编程语言的需求总结为四个:效率,灵活,抽象,生产率。那么,C语言玩的是前两个,而C++玩的是前三个,Java和C#玩的是后两个(抽象和生产率)
任保一种设计都不可能让你什么都要的,这就是Trade-Off——什么事都需要交换的。
接下来,陈皓从移动设备、数据中心两个角度,说明了C++的性能效率的重要性,同时还指出:
当然,不是C++不注重 开发效率,看看C++0X的标准引入了多少东西我们就知道了。但是本质上,C++还是致力于性能和抽象的完全平衡。
目前仍在进行的2011 InfoQ读者年度深度调查中,有超过30%参与调查的读者主要使用的语言是C和C++,也欢迎正在阅读本文的您参与调查,告诉我们您使用哪些语言,同时也可以在文后留下您对本次讨论的想法。
郑柯 InfoQ中文站总编。做过开发,当过PM,干过销售,搞过市场,最终还是回到媒体。实用的理想主义者,相信:每天改变一点点,这个世界会更好。
那个叫陈硕的trade-off都能译成交换,水平真高,trade-off是平衡、妥协的意思。
您看的真清楚,后面那个是陈皓,不是陈硕了。。。
C++的堕落不仅仅是标准化过程的问题。C++的设计还是过于复杂,缺乏现代语言的一些基本特征,又保留了古老语言的渣滓。如果不是在效率方面还可以,简直就一无是处了。
C++过于机器语言,性能不应该等同就是要求低级。语言应该可以进化的。不同语言可以相互竞争的,C++的使用范围将逐渐缩小。软件的进化跟不上硬件的日新月异的升级。编程语言原生地支持多核并行、内存管理、完整集合框架、IO、网络通讯、互操作、组件化、可测试特性、安全特性等基础设施,也就是从库中迁移到语言层级,我认为这是其进化的一个方向。
从《Why C++ ? 王者归来》coolshell.cn/articles/6548.html 表述的意思来看,Trade-off非要翻译成“平衡、妥协”就有点锉了。
而且,那算不了翻译,只是解释性能与抽象的平衡.
如果你运行一个Saas,每天面对服务器,电费,机架租费,你就知道C++的重要了。
人家原文就是这个意思,而且trade-off在外国的技术文章里经常出现,从没觉得理解成原意有什么问题.
如果在InfoQ上讨论关于C++的内容,那它就是太老了,太不敏捷了。
在一个大家没有选择的年代,时代选择了你
在今天日新月异的时代,请大家关注其它更多选择。例如我就关注于Go, Rust语言。
www.cnblogs.com/chrome
c++复杂?没觉得啊,不就是多个指针吗。
c++落后?并发异步什么的该有的也都有啊。
c++0x标准出来后正是学c++的好时候!
为什么C++?因为 Performance per $,也就是说performance 就是钱,这个分成三个方面,
耗电,芯片的耗电量,移动设备的耗电量,家用电脑的耗电量都和钱有关系。
资源,家用电脑和移动设备上的处理器资源有限,因为要让一般消费者买的起。
体验,在更小的设备上会有更好的体验,有更好的体验就可以挣更多的钱。
C++之父说要让汇编也能跑...
不同的系统,采用不同的语言
自己搞不懂,还在乱说。C++的优势岂是你等鼠辈能了解的。
语言本身何必要支持那么多,有官方发布库来支持更多的特性足矣,java不就是很多官方库来支持么;语言还是要做成小核心,确有必要的东西才做到语言中。
完全同意,写个本地自己一个人处理下excel文件之类的,何必c++,写个高性能通讯交换的,你用脚本语言试试看。一个大的互联网公司,我不信他们没有用C++的。
‘效率’两个字足矣,不过汇编效率更好,为啥比C++用的少多了?
“如果不是在效率方面还可以,简直就一无是处了。”,成立么?
在实施Scrum项目的过程中,Scrum Master的角色是相当关键的,因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述,同时重点阐述仆人式领导者应有的基本内外特征。
论道WP第三篇专栏,以应用程序栏的使用为中心,包括了软键盘带来的问题、应用程序栏介绍、如何绑定应用程序栏的属性等几个方面的具体话题,为开发者顺利使用应用程序栏开发提供了具体指导。
在多线程并发编程中Synchronized一直是元老级角色,很多人都会称呼它为重量级锁,但是随着Java SE1.6对Synchronized进行了各种优化之后,有些情况下它并不那么重了,本文详细介绍了Java SE1.6中对于锁的性能优化,以及锁的存储结构及升级过程。
本次分享将首先介绍现代富文本编辑器的组成和实现,然后结合UEditor的开发过程,与参会者分享UEditor在设计和实现的过程中,所涉及到的核心功能的细节实现。
本次演讲视频录制于百度技术沙龙。
我们所开发的应用程序大多都需要提供一个图形用户界面(GUI)。关于GUI应用的架构设计,已经有了Form & Control、MVC,、MVP、 Passive View等多种模式。模式可以帮助我们建立优雅的架构,但前提是弄清楚模式的应用场景。弄清楚GUI应用面临的设计上的问题,有助于我们正确的挑选设计方案。
MongoDB是一种非常易用的NoSQL方案,Brian C. Dilley在这篇文章里介绍了MongoDB的优劣势,并介绍了MJORM项目。MJORM用于MongoDB,是一个没有注解的Java ORM库。
随着网络基础设施的逐步成熟,从RPC进化到Web Service,并在业界开始普遍推行SOA,再到后来的RESTful平台以及云计算中的PaaS与SaaS概念的推广,分布式架构在企业应用中开始呈现出不同的风貌,然而殊途同归,这些分布式架构的目标仍然是希望回到建造巴别塔的时代,系统之间的交流不再为不同语言与平台的隔阂而产生障碍。
17 条回复
关注此讨论 回复