Forwarded from 层叠 - The Cascading
Telegram
荔枝木
啊这……
Forwarded from dnaugsuz
嘛，吃早饭的时候想到 ParserKt 跳过 Expr 里的 /* 注释的问题，说是不可能完成(因为要 lookahead)，发现是我错怪它了……
它读取 Expr 链用的是 InfixPattern ，而这个 Pattern 接收的是
它读取 Expr 链用的是 InfixPattern ，而这个 Pattern 接收的是
Pattern<Char, InfixOp<T>> 所以只要给 Trie 外面包层 Piped.decide， 然后如果是 /* 就返回一个跳到 */ 的解析器，否则 always(op) ，实际上是可以实现，只不过那个跳到 */ 的Pattern超级难写，而且这个做法超级鸡肋而已（只为区别除号和注释就得在 Trie 外再包一层…… 还不如允许 lookahead 开销小呢）Forwarded from dnaugsuz
不过我是真打算抛弃老的 ParserKt 了…… 看起来 crossinline 更有魅力一些，而且老版的代码虽然不冗余但也有很多比较鸡肋的功能，对实践的意义有疑问，而且新版一样支持 Trie,NumUnit,Lexical,Layout 这样复杂的 pattern 和 unparse ，只不过就不能写
!element('x') 这种利用 OOP PatternWrapper 的特性了。Forwarded from iseki 萍水相逢，相聚是缘
之前写了个codegen，处理vertx eventbus的，就是比较粗糙 https://gist.github.com/cpdyj/34f77d3bd56903247dc2a9e92196c6eb 上次不是纠结vertx的Service gen没法用吗
Gist
codegen for vert.x eventbus on kotlin.
codegen for vert.x eventbus on kotlin. GitHub Gist: instantly share code, notes, and snippets.
http://sargunv.github.io/cakeparse/
https://github.com/h0tk3y/better-parse/
草， Kotlin 居然还有 cakeparse 这个解析组合子库…… 完事后我也应该把 ParserKt 弄上 awesome list 还好
https://github.com/h0tk3y/better-parse/
草， Kotlin 居然还有 cakeparse 这个解析组合子库…… 完事后我也应该把 ParserKt 弄上 awesome list 还好
GitHub
GitHub - h0tk3y/better-parse: A nice parser combinator library for Kotlin
A nice parser combinator library for Kotlin. Contribute to h0tk3y/better-parse development by creating an account on GitHub.
duangsuse::Echo
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 的包结构相当复杂，而且还用的是
better-parse 的 Tuple 和 And 用了
的确很厉害，但它们都没做到能弄出(即便还有缺陷的) HanCalc 那样复杂的文法，止于玩具的程度而已。 想写出好东西光靠聪明是不行的…… 还要懂得如何分配自己的聪明 ☹️
一个作为底层为高层服务的库，就应该简单。 应该首先为使用它的东西的目的着想，尽可能少的使用不能使代码变好看的技巧或在API上制造麻烦。
聪明才智都用到设计这种“复用”库上了，如何才能真正在它上面轻松构造和谐优美的应用？
或许这样的代码，单独放到台面上是 A 级；但作为应用程序忠实的仆从，反而大放光华、喧宾夺主，就会毁了所依赖它的应用以及它自己。 写好复用库的关键在于看到它不是单独一个“人”。
顺便： CakeParse 真可爱，它的子解析器调用动词是
#statement #fp #kotlin #ce #lowlevel #dev
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
GitHub
ParserKt/examples
Example parsers for the ParserKt library. Contribute to ParserKt/examples development by creating an account on GitHub.
Forwarded from Plain 👨🏻💻 频道 @DigitalLife_CH
JetBrains Blog
Kotlin 1.4 现已发布，专注于质量和性能 – Kotlin Blog | JetBrains
Kotlin 1.4.0 今日发布！ 在过去的几年里，我们一直在努力使 Kotlin 成为一种有趣、令人愉快且高效的编程语言。 为了借助此版本的 Kotlin 继续追求这一目标，我们投入了大量精力和努力来提高 Kotlin 及其工具的性能和质量。 我们也很兴奋地宣布支持多种新的语言功能，包括期待已久的 Kotlin 接口的 SAM 转换。
为了帮助您充分利用 Kotlin 1.4 中引入的变更和
为了帮助您充分利用 Kotlin 1.4 中引入的变更和
不过这也正常，因为我找到了数个几个月没修复的 typo，难道这就是所谓的『贪多必失』么……
一个 kotlinx 库，居然把错误信息写得那么详细！ GNU 的文档链接都有了…… 而默认无法更改的 -help 命令的帮助却又那么简略！
一个 kotlinx 库，居然把错误信息写得那么详细！ GNU 的文档链接都有了…… 而默认无法更改的 -help 命令的帮助却又那么简略！
GitHub
Typo in user error message · Issue #42 · Kotlin/kotlinx-cli
kotlinx-cli/core/commonMain/src/ArgParser.kt Line 247 in f917f17 GNU standart for options allow to use short form whuch consists of one character. "whuch" ? "which"?
duangsuse::Echo
…… 看看 kotlinx.cli 他们这个，笑死我了， 简直不配叫 Kotlin ，草
解释一下。 Kotlin 代码的 if 嵌套层次能深到如此地步，而且 val 下面的 if 可以 early-continue 或者 invert if 的，它非要加缩进，真是让人无言以对，我内心已经开始自暴自弃一样的大笑了…… (大概是看谁的代码都有对它同理心吧)。
arg.startsWith('-') 又是一个和上文不对仗的用法，上面用的是 startsWith(optionShortFromPrefix) , 就算说是过滤性预判也极其牵强，只能说是作者嫌应用起来太长了， Kotlin 能写得这么窝囊我也是醉了。
duangsuse::Echo
同样是程序员，为什么有的人会把 Java 写成汇编，有的人会把 Kotlin 写成 Haskell？ 🤔 有一定编程素质的人写代码是横着写，写十年实质上没有进步的人写一旦时序区间复杂一点代码，一个个子程序像顽石一样竖在那不动，别人想弄明白你干了什么都麻烦的要死 好像别人欠你时间了一样 我以前以为 Oracle JDK 里的东西带黑科技性能加成，看来如今必须要改变一下看法了…… 把本来 71 行可以实现的逻辑写成 471 行、为每个子程序哪怕是最细节最实现无关的东西加上堪比千字文的注释、即便代码复用唾手可得我也要…
和之前那个 JDK DataInputStream 实现的一样，怎么这些程序员非得用这种机械化的方法编程，就不能换个套路…… 难看死了
TMD 还以为 JetBrains 和 kotlinx 里全都是大佬呢，没想到一些大佬的也不咋重视代码质量
TMD 还以为 JetBrains 和 kotlinx 里全都是大佬呢，没想到一些大佬的也不咋重视代码质量
看着这种优化的「注释」方式，我想起了那句“:shi味咖喱饭，还是咖喱饭味的:shi”…… (和谐
不管你怎么改，也只是从外表难看变成内部难看而已……
还有那个
还有
不管你怎么改，也只是从外表难看变成内部难看而已……
还有那个
if (treatAsOption && ..) if (!treatAsOption) 又是什么鬼啊……还有
if (treateAsOption) { if (!p) // Argument is found } 这个注释又是什么鬼逻辑…… 难道这个开发者不懂 found 是什么意思？学到了学到了，不过这样的代码我是不会再以非重构目的阅读了就是。
乍一看非常厉害，其实也没啥算法，而且都是在无用的地方下篇幅，死板的机器 formatting 我也会写那种 reformater 呢，何必呢。
从根本上设计就有问题，过于复杂，看起来再难以理解也只是给自己添麻烦而已，能做出什么呢？ 支持的太多，最后反而一个也用不到，自己也弃坑了，简直是暴殄天物。 Kotlin 这样融合OOP和函数式优点的语言拿来写这种烂代码、虚浮的内部建模，没有多大意义
乍一看非常厉害，其实也没啥算法，而且都是在无用的地方下篇幅，死板的机器 formatting 我也会写那种 reformater 呢，何必呢。
从根本上设计就有问题，过于复杂，看起来再难以理解也只是给自己添麻烦而已，能做出什么呢？ 支持的太多，最后反而一个也用不到，自己也弃坑了，简直是暴殄天物。 Kotlin 这样融合OOP和函数式优点的语言拿来写这种烂代码、虚浮的内部建模，没有多大意义