你要探索什么呢？看过逆向的代码完全找不到重心，什么都碰了，什么都只摸了一个 hello world，但另一面看过你在知乎上的各种回答，又安利大家用你的 Autumn，一个学习的东西就这样去推广了，确定不是害人？

而且，一个生产可用的 Web 框架，从 TCP receiving -> HTTP parsing -> Routing -> Requst handling -> Responding 每一个点里面都有无数的细节，而我们看到的就是一个很普通的玩具而已。

Midori 的路由是我协助完成的，功能不弱于 Rails，代码不多是因为我建议与其独立实现，不如直接使用 mustermann

这个库目前就功能上已经成为 Rails 所用的 Journey 的超集，但你读过 journey 的源码就会发现其实他也没花多少行就搞定了，而且我读过市面上几乎所有流行语言的流行的（或者代表性的）Web 框架，路由的设计 Journey 吊打全部，而且 Journey 是一个人独立完成的（Aron Patterson）

我说的是，我的框架是对象规则反射，而不是手动捆绑。

实际上....Rails 是直接支持你所说的效果，“约定优于配置”在这里是有体现的... 另外你提的 CI、CakePHP 都是抄自 Rails（或者我们说 Inspired by Rails 吧）

话说，Midori 搞出来也不难吧...

你写代码不上版本控制的么...

那你等开源的时候再说事啊，裤子先脱了，飞机也起飞了...可啥时候降落呢？

你不开源但是挡不住被逆向啊... 他不是这个意思，他的意思是“是骡子是马，拉出来溜溜”、“实践是检验真理的唯一标准”

你的发言都是先“造个大新闻”、然后“批判一番”、但是之后就“无可奉告”，你这样很让人“Angry”的，识唔识得？

另外，Rails 的路由都可以可视化的呢... http://tenderlove.github.io/fsmjs/ Journey（Rails 的路由库）的设计相当先进的

队长 Midori 的其实也可以，不过可能要稍微改动点东西

还真是会的，你装个最近的 RubyMine 体验下就知道了...

另外，你这个 C++ 实现的版本又要撞队长枪口上了...

你批评他无耻抄袭都比批评这个 DSL 的风格问题强...

他那个...你还不知道这个风格的源头是 Sinatra 吧。。。另外 JS 的 express.js 后来的 Koa，几乎所有的语言的“轻量级”Web 框架的风格都继承与此...

我一直以为写 Objective-C 的人会更容易接受 Ruby 的呢...

隐式转换有坏处，但是在接受范围内，显式转换，你为什么不去写 Idris？只要程序可以编译通过，是可以连逻辑错误都没有的呢

你设计的 API，你离职了，谁处理？

那不还是因为 JS 没有真正意义上的类型系统么... 缺陷居然被你说成优点了...

"Ruby 按照你要 new 的对象作为模型进行 new" 和“你 clone 了原型对象（对象拷贝），然后再利用这个对象来编程”有什么区别？

你这也是答非所问，API 没改过，上层程序当然不用改。

就算你答了我问的“怎样的设计保证了，底层改变，上层就不用改的？”，可“API 改写，难道上层就不用改么？ ”呢？

亏你还在我那个 FormCore 的帖子下回复... Ruby 的 class Foo 关键字，几乎等同于 Foo = Class.new

你也没解答 "API 改写，难道上层就不用改么？怎样的设计保证了，底层改变，上层就不用改的？" 啊

原型链继承跟 class-base-programming 有冲突么... es 6 的 class 还有 TypeScript 的 class 是什么...

Ruby 的继承还是靠祖先链完成的呢... 你到底是真懂假懂...

你要 DSL，可以，方便快捷，但是你得自主承担后期异常行为的风险，如果 DSL 底层一改，是不是你上层都要重写？

API 改写，难道上层就不用改么？怎样的设计保证了，底层改变，上层就不用改的？

换句话问，如果能做到这点，语义化版本是做什么的？

还有上次跟社区朋友 @dsh0416 的分歧，我看他比较喜欢 meta-programming（元编程），呃，我觉得没问题，只是，你要做好 meta constructor，而且，我觉得 meta constructor 是很不好维护的，这种东西可以节省你写的时间，但是你后期维护，如果你站在这个平台上去开发稍微有点规模的应用，我看不好办，就像 vue.js，你怎么都不能跟 React / Angular2 比，为何，我觉得他说的轻量，应该是代码量的轻量，你这个是 meta generator engine（元信息引擎），如果我要给你开发扩展，或者利用现有的模块再次拓展，很难，为何，因为你这样写相当于做了个微内核，啥都包含在几乎只有一个函数里面，扩展一般以 extend、mixin，你这只有一个独立的东西，叫我怎么扩展？所以这种东西再流行，也太 single 了点，如果你自己精力不够，打算放弃了，那么整个东西就彻底性瓦解了，因为几乎只有你一个人维护。

你这句话很容易证伪啊。。。（似乎已经证伪了）

1 block 是 ruby 的一部分，你若需要使用 Ruby，那你就要了解 block，

你说 JS 还能做类型检查，首先我们不讨论 JS 糟糕的类型系统，Ruby 对于 block，需要做“类型检查”么？不需要，用 block_given?

def obj.method(name, &block)
  str = "Hello #{name}" // 拼接 Hello 和变量 name
  yield if block_given?
end

这才是 ruby 风格的代码，Ruby 的语法设计，注重的是提高表达能力，你指出的场景很常见，所以 block 可以很好的屏蔽掉类似 js 那种传入函数作为回调时干扰视线的 function()

此外，这里反倒体现了 Ruby 的简洁，有一种场景 临时打开一个文件，做一些操作，关闭文件

正常的写法：

file.open()
// do sth
file.close()

如果你写过 Python、C#，你知道他们提供了 with 语法，这是语言提供的机制，而 Ruby

file.open(filename) do |f|
  # do sth
end

这是 open 方法自己就可以做到的一点，不需要语言提供支持。

2 这跟 Ruby 没关系，你用任何语言都可以写出这样的代码，yield 也不是 Ruby 的专利，既是不是 Ruby 的 yield，协程也可以产生类似的问题，不要把逻辑的设计怪罪到语言头上。

顺带装个逼，

根据 Kleene 正规型定理，任意偏递归函数都可以由原始递归函数经过一次极小化得来，所以写程序的时候如果发现两层以上的无限循环要格外小心，很可能逻辑是错的。

当你写出如此丑陋的代码的时候（任何语言下都可能发生），那很可能你的逻辑出了问题。

另外，Promise 是一种风格，你希望在 Ruby 中使用 concurrent-ruby 拿走

3 Ruby 也可以的啊，Keyword arguments，如果你认为这个风格好，可以用啊

4

还有的就是，Ruby 居然延续了 Perl Pod 文档的风格，各位可以自行用 perldoc 或者 man 看一下，总之这些文档只告诉别人传入些什么，不告诉别人返回类型，我当初写了几年 Perl，我发现 Perl 这样做很让我火大，dbm 有时候到底返回了哈希引用还是就是哈希，有些时候我要自己去试。

JS 不是这样？Python 不是这样？

这个确实是问题，有很多人吐槽过，Python 有 PEP484 虽然群众更希望 Python 2.7 一万年，Ruby 也在做类似的改进 —— Soft type https://ruby-china.org/topics/25428

JS 你恐怕需要 Flow（Vue 在用）、TypeScript 了，短时间看不到 ES 改进的希望，另外，ES 的类型系统... wat?

5

因此我可以推断，以 Ruby 为友，或许你会活得很累。

Matz 发明 Ruby 是在 93 年，目标是快乐编程，正式发布于 95 年，最终在 06 年 Rails 发布，彻底引爆了一波节奏，

Rails 的信条 之 程序员的幸福最大化

是 Ruby 造就了 Rails，所以第一条信条便是从创造 Ruby 的核心理念所提炼出來。

早期 Ruby 的极端邪说就是把程序员的幸福度放到第一位。还把追求幸福置于驱动编程语言与生态圈前进的考量之上。

06 至今，到底累死多少人了呢？

是个梗，前几天爆的中金公司某首席欲潜规则女实习生。https://www.zhihu.com/question/60327634

1 传统的方式是 def foo(arg1, args2, options = {})，这样你可以这样用 foo 1, 2, bar: 'baz', baz: 321，这也是 Rails 的各种 API 的设计方式。

第二种方法是双打散（double splat）操作符， def foo(arg1, args2, **options) 这样既可，这个是 Ruby 2.0 后的东西，用法同上，所以很多库的设计没有跟进，另外整个形参列表都不定的话用打散就可以了 def foo(*args)。

第三种方法是用 Ruby 2.0 的 keyword arguments，如果你想显式声明可选参数的话 def foo(arg1, arg2, bar: nil, baz: nil) 想可选的话，给个默认值就 ok 了

2 你可以用 1 的方法，让形参接受 proc 来实现，Ruby 的 block 每个方法，限定只有一个

另外说白了，你能做什么，做过什么，做得有多好，除了你自己，别人根本不会关心，这里不是面试。

搞一个 AR、Rails 出来，很多人都可以，有一个系列的课程就是教如何去设计一个 Rails 出来（Rebuiding Rails），你在另外一个帖子介绍 Autumn，这个论坛很多人都玩过类似的了，包括你的那个想法，好几年前就有人做过了，你可以搜一下。

Ruby 的社区文化是 语言（或者语言的库）的设计者、语言（或者语言的库）的实现者还有语言（或者语言的库）的使用者三者分离，DHH 的最大功绩是发明了 Rails 的体系结构还有核心的 API，说白了就是 DHH 告诉大家要有什么，应该长什么样子，其他人跟上完善，Ruby 语言也是这样，其实你读过早年 Ruby 的实现就知道 Matz 的编程水平并不高明，但是有高手的加入，MRI 在 benchmark 上，已经超越了 py

另外 ActiveRecord 的模型做的事情其实很多的，毕竟 AR 源码剃掉所有跟数据库的部分还有将近 3000 行（当然也去掉注释和空行啦），这可是 Ruby 的 3000 行啊，这部分我就可以写出跟这篇文章长度相近的文章来，不过精力有限，这一节被我删去了

这里的问题不是做得出来的问题，而是仅用 20 行左右实现行为和 ActiveRecord 模型一致的动态表单模型（是 FormCore 的内部实现核心二十行不到），另外已经完成了，没完成的是文档、测试（让人相信可以大胆用的东西）

太遗憾了

其实这东西适用场景挺多的，可以把组合模式透明化啊，不过把方法代理到另一个 AR 实体确实有坑... 而且 AR 没办法自动 eager loading

@bhuztez 大会报销讲师的路费、安排酒店的住宿和餐饮，不解决安保问题...