我过去搞的不太值得学习 (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 适合表达的领域。而且如果不考虑存储因素的话化，这个需求本质上就是一个链表计算。因此把计算过程和存储分开思考，解决方案的适用性会广很多。

@wootaw 别闹

翻完评论才看明白什么意思。我觉得这个计算逻辑不适合用 SQL 做，因为它的关注点并非在集合，而在集合中的每条元素。用两个链表做计算（递归比较头节点）反而更容易，计算结果再保存进数据库就行。

如果有非常特殊的原因一定要在 SQL 里实现，可以看一下 lateral join 和 with recursive 。

PG 文档上都有，见 4.2.7 Aggregate Expression

{} 跟 do ... end 的区别只在于跟前面的方法结合的优先级，简单来说 {} 会 “紧贴” 它前面的方法，而 do ... end 更加宽松。

我看楼主之前有过几个帖子讨论语言的设计优劣问题。但说实话纠结这些并没有太多意义，更多是结合个人偏好的主观问题。倒不如多了解下各种语法的客观差异，避免踩坑，然后总结出一套符合自己偏好的编程方式和风格干活。

确实 query plan 不同，感觉 CTE 更严格的按照每一步去划分优化的边界，而子查询作为一个整体查询有时候会优化得更多一点。所以我一般是测试时写 CTE 然后转到代码里再换成子查询。这样也更容易转换成 app 层的代码。因为 Elixir 的 Ecto 可以写出非常复杂的分析型查询，但目前还不支持 CTE 。

Emacs 有个插件能帮你对齐，也是你说的 river 风格。不过 Emacs 的对齐功能基本都有点自恋 + 死不认错，人工调整后编辑器也会不停的帮你 “纠正” 过来。想调整规则得去研究类似 AST 的数据结构，所以我直接放弃了……