http://sargunv.github.io/cakeparse/
https://github.com/h0tk3y/better-parse/

草， Kotlin 居然还有 cakeparse 这个解析组合子库…… 完事后我也应该把 ParserKt 弄上 awesome list 还好

两个大佬都比我聪明，都用了 Kotlin sequences 和大量的 infix notation ，而且是 LL(*) 的 (regex)tokenizer-parser 架构；并且，我也见到不少和函数式领域有交叉的名词（总之高大上就是了）
CakeParse 的包结构相当复杂，而且还用的是 CachedSequence<TokenInstance> …… 真不是一般的复杂，尤其是命名上。
better-parse 的 Tuple 和 And 用了 codegen(n_max, output) Gradle task 代码生成，而且它的 (a and b) 还能针对 skip(a) 这种特例创建不同的 tuple ，这种思路我是想不到如何尽可能优化地实现……

的确很厉害，但它们都没做到能弄出(即便还有缺陷的) HanCalc 那样复杂的文法，止于玩具的程度而已。 想写出好东西光靠聪明是不行的…… 还要懂得如何分配自己的聪明 ☹️
一个作为底层为高层服务的库，就应该简单。 应该首先为使用它的东西的目的着想，尽可能少的使用不能使代码变好看的技巧或在API上制造麻烦。

聪明才智都用到设计这种“复用”库上了，如何才能真正在它上面轻松构造和谐优美的应用？
或许这样的代码，单独放到台面上是 A 级；但作为应用程序忠实的仆从，反而大放光华、喧宾夺主，就会毁了所依赖它的应用以及它自己。 写好复用库的关键在于看到它不是单独一个“人”。

顺便： CakeParse 真可爱，它的子解析器调用动词是 eat() ， 吃输入 😂
#statement #fp #kotlin #ce #lowlevel #dev

…… 看看 kotlinx.cli 他们这个，笑死我了， 简直不配叫 Kotlin ，草

不过这也正常，因为我找到了数个几个月没修复的 typo，难道这就是所谓的『贪多必失』么……

一个 kotlinx 库，居然把错误信息写得那么详细！ GNU 的文档链接都有了…… 而默认无法更改的 -help 命令的帮助却又那么简略！

解释一下。 Kotlin 代码的 if 嵌套层次能深到如此地步，而且 val 下面的 if 可以 early-continue 或者 invert if 的，它非要加缩进，真是让人无言以对，我内心已经开始自暴自弃一样的大笑了…… (大概是看谁的代码都有对它同理心吧)。

arg.startsWith('-') 又是一个和上文不对仗的用法，上面用的是 startsWith(optionShortFromPrefix) , 就算说是过滤性预判也极其牵强，只能说是作者嫌应用起来太长了， Kotlin 能写得这么窝囊我也是醉了。

和之前那个 JDK DataInputStream 实现的一样，怎么这些程序员非得用这种机械化的方法编程，就不能换个套路…… 难看死了

TMD 还以为 JetBrains 和 kotlinx 里全都是大佬呢，没想到一些大佬的也不咋重视代码质量

全貌。 就这么一点逻辑还加一句一注释演技真是浮夸啊…… 很多 if 其实都只有一个语句，它偏偏要加缩进 而且还在那句上加个无关紧要的注释，真是把我以前在 Java 见过最烂的注释方式移植到 Kotlin 上了，一句一注释，而不是把这些破烂集合到内联文档垃圾场去，的确是很 Kotlin way 啊。 😠

看着这种优化的「注释」方式，我想起了那句“:shi味咖喱饭，还是咖喱饭味的:shi”…… (和谐
不管你怎么改，也只是从外表难看变成内部难看而已……

还有那个 if (treatAsOption && ..) if (!treatAsOption) 又是什么鬼啊……
还有 if (treateAsOption) { if (!p) // Argument is found } 这个注释又是什么鬼逻辑…… 难道这个开发者不懂 found 是什么意思？

学到了学到了，不过这样的代码我是不会再以非重构目的阅读了就是。
乍一看非常厉害，其实也没啥算法，而且都是在无用的地方下篇幅，死板的机器 formatting 我也会写那种 reformater 呢，何必呢。

从根本上设计就有问题，过于复杂，看起来再难以理解也只是给自己添麻烦而已，能做出什么呢？ 支持的太多，最后反而一个也用不到，自己也弃坑了，简直是暴殄天物。 Kotlin 这样融合OOP和函数式优点的语言拿来写这种烂代码、虚浮的内部建模，没有多大意义

混乱的代码就不多发了…… 这个拿来充当反面教材都太重口了。 隔壁的 CliKT 代码质量比它高到不知哪里去了，我从那抄 multiplatform 的无趣味代码抄得谈笑风生，而且都不需要重构。

仔细解读下这个反面教材哈， #Kotlin
1. optionFullFormPrefix 太长了(别告诉我没法短，不能短也得想办法变成 Pair 之类的弄短！)
2. 顺序虽然是统一的出现/依赖顺序而非重要性顺序，但和 prefix, delimiter, deprecatedWarning 放一起实在太草了，何况也并非严格按建模对象的出现顺序， full/short prefix 其实是并列的。
3. textDescription: String get() = 没有问题，但是后面还有一个 formatHelp: String get() {} 就实在是太糟心了
4. TResult ? 难道你不用 R 吗？ 而且 T: Any 的 constraint 真的有意义吗？ 很多时候在有 null T? 成员时根本不必显式指出的
5. 排版问题。 T? 和 T ?
6. ArgType<T> 和 TResult 的关系存疑，理论上只应有一个。 要知道 ArgType 是包含 convert 方法的。
7. Nullable 的东西太多了，设计建模可能有误会没消除

🤔 #zhihu 上看了 #Cplusplus 的一个 stream lcm 最小公倍数:
#include <iterator>
#include <numeric>
int main() {
int[] xs = {2,3,4,5,6};
cout << reduce(begin(xs), end(xs), 1, lcm<int,int>);
cout << endl; //^ 60
return 0;
}

https://coolshell.cn/articles/21003.html #web #security 草，原来字符串比较算法的耗时也可以被用来猜密码， str.zip(str1).fold(true) { (a, b) -> a xor b == 0 } 而不是 str.zip(str1).firstOrNull { (a,b) -> a!=b } 么

我艹受不鸟了，这是啥玩意啊『前端』……

#Cplusplus 这个 template 技巧收下了！
C/C++ 函数返回值可以不确定吗? - IceBear的回答 - 知乎
https://www.zhihu.com/question/414206269/answer/1408101568

template<> int f<int>() { return 1; }
template<> bool f<bool>() { return true; }

or:

variant<int, bool> produce(string &type) {
return true; //有时需先声明作局部变量 不然类型错误
}

auto visitor = [](auto &&arg) {
using T = decay_t<decltype(arg)>;
(is_same_v<T, int>)? f_int()
:(is_same_v<T, bool>)? f_bool()
:nullptr;
}
std::visit(visitor, value);

🤔 老实说我现在最看得起的「设计模式」只有 Delegate, Observer, Visitor, Kotlin 的 scope function let/run/apply/also 和 null/elvis chain 以及 OOP 原生的 嵌套式构造器调用、字段初始化、方法解析 。

玩得再花，不能解决实际问题也是废物。还不如实在点、自然点，在合适的层次解决真正的问题。
所以说设计模式什么的都滚蛋吧…… 只有数据模型和程序的共鸣最重要

最近我设计的 ArgParser 和 ParserKt 也都只用了 Delegate/Visitor ，没有其它古古怪怪的 Adapter,Provider,Builder,Factory,Command 这样的东西，无脑的复制 pattern 显然是不好的，乱用各种 -er 对象更是不可取的操作……

所以说把函数式拿来修复面向对象的设计模式里各种奇奇怪怪的名词是最好的选择，而且也解决了函数式不明确、太隐晦的问题。