硬广！（本频道）必须挺！我写了一天啊

浪费了一天时间写了一篇纯函数式编程半通不通半理论不实践的教程…… 咱来谈谈范畴论

真正的无知不是知识的匮乏，而是拒绝获取知识；真正的理解也不是能懂得或者能造出晦涩难懂的知识，而是能把晦涩难懂的知识讲得通俗易懂。

啥时候我才能有一个这样的朋友，就不愁进步不够快了。

聪明的人学到了往往是只有自己学到了而懒得管其他人，不聪明但是很想聪明的人学到了却是大家都学到了，不知道知识到底应该何去何从。

“这个世界里，”汤川说道，“有些谜是无法用现代科学来解释的。但是，随着科技的进步，迟早一天，那些谜也会被人们解开的。那么，科学是否有极限呢？如果有的话，那么这极限到底是从哪里来的呢？”

汤川用手指着恭平的额头，说道：“那就是人。人的大脑。比方说，在数学界里发现了新的理论时，要验证该理论是否正确，就必须要有数学家们来动手检验。然而，如今发现的理论开始变得越来越高精尖，如此一来，能够检验理论的数学家也就越来越少了。那么，如果该理论太过费解，其他人都无法理解的话，那又该怎么办呢？要让该理论有所定论，那就必须等待另外的天才出现了。正是因为这理由，我才会说科学的极限来源于人类的大脑。你明白我的意思吗？” — 《盛夏的方程式》第八章

可是每个人都是不一样的，很可能一千人里无人能解决的问题，再遇到一人就能解决。如果一开始就让他们丧失了对知识的兴趣，那知识的实际意义在哪里呢？它还能继续好好地发展下去吗？还是最终变成一个『大家都去崇拜某位先哲』的纪念馆呢？

能够发自真心地教别人一个知识，摒弃了偏见和敌意、热爱和欣赏知识本身，能够理解和容纳同道幼稚的误解并且加以疏导，『我只是想让你明白』，那才是真正的贤人啊。

#Telegram #life

发了好多条广播呢

#life #Telegram 为了方便大家认识我，我把名字里的一些东西移动到 bio 里
Technical unfamiliar is origin sin
这句话的源头是冰封哥 @ice1000 的『菜是原罪』

后来我发现，我不应该尝试跟在他的后面怎么样，每个人都有自己的风格，何况冰封哥不喜欢菜鸡跟在后面的。
Telegram bio的空间很宝贵，我暂时不想在那里放格言，那就简单放一个自己的领域介绍吧。

/'dʊɔːŋ sjuːz/; [PLD, FPλ]; @dsuse@dsuses 日常讨论笔记文档代码 17yo CC-BY

现在的 first name （名）是 duangsuse，没有 last name（姓）

👆 好久之前的…… 已经没有时效性了

懂的人其实也不在少数，但最好是首先要明白人群的价值，不要霸占着话题、不允许别人提出「反对」的见解，把所有求知的人视为独立平等的个体，是两个灵魂之间的交流，而不恃才傲物；如果别人是对的，你就又纠正了自己的一个错误，即便别人是错的甚至错得很幼稚，你也得到了学习更好表达自己意图的方式以及与他人辩论的机会，同时别人也得到了自我提升以及进一步学习的机会。

认为自己的知识是自己的，还是认为自己的知识是跟世界复制来的；并且真心感谢其他人的帮助哪怕自己付过费，这是两种观念，但持不同两种观念的人将有巨大的不同。

一个争端，世界上就平白无故多了两个对某个知识有印象的人！为什么不去做呢？

uoow -> moon

#Kotlin Write once in one language, run anywhere on all platform.
编程就应该是这样，语言表达无关、平台无关，什么『专有』…… 都弱暴了！ M$ 之前那么宠 C# 和 .NET，最后还是只能给它官方开源跨平台了呵，不是想弄成Windows专有的技术么。

#school #life 呃…… 今天是星期五，本来本校换了个校长以后不经常放假了，趁着高二高一生中午放学的时间我也跟出来了……
还是和以前一样啊，本来到学校的时候可能啥都没有打算干，可后来又莫名其妙设计了一堆（嗯，的确是『设计』出的），虽然实现不了偶尔看见许多前端和PHP、Android们弄出来的东西心里酸酸的。（绝望）

襄阳昨天受孝感4.7级大地震影响，学校教学楼中间裂了个缝，正好是在高三的我们班…… 说什么『整体浇铸』只是裂了表面，假还是照样不放，生艹。

刚才USB绑定连WiFi上网或者用流量什么的不行了，手机不在家里，所以这段消息是离线编辑的（我也是习惯了，虽然之前我不上机是啥都懒得干的）

提示：这条广播好像发错地方了……如果不适请跳过，深表歉意。

刚才我登了一下小号，因为感兴趣 @drakeet 现在的发展看了下 @drakeets ，发现他虽然进步不快但也依然是蛮有创意，感觉实在是服气。
尽管他是拉黑了我，而且我也曾经很出言不逊（当然，我是真心的），不过我不喜欢给自己树敌，所以权当不认识这个人（嗯，现在两边都一样了）。

之所以说是有创意，是因为居然有native markdown render和LaTeX渲染，以及desktop版本虽然它没有截图所以我不知道是什么层次，虽然我其实还是蛮为drakeet现在没全换Kotlin感到有点可惜。

开始看到 "native" markdown render 之所以吃惊是因为（我开始只当他是完全自己实现的，后来我一想解析器形式化语言问题可不是个简单的主儿啊……就觉得解析器部分应该不是他实现的）
Markdown 完全可能是一种递归的结构，既然他给纯纯写作支持了渲染到 Android View 的功能（还支持 checkbox 控件什么的），就说明他是写了处理递归结构的算法……

比如，

- [ ] Binarie Project
  - [ ] Reader Abstraction
    - [ ] MarkReset
  - [ ] Writer Abstraction
  - [ ] ByteOrder
  - [ ] ByteConverts.kt

这实际上就是带递归的 <ul> (unordered list)

<ul><div>
  <li><input type="check"><div> <!-- 这里就回到了针对 div tag 的渲染 -->
    <ul>
      <li><input type="check">
  <li>……

虽然我不知道是不是 checkbox 也可以这么弄，但是 +/- 的 markdown list 的确是可以嵌套的。
所以你不可能只用 forEach 来渲染，当然我很清楚渲染子视图本来不应该依赖顺序来维护某种上下文的，可所有 UI 框架的绘制子程序基本都会顺序执行 drawLine, drawRect, addChildView 什么的。

那么我当然不可能只是这么浅显地吐槽一下，Visitor Pattern 我肯定必须谈的。
Visitor 是什么呢？考虑一下你有这种东西：

sealed class Expr /*四则expression*/ {
  data class Add(val a0: Expr, val a1: Expr): Expr()
  data class Literal(val n: Int): Expr()
}

编写一个程序来对加法进行求值操作。
val _1p0p9 = Add(Literal(1), Add(Literal(0), Literal(9)))
assert(eval(_1p0p9) == 10) //1+(0+9) = 10

首先我们可以利用面向对象的虚方法(virtual methods)，Add (+) 和 Literal (0-9* integral number) 都是 Expr 的「子类型(subtype)」，上面都可以有 eval 方法（求值操作），然后我们把他们的语义实现到这个 eval 方法上。

sealed class Expr { /*...*/ abstract fun eval(): Int }
然后在子类 Add 和 Literal 里实现 eval 方法，计算表达式。

也可以直接利用 Kotlin 的 when is test 这么写：
fun eval(expr: Expr): Int = when (expr) {
is Expr.Literal -> expr.n
is Expr.Add -> eval(expr.a0) + eval(expr.a1)
//sealed class 的子类是在相同文件内确定的，所以不用为了 branch exhaustiveness（分支情况穷尽性）加一个 else branch
}
递归的时候，要记住并且只看自己的函数是要进行一个怎么样的操作，就不会觉得难以理解了，Add 的 a0 可能是另一个 Add（继续递归），也可能是 Literal（递归的基线）。

而 Visitor 呢？它是为了抽象出「eval 类」Tree walker 函数的行为，让它能够做许多操作，比如 show, render, typeInference, compile……

sealed class Expr { fun <R> visit(vis: ExprVisitor<R>): R }

interface ExprVisitor<out R> {
fun visitAdd(e: Expr.Add): R
fun visitLiteral(e: Expr.Literal): R
}

还是不能理解？那么，也可以说 Expr.visit 方法就是上面的 when (expr) { is VariantA -> ...; is VariantB -> ... } 这个子类判断分支、ExprVisitor 的各种 visit 就是 when 判断里 case 后的结果表达式，它被抽提出来了。
也可以认为，它是『不对接在面向对象「虚方法多态」』上的方法 overriding，所以不必修改类定义即可工作（实际上很多设计模式，比如Strategy、Observer都是这样弄的……）。

当然上面的 Visitor 是一般工程界的风格，我的风格略有不同：

sealed class Expr { fun <R> visitBy(visitor: ExprVisitor<R>): R }

interface ExprVisitor<out R> {
fun see(e: Expr.Add): R
fun see(e: Expr.Literal): R
}

所以要我实现的话我会怎么实现呢？首先我得有一个渲染器就行。

fun renderMarkdown(text: String): Unit? {
  val markTree = MarkdownParser.tryRead(text) ?: return null
  val render = MarkdownViewRender(ctx) //不是特别了解Android的View布局系统，或许只需要ViewGroup就够了？
  markTree.visitBy(render).let { contentView = it }
}

其实一般而言 Unit? 这种类型不该出现的，我这里是想表达 Rust 的 Result<()>，或者说 enum class Ok { Okay, Failed }，不过这里是示范。

然后 LaTeX 也是我很奇怪（或许不尊重，但是我是真心这么想）drakeet怎么会知道TeX，这令我有点怀疑是不是他有偷看我频道（我一直没见过他写真正需要Math排版的内容） 😂
不过这个功能很有创意，但也不是很困难，实现 TeX 太困难了，我更愿意相信他是使用了网络 API 比如 https://codecogs.com/png.latex?\LaTeX 这样的在线渲染服务

要是我会怎么实现预览呢？假设我一定要把本来可以由布局控件实现的网络下载操作实现到这里的话（当然是需要 Async task 抽象而不能阻塞的）
我们的父层抽象，是完成渲染后（别问我为什么瞎设计，方便教学。）
对特定 Image Link 视图进行一些后期处理（这样就可以实现一些诸如检查 href link 可达性的功能，相信大家编程的时候都会这么弄，而不是一定要把这个逻辑写在渲染完成后本该直接返回的那一坨）

val layout: ViewGroup //...
const val CODECOGS_LATEX = "https://codecogs.com/png.latex?"
fun onRenderedImageLink(img: ImageLink) = when {
  img.href.startsWith(CODECOGS_LATEX) -> tasks.add(Http.download(img.href)) { img.render = Bitmap.read(it) }
  /* where Http is a singleton global state; Http.download: () -> ByteArray */
  else -> {}
}

嗯这样可能需要 Render 使用一个在我们这儿处理后的 strategy pattern 来实际渲染，免得它看不到我们的解析结果。（我觉得很奇怪，但这是因为我举的例子本身设计上就有颠倒顺序的问题）
或者，也可以做一个 ReplacableView （相当于二重指针，Box<T>(var item: T) ）来允许我们随便替换。

最后我真的不了解Android的View抽象，目前也懒得学了，错了请彬彬有礼地帮我指出雅正，谢谢。

其实我真是蛮酸的，尤其是看到自己的无人问津（当然我不怪Telegram）和CMU高材生的后生可畏。

他们是大学生啊，我可是高中在读的很不称职的高中生啊，羡慕人家的光明正大。

现在还得弄Binarie和ParserKt，绝句虽然最近就可以设计，也只能暑假开始了，我完成至少是ParserKt才可以动工（还好，ParserKt的DSL，PKNF, ParserKt Normal Form暂时不需要动）

这么看来其实我是个很自私的人，『中文编程』偶尔有点火或者知名，明明是对许多中国人、对xiaq、对『GitHub:汉语编程组织』都很好的事，但我第一时间是好奇，然后是抱怨『为什么不早不迟偏偏是在这时……』，无言以对了。

https://github.com/naoyuyan/naoyuyan/blob/master/%E8%84%91%E8%AF%AD%E8%A8%80%E8%AF%B4%E6%98%8E
https://github.com/directcg/Program-in-Chinese/wiki
你们看，其实许多所谓的『汉语编程』项目根本是笑话，很多人根本没有什么编程思想总结，甚至连很简单的解析器都不会写，他们才提出『汉语编程』。这些人根本不写程序、不做软件。
还有一些人则是思想太死板了，要实现『汉语编程』显然既要有自然语言（但不至于非得是NLP层次的才够）相关的知识（基本人人有）以及许多不死板不教条的编程经验，更要对程序设计语言的理论有一定程度且具有创新力的理解，这才是中文编程里面最重要的一部分，自然语言处理只能认为是辅助的辅助而已，不是灵魂。

如果把『汉语编程』里的『汉语』，当真放到『编程』的前面会怎么样？答案是那样的程序设计语言根本不优雅，不容易让人完全学会，而且会让整个社区的代码质量更不平衡。

现代汉语作为自然语言，它是能够描述很多我们平时编程绝对不会用到的信息的，比如：

今天我妈妈给我炖了一锅鱼，那鱼真香、真好吃。
昨天我爷爷给小红炖了一锅鱼，那鱼真香、真好吃。
昨天我妈妈给我炖了十只鸡，那些鸡真美。

请问这能够被写成程序吗？它根本只是在描述一件事情以及作者对此事的主观看法，即便是要怎么样也得先引入计算机对问题的抽象方式，而不是完全用『自然语言』来过度设计，给自己和他人制造问题。

这朵花真香啊。
这几朵花真香啊。

其中的「朵」是数量、「啊」是语气助词，如果这些意群出现在所谓的『汉语编程』语言里，哪怕只是允许那么写，你觉得那样的代码还有可维护性、可读性吗？那样的语言写出来的代码有一致性吗？

汉语凌驾于编程之上只是文化自负、舍本逐末，不能解决实际问题。

但到了另一种层次，以无数个不同的语言写过相同的程序、了解了面向栈|面向过程|面向对象|函数式|逻辑式(描述式)……设计实现过一些程序设计语言领域的东西以及自己编写了很多简单抑或复杂的算法后你就会发现，其实自然语言和所谓的编程语言之间虽然有很大差异，但前者是后者的超集，两者是很兼容的。
不是很多人只回答个『名字』『标识符』不同的区别，那是一种对问题解决方案思路描述根本上的不同。
一些人对英文语感其实真是差到连词法上的 plesure 和 please 区别那么显眼都分不清楚，中文和英文岂止是『名字』上的区别？

Alice(r) waved(v) to(p) us(r) silently(a).

这里 r是对事物的指代、v是动词、a是修饰语、p是介词。

爱丽丝(r)默默地(a)向(p)我们(r)挥手(v)。 

注意到了吗？现代汉语的语言习惯和英语是有很大不同的，包括 wave(v) 没有『过去式』、默默(silent) 后面跟的「地」，silently 修饰以及介词 to 的语序从 [waved(v) to(p) us(r)](stmt) silently(a) 变成了 默默地(a) [向(p)我们(r)挥手(v)](stmt)

从 wave (to us) 到（向我们）挥手，一个是先说『动作』，一个是先说『对象』。
有人说，英文是先说核心词（〔动作〕Alice挥手：向啥？向我们。）、汉语是先说上下文 (〔主语和宾语〕Alice向我们)=>弄啥？挥手。

那么，逗号依然能被用来切分『参数列表』么？
那么，『函数』依然该被叫成函数，甚至弄出 公开 静态 整数 主要的(常 字符指针 参数们) ； 吗？
那是新的编程语言，还是机器翻译了的 C89 语言？
拜托！你是在设计语言，还是在 cosplay Google Translator?
那么，for, while 还能被翻译为『循环』吗？
那么，全角和半角符号的区分没有意义么？
我就思量着，如果一段代码里符号都可以从全角半角里随便选，只要开闭配对就行，这样的表示方法势必是混乱的，而且全半角语义上没有区分，这个不区分本身有啥意义？要知道Basic对大小写的不区分可是害苦了很多非英语母语的人。
好的编程语言不该让人『可能』写出烂代码，因为那往往是设计思虑不够完善导致的。

语言所谓『翻译』，关键在于看它们如何被使用使用，而非单纯看字面含义。只看 "break"、"continue" 这些它们看起来时候的样子，是发现不了他们使用的时候永远是用于『停下』『略过』一次循环迭代的、不考虑语言的一致性(uniformity)是设计不出 抛下/尝试……接迎……终焉 这种看起来莫名其妙但实际用起来却很自然的结构化异常文法的。只知道C风格的"for"是无法设计出 对…里的(名)…… 这种文法结构的。

绝句的语法设计为了『更自然』『更统一』的目标一直在完善，甚至许多语言结构（比如重复若、抛下/接迎、断续、对何<真收者、入值、出返> 值：可关闭 皆有）都是和编译|运行时它们实际对应的抽象结构（比如栈、指令流、Continuation的capture/resume、多态类型系统的forall量词泛化）相对称的。
绝句的「常参」、「量」和「变参」的区分正像Kotlin的 val/var，不过规范化加上了「解量」语句而不是直接支持 val (a, b) = xy as Pair<Int, Int> 这种，每次提到「量」，感觉它是把一个动作的『量化』的结果，命名成了名词的『量』，简单一个字却体现出了定义+赋值的两种含义。

其实这也没有什么高大上的算法，为什么不多想想呢？

『汉化』语言首先是要了解语言、了解编程。所以这个…… 怎么说，其实 register 这个关键字是 C 里的 storage classifier，而 storage[存储] 这个字眼和『高级语言』 C 的结构化编程范式是相关的，它的是要修饰一个最好存储在寄存器的变量，换句话说这里的register实际上是『寄存器』的含义。翻译成『记录』就有点啼笑皆非了……
再比如把 lambda (Greek alphabet 'λ') 翻译成『拉』（还有 abstract 翻译成『阿』……），其实我觉得翻译成「入」都很好，入x. x+1 么，这才叫中文之美，『拉x: 1<= x&&x <10』是什么意思呢？
再比如把中缀 is 翻译成「是」，看起来很正常（若这人是正常用户，这人去加星(1)），可是它就与相等性判断 (==) 冲突了，你觉得，汉语编程里应该存在 大于号、小于号、&& || ! 么？
（若这人的名字是"duangsuse"且这人的年龄大18，当然也可以 量 加星=你这人，名字是"duangsuse"且年龄大18。，因为「你」中缀链简记不能 你x的name 且 的name，那太难看了）
而为了一致性，我不得不把 is 翻译成「属」，同样的也规范化了 判属…… when condition、属别名，所以绝句的类型都叫属，而不是具体的「类」「物」「例」。

量 f：(用户)真假 = 函数，〖他〗他属正常用户且他的年龄不小18。

再比如把中缀 as 翻译成「为」，如果用 （expr为加法树去计算()）这种形式，实际上它表达的是 has type，而不是 coercion 「作(as)」「试作(as?)」动态强制转型的含义，而「为(where)」本来可以用来做更有用的事情——开启对描述一件事、一种事物的代码布局，也就是Python的「:」。

绝句一是只以『翻译Kotlin编程』而不是『汉语编程』为己任，二是尽可能使得自己的表示方法规范、可猜测，三是针对且仅对经常出现的文法结构进行简化，四是统一定义实现的术语、提升代码和文档质量，最后它不是Kotlin的子集，目标是成为比Kotlin更容易理解、代码质量更好的编程语言，即便是以在非关键问题上牺牲性能和理论精确性为代价。我希望只要有可能，即便在一年后它的编译器都能让一个有编程基础的人在两周内彻底弄清弄懂、语言设计可以让人在一天内基本明白是啥意思、啥目的。

尽管绝句很考虑语言的一致性（所以不可能为了描述一种程序结构，而引入N种不同的文法），为了解决与现代汉语对接的问题，还是有所谓的『逗号表示法』（如果要说最自豪绝句的哪个设计，我绝对会说逗号表示法！）『「你」第二人称表示法』『「它」第三人称表示法』『记法(自定义中、后缀操作符)』的。

这段程序
定义 二分查找(数组, 目标) {
左索引 = 0
右索引 = 取长度(数组) - 1
位置 = -1

当 左索引 ≤ 右索引 且 位置 为 -1 {
中索引 = 向下取整((左索引 + 右索引) / 2)
如果 数组(中索引) 为 目标 {
位置 = 中索引
} 否则 {
如果 数组(中索引) > 目标 {
右索引 = 中索引 - 1
} 否则 {
左索引 = 中索引 + 1
}
}
}
返回 位置
}
用绝句写有两种写法：表述式和定义式

引记法 绝句.符号 「~前」
引记法 绝句.符号 「~后」
“属别名 索引 = 数”
对何<项> 项：有序<项> 皆有
事 二分查找(片：切片<项>、目标：项)：引数? 为
  变引数 左 = 0；变引数 右 = 片的末引
  重复若左不大右，
    量 中：引数 = (左+右) / 2
    判片[中]，
      它是目标，回中。
      它大目标，右 = 中前。
      它小目标，左 = 中后。
  回空

—

引记法 绝句.符号 「之」
‘在升序序列 [片] 上搜序 [目标]，若无则空’
对何<项> 项：有序<项> 皆有
事 二分查找(片：切片<项>、目标：项)：引数? = 二分找(片的索引)
其中，
  尾递归的事 二分找(区：引数域) 为
    若区之为空，回空。
    量 中：引数 = 区的中值
    回 判片[中]，
      它是目标，中。
      它大目标，二分找(区去换末(中前))。
      它小目标，二分找(区去换始(中后))。
扩物 数域 为
  量 中值：数 取者，(始+末)/2。
  事 换始(新始：数) = 数域(新始、末)
  事 换末(新末：数) = 数域(始、新末)

表述式和定义式都一样代表高级别的抽象、重复逻辑提取，这才叫『汉语编程』，只描述自己想做什么而不把每个步骤都写得死长死长。
哪种写法都比把『汉语』看得比『编程』的优雅性更重的语言好维护、直白、易理解。

https://zhuanlan.zhihu.com/p/30800689

汉语、汉字是美的、富有信息量的，但只有你开始重视程序算法、程序表述方式的美，使得它在保持简单漂亮的同时也能尽可能干净利落，才有可能把两个美有机结合在一起，最终完美地实现一个编程语言、编译器需要解决最本分的工作——让人编程、让人又快又好地编程。
『玉有灵性，反之也有邪性。』，事物往往都有两面性。
汉语编程，做好了能够让刚入门的中国人像编程大师一样肆意实现出各种曾经复杂难懂的逻辑，做差了，以纯汉字表达的程序会不留情面地显现出汉字丑陋的一面，更难看、更难懂，令语文老师觉得满篇不合体、缺语素，残害选择恐惧症、也可能让刚想试水的工程师最终悻悻离开，不能实用。

啧啧啧，虽然易语言提供了语言运行环境、IDE和基础库，但它身为『面向对象编程语言』居然连基本的中文语序都做不到，还和洋文一样把操作放在前边。我深深感到这5kw纳税人的钱是用到刀背上了。

🤔duangsuse 昨天晚上想到了一些话，愿意分享给大家。 #statement

duangsuse（虽然一点也不好）是如何编程的呢？
他编程，是一个从整到零，再从零到整的过程。

首先是把一个相对比较大的目标，拆分成许多能够比较简单实现的小目标。
比如，把一个操作纷繁复杂的类(class)，抽提出实现了很多接口的类。

接着是和自己争论实现的难点和复杂性，继续重新拆分和重新组织继承、数据依赖这样的关联。
比如，它会把二进制流读取器弄成 class Reader: BaseDataReader, ByteReader, ReadControl 而不是把所有这些操作，放在一个类里面。

然后是实现这些小目标。

最后，他按照在实现小目标时早已预备好的思路，把许多子程序组装成整个程序。

如何做出好吃的糖炒板栗？大的小的分开炒。一起炒的话，小的糊了大的没熟，怎么也不好吃。

如何写出好看的程序？每个部分分开写。写成一坨的话，两个事情里类似的子过程，差异不大，却让人迷迷糊糊分不清，怎么也不好看。

fun <R> Producer<R>.retry(n: Cnt, terminate: PredicateOn<R>): R?
= sequence { invoke() }.take(n)
.takeWhile { it != null && !it.terminate() }
.firstOrNull()