我留下了太多稿子... 看来会有做不完的事情了

上个暑假了，我花了一个星期的时间去整理，把这类东西加以注释发到频道上来，可是看起来，好像还是按照优先级归类排着做好呢。

解决了科学上网问题，需要在修好的笔记本电脑上弄个 ArchLinux 并且安装合适的软件。

啊，刚才才发现你说了这句话…… 😟
好同意啊，我刚刚的消息里也是这个观点，能写成表达式的为什么要弄个函数？能用内部 DSL 的为什么要弄个 XXEL？

……或许是为每一个主语是集合的命题定义逆命题太麻烦了，比如 list.all {...} 是不是得定义一个 list.notAll : List<T>.((T) -> Boolean) -> Boolean -- (exists (not . f)) 呢？此外你还能在 Collection<*> 里找到一大堆输出和接收命题方法(single, exist, filter, find, partition, takeWhile, …)，是不是都要支持 not……
不过 !in, !is 这两个关键字倒是存在的
标准库的简洁（这里指的是最终输出组件包的简洁性，代码简洁性可以用 codegen 工具）和用户的需求有时候不能两全，其实有这种方法也未尝不可，不过利用名字上的区别的话…… 可能有点鸡勒了

Ruby 是直接搞了个 unless... 完美解决了所有这类问题

……当然这其实一点都不完美，对于我们这类母语不是英语的家伙，这种语法对初学者是相当疑惑的，尤其是知道 if 和 unless 肯定是则一而选的分支逻辑的时候，我当时看到 if unless 并存的子程序是想死的心都有了！

我个人觉得，既然 (p as Boolean).not() 一下就可以了，多写个 ! 也不是件难事

我之前也在 Python 里写了一个支持命题的函数组合库，有一个 notp(q) 函数能够直接定义 notNone = notp(emptyq) 如果这类检查常用，利用多态和 method extension + infix 也未必不是办法

a 对了，说起来我之前为了一个 Spring 的项目 context path 绑定写过一门 DSL，既然大佬写这类程序，为何不也设计一个专门的 DSL 来定义接口？Swagger 实在太难看了，前端写东西果然就是只会用 existing 的 markup language……

我觉得我们应该感谢他们是 JavaScript 风格的程序员，不是 Java 风格的，我可懒得为了一点 boilerplate 去写 XML 这种更大更危险的 boilerplate。 😵

别人说 Mongo 是面向文档的数据库，我感觉和 RDBMS 有多大差别么…… 😓
反而还更莫名其妙一些，起了一大堆新名字

其实这种数据处理的话，就是 Kotlin 的 collection method extension 大概也能完成吧…… 名词一大堆一样

我很讨厌 Spring 在弄那个 url mapping 的时候很多 boilerplate

我见过不少人说自己对代码有洁癖，但我对任何代码真的是看不得一点重复……
一有重复我就忍不住想解出模板、一见到瞎写的控制流我就想把代码挂出来瞎喷一遍……

一般来说我对自己不理解的算法、模型（比如关系数据模型的 1:1, 1:N 什么的）都会写 N 遍，往往是写第二三遍的时候我会开始能够把代码缩短成原来的 3/4，如果原来的代码非常冗杂的话可能是 1/2，甚至是 1/10

所以我想……

为什么一个应用程序，里面居然能够放这么多重复的名字？

我看到的时候，立刻就浑身发毛，或许这真是我多虑了
但我真的是觉得那些程序本来就不应该是这个样子罢了…… 我是一个重复的词都不想见到

同意……
其实我原来也就是想发点不能编译的代码

我觉得 Kotlin 的 enum class 真是太好用了，如果你不想写专门的辅助类，它可以做到很奇特的效果

而且可以辅助你进行更远的设计

/tmp/a
我忘记 Telegram 发文件带名字了……
UNIX-like 平台上是不看文件后缀名的…… 普通文本编辑器都可以打开

还好括号是匹配的

我莫名觉得这个关系模型有点复杂啊…… 是因为没有图示的原因么 😭

下次会的，你们这次就不要太较真…… 毕竟，代码比用什么写代码重要，是吧？

我这里的代码，其实指的就是你说的『程序的灵魂』

我觉得还是蛮不错的啦…… 如果你写的缩进正确的话

比如 Kotlin 的 when (with value)

fun name(x: Any) = when (x) {
is Boolean -> "bool"
is Number -> "num"
is String -> "str"
is Array<*> -> "ary"
is List<*> -> "list"
is Map<*, *> -> "dict"
is Exception -> "error"
is KFunction0 -> "callable"
else -> "any"
} 总比没省略 is 左侧表达式的要好看吧

还有 where("user") 后面的一堆 point-free，其实只要缩进明白一点看起来是只会更优雅，不会更难看的

—
假设这里的 point-free 是
p :: (t -> Bool) -> (t, t, t) -> Bool
p f = \(a, b, c) -> (f a b) & (f a c)

p elem ("ABC", "A", "B") --True, "A" elem "ABC" & "B" elem "ABC"

或者

f a b = a + b -- f = (+)
f' a = \b -> let op=(a +) in op b
f1 = f 1 -- = f' 1 -- （因为有 currying 实际上是一样的…… 不像 Scala 有 partial application）
(f1 0, f1 1)

这类
只有目的不是很纯（比如为了进一步缩减代码文本的体积）才会让代码更难阅读

import Data.Char (digitToInt)
atoi base = foldl (\ac -> (ac*base +) . digitToInt) 0 -- str
这里我们 point-free 约掉了包括高阶函数 foldl 的第一个函数参数的参数在内的两个参数…… 啊好饶舌的说

对了原语是什么
那那个原来的意思是啥

还是 Haskell 好，notContains 就是 not . elem…… 否命题直接函数合成（跑

Kotlin 那个 self （function type with receiver）搞得一些泛化的函数类型上的操作符有点麻烦，有些的东西必须弄两个版本……

不过我想一般很少有人会用 T.() -> R 这种，比如写 subparser 组合库的时候，都是 (Parser.Stream) -> T 这种

第一种我想 Java 侧怕不是不方便……