不是指重新实现一遍 python。回复内容：
greenspun’s tenth rule，与君共勉：any sufficiently complicated c or fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of common lisp.
谢谢邀请。这个问题的目的有点可疑。读过这里的大部分回答之后，我的感觉是，也许我们都误解了提问者的意思。我猜提问者的意图跟 python 没关系，真实的意思是：「我们能不能把尽可能多的 c/c++ 常用功能塞进标准库，让 c/c++ 程序员不再需要打理各种细节」。至于所谓「达到和 python 的开发效率」，只是一个比方。如果我的猜测没有错，那么我的回答是：可以，但只在具体的领域有效。熟悉分布式程序设计的老程序员可能会记得 corba 和 ice。corba 是老一辈的分布式架构，c/c++ 绑定时用的是 c 字符串类型；而 ice 则直接用了 c++ 标准库的字符串。不仅如此，ice 大量用了 stl 标准库。具体到开发效率时，ice 的 c++ 绑定确实让我省去了大量时间折腾 corba 里的 c 字符串分配和释放问题，做个小应用确实轻松了很多。但为什么我说只在具体领域内有效？因为 c/c++ 的定位决定它存在巨大的限制。仍然是字符串的例子：有谁知道有多少广为使用的 c++ 库没有实现自己的字符串类么？icu、wxwidget、qt、mfc，还有很多流行的库，都这样重新发明着轮子。我无意追问为什么我们会面对如今这种混乱的情况：这是个历史问题。无论如何，c++ 使用库碎片化已经是事实，无法如果。既然不能如果，现在再谈重建标准功能库，就只能限定在某个具体的框架里，比如 mfc，比如 qt。在这些具体的框架之内，确实可以有比纯利用 c++ 标准库高得多的开发效率。唯一的问题：请别超出框架的范围，不然就可能给自己惹麻烦。那么，在理想情况下我们能不能达到 python 的开发效率？也许可以吧，不过如果理想都达不到，我想我们还是别讨论了，立足现实更好些。
c/c++本质上是raw memory processing语言如果你不需要处理原始用户态内存，却选择了c/c++，说明你不理解c/c++因为你放弃了这两个语言最有用的功能
你说的是用 c/c++ 写个 dsl？
不能。你会花和python差不多的时间构思。python两倍的时间打字。python一百倍的时间编译。比以上加起来还多十倍的时间debug内存越界和野指针。
c++的时候觉得最影响开发效率的我觉得是没法像python那样对什么东西都可以print出来。和成熟的logging日志库来帮助调试。所以在开发c++的时候自己写了一个头文件库。没有依赖，就没有伤害。直接include进来就可以使用的。https://github.com/yanyiwu/limonphope it will help
首先回答问题，不行！（仅回答c++语言）从语言本身角度，c++不是为了这种生产环境设计，就算再多的类库，再多的补丁，实现再多的python功能，她还是c++，该有的c++功能还是有，而更多功能当然带来更复杂的逻辑，所以并不能像python一样快速开发。而且这个c++库恐怕会大到普通pc无法容忍的地步，编译时间和大小都不是普通用户能承受的。但是！！如果拥有一个非常大的类库，确实大大增加c++的学习成本，同时增加c++的复杂性，同时，c++的源代码会变得比较简短也是事实，如果库写的不错，代码简化之后和python差距不大，或者更像一种神奇的c++类似的内存自动管理语言。我现在刚接触了一个非常大的c++库，现在正在学习，个人感觉就像在用一门完全陌生的语言，各种调用都要查询很久文档才能写出几行代码，但是如果熟练的话，应该能够做到原来c++至少一半的代码量就解决相同问题。
为什么不理解成：有人为了用c/c艹语言实现高开发效率，最后发明了python呢？你觉得cpython里的c是啥意思…
objectivec 嘛 开发速度快 但是执行速度慢
c++11 + stl + boost 的开发效率大可与 python 一战，不过编译速度不能比
for (auto x : { 1,2,3,5,8,13,21,34 }) cout