我们展开来讨论一下
首先我认为做软件最关键的是人,工具不是最关键的。这一点我们应该没有太大分歧。但是我同时认为当事情进入实际操作的时候,工具的选择与应用同时也反映了人的理解。
“但凡一直存在下来的就说明其是有生命力的”
我在两年前工作所迫还用过awk,但是我相信awk不应该出现在任何一个新项目里了。我觉得如果不是历史原因限制,大家就不倾向于选择的工具,就是基本上失去了生命力的。包括perl, dephi,甚至C++。
“我不是编程大牛,其实我一直的感觉就是写程序是一门艺术,是艺术就意味着不应该是任何人都能随便拿起来就作的事情。说实话目前大家努力的方向就是想尽办法让编程越简单越好,但我总认为这是值得商榷的方向,因为不是每个人都能成为艺术家的,即使你给他再好的乐器和画笔。”
诚然赏心悦目的程序对于能够欣赏它的程序员来说就是艺术,但是创造语法简单而功能强大的语言更是艺术。我个人不倾向把软件当作艺术对待,knuth作为学者可以,对于大部分程序员我们还是有很多艺术以外的追求。对于我个人来说,software is all about handling complexities。毕竟很多客观上达不到一定标准的人每天都在用着入门级的技巧来创作可能不是那么“艺术”的程序,从而实实在在的改进着人们的生活。我认为这应该得到尊重,如果有可能应该给他们提供更便捷易学的工具。在计算机的世界里,我们是有可能提供一门语言,即方便使用且追求工作效率,又符合深层次的一些思想。现在的主要脚本语言接近这个目标,但是C++是没戏了。写到这里发现这个题目有点大,回头如果有时间专门讨论这个话题相关的。
“C++确实缺少一些缺省的实用库,这确实是个问题,但好在有一些无私的大牛还在做这方面的工作。”
关键是boost包的稳定性和实用性还是达不到某些情况下的要求,也是C++先天不足的一个侧面证据。
“至于脚本语言也不是为了取代C++之类语言而诞生的,反而两者可以很好的结合。”
Ruby和Python与C都是无缝接合,毕竟解释器都是C写的。但是我实在看不出来有C++什么事情。
最后,我认为项目伊始,选择正确的工具是非常关键的,也是靠量对问题/工具的理解的重要方面。这个问题不能简单地推给开发人员,指望他们用任何工具都写出符合要求的程序。目前来说一些好的语言特性,比如exception,iterator,generic support,oo purity,unit testing/doc support,metaprogrammin等等,在C++里面支持的非常不自然,template metaprogramming简直就是不可能维护的东西。Java则在SE5以后支持,但是boxing/unboxing,annotation之类的东西仍然不自然。而Ruby/Python基本上就比较自然了,即使如此Python3000仍然宣称不会backward compatible,就是为了避免像C++一样被绑在历史包袱上。具体到实际的使用,自然是脚本语言效率更高,更不容易出错,新人更容易理解高级技巧,写出符合规范的代码。
乱弹
2009-05-14 18:23:30可以开个主贴讨论。蛮有意思的。