草，花了好长时间就做了个 logo …… 而且动画还要另做

#Kotlin #web #Java #dev

之前写了个codegen，处理vertx eventbus的，就是比较粗糙 https://gist.github.com/cpdyj/34f77d3bd56903247dc2a9e92196c6eb 上次不是纠结vertx的Service gen没法用吗

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 } 么