Ruby 究竟有什么魔力？

HK-SHAO 我没用过Ruby，但我想指出的一点是，“语法复杂”在一些人眼里是缺点，另一些人眼里就是灵活的表现了；同时性能不好在一些场景中不算太明显的劣势，比如网络IO占绝大多数开销的情况下程序慢一点就没什么了，同是难兄难弟的Python性能也不是很好，但用的人还是很多，并且一些常用的函数全都可以用C加速

我之前看过《七周七语言》，记得作者十分强调的是Ruby的开发效率，所谓“不要过早优化”可以描述这种场景

HK-SHAO 要了解OCaml的魅力，你首先要学习函数式语言的理论，知道一点关于类型推导的基础常识，诸如此类的基础知识。如果你只是站在一个C、Python、Java程序员的角度去看，将什么都看不到。这就好比很多人听了一辈子流行音乐，然后问古典交响乐有什么魅力，其实很难回答。这里不是贬低流行音乐的意思，反过来同样适用。两个完全不同的世界，感觉上......

对ruby的印象和知识都还是来自于RPG Maker VX（一款人气很高的可视化脚本编程RPG游戏开发工具）
它的语言表达性还是要比python好一些，对于快速实现web应用方面比java略胜一些，不过从实际的工程方面考虑，国内可能懂的人不是很多。

工程最重要的是权衡，许多不同要素往往是相互不兼容的。花大量时间去雕琢一个设计精巧代码优良的C++实现固然好，但是人力成本和工期将会极高。《注重实效的程序员》一书中提到的将工期作为需求的一部分也是专业素养的体现。

真的要做比较的话，基于python或者node的方案可能在国内人气会更高一些。不过确实算是“难兄难弟”了，他们的优缺点和本质想要解决的问题大体相似：轻量应用的快速原型和快速迭代。同时使用他们后面有需要的时候依然有用更高效语言去做局部优化的空间。

Miigon 《注重实效的程序员》一书中提到的将工期作为需求的一部分也是专业素养的体现。

这也是我楼上 0x0001 想说的一点，我在工作后也有蛮多类似体会。除了设计一个优雅的实现，达成这个优雅实现的路径也很重要，大概需要一个 Roadmap，在有限的资源下，时间的预期、人力的安排也是一门艺术。这也是程序员更核心的工作量所在，代码只是这个过程的一个副产物。

业务起步阶段最关注的是一个探索过程，代码只是整个业务模型的一部分。一个矛盾在于，我们在投入实践之前，其实是没法知道我们究竟需要一个什么样的系统。就需要一些后知后觉的复盘总结，在下一次再做有一个更清晰的认知，去优化细节、重构等。

这时候，需要一个类似画笔和草稿纸的角色，快速达成一个原型供业务试错，待业务模型稳定以后，也就有了纯技术层面的项目的生存和发挥空间，大量的时间投入才有发挥出来的价值。

当然以上是从职业层面去看的，自己有能力、有充足的自由时间的情况下，就没有太多的限制，可以像一个艺术家一样，自由地选择你的侧重点（运行性能、开发效率、易用性、优雅的UI、赋予用户自由、开源 等等等等...），设计出符合自己审美、更加优雅和理想的软件。

lantern
贴一下原文，原文味更足一些：https://sites.google.com/site/steveyegge2/tour-de-babel

一个视角：该文章写于2010年，当时最新的C++标准还是03，

还有，C++好骂！（逃
reflection部分和toolset部分前阵子写Unreal的时候体会尤其明显（Unreal在C++基础上搭建了非常庞大复杂的对象反射和管理体系）

Stuff takes forever to do around here. An Amazon engineer once described our code base as "a huge mountain of poop, the biggest mountain you've ever seen, and your job is to crawl into the very center of it, every time you need to fix something."

That was four years ago, folks. That engineer has moved on to greener pastures. Too bad; he was really good.

按照2010年写文来算，2006年就已经有人在讲shi山这个词了