https://mrale.ph/blog/2018/02/03/maybe-you-dont-need-rust-to-speed-up-your-js.html#profiling-the-pure-javascript-version #Rust #JS #web #editors #lowlevel

这篇文章讲得真好啊！作者用类似 sort(xs, comparator, /*显式指定余参*/false) 、用 UintArray 替代 JS 的 class definition ，把可复用的存储做成一整块 struct 的方法来提升性能，还有很多有意思的地方，写的非常全、耗时折线图(iteration-ms)很多，是 PGO (基于评测优化)，即便没打算看的我第一遍也能理解很多。

作者最后的寄语也很好，要让程序员注意 profiler 和使用的算法、不要过度依赖 VM 的优化并且懂得帮助 VM 优化自己的代码； 编译器工程师要知道把优化拿上台面而不是在后台默默试图接受全部代码，真的是大佬的眼界。

#China #web 诞生自互联网、毁了互联网。 🌎🕸

中国大陆的著名社交软件「新浪微博」的官方客户端于近期开始对第三方网站链接（除少数白名单内网站）进行干预。用户无法直接点击打开，而是需要复制后在浏览器才能打开第三方网站链接。

第三方客户端则不受影响。

src: https://t.me/yitianshijie/1938
src: https://t.me/yitianshijie/1939

https://github.com/ajalt/clikt 草，这个东西不就做了个动画 GIF 作 banner 嘛，就有 1.2k star ，真是太扯了， kotlinx.cli 也才 500 star 啊

妈的现在 Kotlin 的解析库都喜欢用 by 直接把数据存储指定到 class val 上，我真不知道这样有什么好的……
https://github.com/h0tk3y/better-parse/blob/master/demo/demo-jvm/src/main/kotlin/com/example/ArithmeticsEvaluator.kt better-parse 是这样
https://github.com/xenomachina/kotlin-argparser 是这样
https://github.com/Kotlin/kotlinx-cli 是这样
https://github.com/ajalt/clikt
一样是这样…… 只有 https://github.com/leprosus/kotlin-cli 没这样，但他写的也扯，哪里来那么多 multi param arguments……

了解了 Kotlin 反射和 getValue, setValue ，就开始喜欢炫技了，好像一些「不一样」的东西用上了才是『高级架构师』，短视…… Kotlin 摒弃了 Scala 的缺点并从命令式脱胎为定义式，就为了让另一群只认为用到了稀奇 API 或者写出了超长代码、超完善项目包装的人陶醉？ 没想到 kotlinx.cli 也是这样，加文档也不看到底是文档出现是为了什么，看来只有kotlin语法的设计者最懂。。

别人生怕框架里用不上，我生怕框架里尽可能少用了还被人从外面挑出来看到……
什么代码是易读的，Kotlin 的 operator fun 难道还不能阐述清楚？一些框架干脆是把 by 替换了 = assign，真是败笔一处，Kotlin 真不该给 by 允许用 type inference 的，hhhhhh....

等到以后正式放到 sonatype 存储库，我得给 ArgParser 加 multi-arg 和什么 "CLI propmting" ，好好寒碜一下他们…… multi-arg 有啥好炫耀的，流解析器哪个不能做到高扩展性？ArgParser 的解析循环驱动层就支持， 开始我不打算在EDSL里设计就是因为太不合常理。 居然连 get environment varaible 都拿出来当基础 feature ，真是服气了，管得比 ParserKt 宽啊……

只有重视简洁性的代码才是最好的，只做、并做好自己该做的事。以面向对象的 SwitchParser 为核心，再利用各种动态数据结构扩充成 ArgParser；同时具备面向对象和函数式的风格，不随便滥用反射和类型推导，才是 Kotiln 代码应该有的样子；而不是见得风是得雨，看到啥结构好玩就不加考虑地去添加。懂得从用户角度考虑。

不过要是支持 multi-arg ，ArgParser 的表层封装内部表示就要引入不优雅性了…… Converter 只能接收 String，那么就必须把多个 String 拼成一个还能切开，只好用 '\u0000' 这个特殊值了…… 真麻烦啊，还必须修改解析器onPrefix的代码…… 就为了这种莫名其妙的特性

还好目前而言 Arg.param 变量只是 toString 的时候用的，没有数据处理存储会用到它，这样就好办了(toString都不用改因为本来就是用空格切参数名)，只需要修一下 read() 里的代码，convert 的架构是现成的…… 还真是容易啊

toString 里方括号的语义混淆了， Subcommand 也要支持…… 看来又有功能扩展要做了，还好状态机的模型不变，可扩展性就没问题。
@-argfile 也要给提示、 error message format 也要加 TextCaps 、要支持基于数组切片替换的 aliases …… unknown command 也要 open

Clikt 真是太牛逼了，艺术啊，一个 ArgParser 做成简直和 Lexer 一样的考虑程度，心细如针啊，真是一个能拿来实现 Proguard argument parser 的大框架。

我原来以为自己对 ArgParser 的执着过度了因为它不过是个打杂的东西，ParserKt 才是正戏，而且说穿了他们俩除了接口漂亮也都没啥实际算法，花皮糠枕头，没想到还真有框架做得比 parsrekt.argp.ArgParser 还要绝…… 密码提示框，解析一对 -map a b 这种参数，我都想不到有 CLI 程序这么现代化啊，这到广义序列化的范畴了吧,,,

已经支持了 multi-param ，我看看接下来怎么操作

支持了我可一点不开心。 我查了一下一些语言实现的 CLI 参数， ruby, python, lua, gcc, clang, rustc, php, squeak, java, javac, kotlinc ，它们没有一个需要所谓的 multi-arg ，顶多要一个 multi item / mssing-prefix interprete ，真是白白浪费自己框架的输出代码体积……

看到这里我就莫名觉得 ArgParser 的设计也真是牛逼，只是给每个 Arg 都加了 convert 函数式属性，就同时做到了另两个框架特殊处理的 validate 和 convert，还有什么 -v -h 这样的 "eager argument"…… 调用 SwitchParser.stop() 和 throw ParseError 不就做到了么？起那么多名词，却背离了框架所应解决问题的本心。抛弃JVM优雅性的过度封装。

其实从action封装的这个角度讲，那两个框架还不如 Python 的 argparse 。人家是只用了一个 ActionContainer ，我的做法和它大致一样(只不过是静态检查的)。
也有一些框架是按 argparse module 的模式照搬的，可惜它们的其他基础部分太烂…… 而且现在的程序员，估计都喜欢搞一些花里胡哨的东西显得自己很懂、很牛逼，却忘记了自己是在解决问题，应该站在问题的角度为它服务，而不是凌驾于问题之上，刻意套用狭隘的语言特性。

真正牛逼的算法大佬从来不屑于在这种破事上费功夫，我们这些做封装的，有什么脸去炫技…… 框架只该考虑优雅地定义、实现好它的本职工作，而不是在后面的算法没啥特色的情况下硬上「高大上」的 API。

就是对自己的能力没有自信才会作这种腔调！如果真的把自己当程序的设计者，就应该有为了程序舍弃自身的觉悟才对。

……写了半天我自己也给绕糊涂了，ArgParse 有三种arg: flag, param, item ，但其 param 分为强类型(1~4) 与弱类型(moreArgs, resucePrefix) 两种，分别存储在 tup 和 dynamicMap 里…… 这次遇到的坑就是 dynamicMap 里存项是 T 但 tup 里就是 OM<T>，不一致啊。 改起来就超级麻烦，必须得重构了，不然不优雅性就要暴露到接口上

这个该死的解构定义是万恶之源，为了它我不知道执行了多少次测试…… 而且每次都百思不得其解，就为了不分情况的返回 pair，提供一个可变的 OM<T>，而不是分情况往 tup 或 dynamicMap 里写值。

因为数据结构动态类型程度过分，赋值的时序关系没注意到就容易踩很多坑…… 看来 Kotlin 的 local function 也一定不能混乱整个函数内部的代码行号和执行顺序
还是强类型语言好…… 每次 unchecked cast 都好怕的 😱

……又是我最讨厌的动态类型