这不是我想表达的重点…… 其实都是两种语言里的不同特性，放一起比较也没什么意义。想了解你可以看看 Elixir 。

只拿 Elixir 举例，我个人是觉得函数式的写法更灵活点，最主要的原因是函数不用绑定 this ，所以数据和行为（函数）可以更自由的组合。这也是跟 OO 最大的差别。代价就是因为每次数据和行为组合都要严格指定，代码必然会更多，所谓的更 explicit ，比如 user.save() 和 Repo.insert(user) 。

比如有时会碰到 “一个数据在不同的业务场景下有不同的关注点” ，在 Rails 里就代表一个 model 有多种不同的功能，它们可以用 concern 实现并混入这个 model ，这是一种 mixin 的方式。另一种方式是用 ContextA.do_something(some_model) 的方式来处理，把每个业务场景下的逻辑放在自己的模块里。函数式基本就强制你使用后者了。更复杂的逻辑可能涉及多个函数调用，就可以用 pipe 描述成 params |> ContextA.get_model() |> ContextB.calculate() 这种方式，简化一下函数嵌套。

为什么说链式调用没有 pipe 灵活？因为 obj.do_something 的前置条件就是这个方法必须归属于调用者对象，有时这是一种限制，导致必须用继承或 mixin 来组织代码以达到复用的目的。所有链式调用都可以写成 pipe 的方式，反过来未必成立。

@zzz6519003 @Rei 如果是这样，那确实没有用。反而怎么写都没有 . 简单。从语言层面来说我觉得 Ruby 也没必要关注 “给现有功能多一种表达方法” 的事情，这就不是语言设计者该做的事情。

@jasl Lisp 据我对 Emacs Lisp 有限的了解，它允许 variable 和 function 用同一个名字，比如变量和方法都叫 foo ，执行再会根据使用场景辨别到底是哪一种。这大概是 Matz 说它们不属于同一个 namespace 的意思。不过这跟 Ruby 有什么关系，以及为什么会影响这个 issue 就不知道了。

语法不管怎么改，含义还是类似 Elixir 的 pipe ，把上一个操作的返回值变成下一个操作的某个参数，让代码组合变得更容易。有些场景下 pipe 比链式调用泛用性更高。链式调用的缺点之一是必须把函数混入进某个 object ，导致 object 承载多个部分的功能然后变得臃肿。

一开始会，后来…………后来你就习惯了

我过去搞的不太值得学习 (Ruby) ，现在搞的更不值得学习 (Elixir) ，放弃的那个最值得学习 (JavaScript)

倒着看就是最值得学习的语言排行榜？

感觉就是熬夜，饮食不规律，少运动，深夜看手机，并非完全是加班的原因（虽然跟加班肯定有关系）。

我有段时间干一白天，晚上就想熬夜看手机，因为感觉自己累了一天就这么点放松时间还不赶紧利用起来。但其实这样更累。正确的休息方式恰好不是玩手机打游戏。真正让精神放松的方式包括听音乐，冥想，出去散散步（哪怕 10 分钟），小睡一下等。当然这个意识得靠自己慢慢培养了。

首先我更支持平级非嵌套的资源表示方式，即 /animals/:id ，如果要限定 zoo 下的 animals 可以用 /animals?zoo_id=1 。但在有一个唯一标识符 (ID) 的情况下就没必要嵌套了。用户访问他看不到的资源应该通过其他方式来限制。

其次建议 LZ 多了解下 RESTful API 的定义。不是 Rails 的那套 DSL 定义出来路由的才叫 RESTful 。嵌套资源也不是所谓的标准风格。理论上只要用统一的 URL 表示资源就可以算是 RESTful 的，就算你用的是 /animals?id=1 。它是一种架构风格但不是规范。而资源有个统一的 URL 的好处是它的常规操作只用修改 method 而不是 URL + method 。并且这种统一风格可以让大多数资源受益。

最后说一句，如何设计好的 API 跟内部怎么实现是两码事。

@wootaw 是的，如果按照 LZ 的计算过程描述，其实是有不少中间数据的，比较过程化，这并声明式的 SQL 适合表达的领域。而且如果不考虑存储因素的话化，这个需求本质上就是一个链表计算。因此把计算过程和存储分开思考，解决方案的适用性会广很多。