#32 楼 @fsword 譬如想在 lotus 上写个分页插件或者上传插件，会发现每个层都要修改，这分页插件的 api 怎么设计头大得很... 当然 rails 也要，不过层数少点更容易做

#33 楼 @benzhang 这样划分也可以，entity 专注无 IO 的内容，带 IO 的方法提升到 repository 中去，单元测 entity 就容易很多，repository 的方法可以放到集成测。不过和很多 java 项目类似，结果往往是绝大部分代码都会落到 repository 中去，而 entity 只剩下一个只带属性的空壳子...

至于不连接数据库，只用 memory adapter 模拟持久化的做法，也不是 repository pattern 专用的，ActiveRecord 也能做到，但做多就变成 OODB 了还不如不用数据库和 ORM 了直接上 maglev gemstone

#11 楼 @bluecoda 你这是还没学 rust 做对比，单方面的说 go 好而已

#19 楼 @ksec pixelmator 对绘图板支持不好，无法设置笔触压感对应画笔大小还是出墨量，而且论坛上官方表示近期都不能自己设置。pixelmator 也没有舒服的快捷键设置办法...

开源的绘图软件的话这类反馈回复会更快，可配置性也更高，这种问题大不了自己改

go 发了 1.3 也改变不了丑陋的 design decision 啊 就像感冒传播很快，那感冒就是有益的咯？

如果编译模板的时候翻译资料就完整了，那么 ruby 也有更快的 i18n 翻译法

例如 https://github.com/slim-template/slim/blob/master/doc/translator.md 把 tr_mode 设置为 static 的话，运行期就不会调用 i18n 了。

就是把 i18n 翻译编译成了 pattern match 的函数，如果 i18n 的数据来源是数据库并且要实时更新 (例如翻译人员输入) 的话，就不行了...

#4 楼 @bhuztez 理念是 more classes

#25 楼 @fredwu

repository 和 entity 的逻辑不是说分就能分的. 如果一个方法既包含业务逻辑，又包含持久化动作，应该放到 repository 还是 entity? 如果放到 repository, 它就必须有 entity 的知识，如果放到 entity, 它就必须有 repository 的知识。如果将两者完全隔离，那么这种方法就要放到更高一层，放到 controller 中，当 controller 膨胀了，就会想到加个 service 层... 层数越来越多，架构越来越 fancy, 做实际事情的代码却越来越难找...

AR 中拆分逻辑也很容易啊，可以 extend, 可以加 scope, 方法多种，又不需要定死在一个 repository/entity 的划分方式中，一开始就强制拆分开来把很多本来简单的 model 都弄复杂了。

#16 楼 @rasefon ruby 做算法原型很容易的，ruby 的整数具有任意长度的 bitset 的全部功能，利用 bitset 的算法直接用整数就可以了

#16 楼 @blacktulip 哦对... 反正就是类似的...

#12 楼 @yfractal 老子那个一是道，二是阴阳，三是天地人，然后就是万物了，和自然数的递推关系没关系啊

#7 楼 @yfractal 和老子的话意思完全不一样，如果一样的话，早几千年就做出计算机了

#31 楼 @outman 嗯，除了 redlock 以外，还有软件事务内存的做法，如果跑在 maglev ruby 上，就能用软件事务内存了并且可以保证多进程多机器事务一致性... 还有 100 核机器每秒万个事务之类的变态 benchmark, 不过貌似没见过人部署 maglev 的...

这是 Church number 的自然数定义。出发点就是你除了 lamda 以外什么都没有，推出整个数学体系的各种定理 (例如 1+1 = 2, x + y = y + x 等等). 最基本的第一步就是建立整数体系。

首先是 0 怎么定义？我们猜把 identity 函数定义为 0 可能比较好

0 = λx.x

1 是 0 的后继数，2 是 1 的后继数，我们想到 f(x) 这种形式可能适合作为"后继" 的表述

1 = λx. f(x)

上面这样写不行，f 哪里来不知道，所以我们套一层，重新定义 0, 1, 2, ...

0 = λf. λx. x
1 = λf. λx. f(x)
2 = λf. λx. f(f(x))

假设我们有数字 n, 我们先要从数字的定义中取出 x, f(x), f(f(x))... 来

n(f)(x)

然后给多套一层 f()

f(n(f)(x))

所以

add_1 = λn. λf. λx. f(n(f)(x))

#28 楼 @outman

第一种应用常见情形，是维护用户自身的数据一致性。

例如用户既有比特币又有狗币，系统提供自由兑换的功能，那么比特币账户和狗币账户都内嵌到用户模型中就好了。然后对这两个账户的修改就是针对单 document 的原子操作。

当然还有很多事务都是典型的一个账户打钱给另一个账户，或者顶贴积分 -1, 这种内嵌做法就不适用了...

那当然，就和 and, && 的区别一样，都是为了省括号费尽心思

#17 楼 @outman 事务又两种解决方案：

一种是把事务涉及到的模型都设计到一个文档中用原子操作搞定，当然如果单文档会变得巨大就行不通了，这时可以用另一种方法，把事务涉及的主要对象 id 作为 key, 用分布式锁管理系统例如 redlock 锁定。

直接用 coffeescript 就好了，JSHint 提示的问题基本都不会出现

一看 model 的各种 EJB 名词就关了...

正常脑子都会想到 instance 和 class 而不是 entity 和 repository, 语言提供的设施不用，自己造一堆是为何...

+1

#3 楼 @bluexuemei 大概我记错了... 这样？

File.open(f, "r:utf-8", &:read).sub(/\A\xEF\xBB\xBF/, '').encode 'gbk'

File.open 会自动判断是否带 bom 并跳过

#9 楼 @debugger 先全部取到内存中，然后按用户分组弄吧，2000 万数据其实就几百兆而已

#3 楼 @duobei 和 F# 相像多一点，毕竟 ML 不是 lazy 的而 Haskell 是，ML 允许 mutable data type 而 Haskell 不允许

#29 楼 @WolfLee 是语法层面啊，运行时几乎一样的，Swift 编译的程序可以运行在以往的 Mac 和 iOS 上，就是因为基本用的 OC 运行时

#25 楼 @fsword swift 已经比 OC 好了，而且可以做很多高层次的优化，OC 的一些代码是没 swift 快的... 而且 OC 语法已经没办法救了，ObjC++ 完全是个怪物... swift 相对于 OC 可以看作 coffeescript 之于 javascript, F# 之于 C#, Elixir 之于 Erlang 的程度，多好

1. 我会告诉你可以去掉括号这么写吗？func makeIncrementer() -> Int -> Int { ... }
2. 等边三角形模型，画图或许有用...
3. 参数名称在外部使用 obj.f(a, g: b) , 对应调用 objc 的 API [obj f:a g:b], 所以现有的库都可以直接转化成 swift 的调用

#18 楼 @_kaichen 赋值运算符改变了变量名指向的实例很正常，关键是一个 append 方法改变了指向的实例 ... 把 append 改成 <<= 运算符就更直观点