Forwarded from Deleted Account
这居然是”函数式“，我看这种函数式不过比其它编程方法多个高大上的 J, iff, World, StateMachine, FContext, Facade 而已嘛
我不知道类似这般的函数式除了把
它们不仅仅不好用，而且也不见得 Haskell GHC 这么学术的编译系统就有啥不得了的优化，它们就是”毛泽东思想“，迷信吃枣药丸。
我不知道类似这般的函数式除了把
feed.next() 直到 defaultValue : (parse cs) / (op c) : (parse cs) 直到各种各样的数据实例编码控制流越写越复杂，还能多解决什么实际问题它们不仅仅不好用，而且也不见得 Haskell GHC 这么学术的编译系统就有啥不得了的优化，它们就是”毛泽东思想“，迷信吃枣药丸。
Forwarded from Deleted Account
不能解决问题的函数式是垃圾函数式
尤其是这种连理论问题都解决得跟 前端 C++ 后端杂交一样的
屑函数式编程
尤其是这种连理论问题都解决得跟 前端 C++ 后端杂交一样的
屑函数式编程
Forwarded from Deleted Account
鼓吹自己是函数式的项目是屑
Kotlin 的 Arrow (functional stdlib) 是屑
Kotlin 的 Arrow (functional stdlib) 是屑
Forwarded from Deleted Account
想处理错误就能处理，不想就可以不处理，这才是正经编程实践错误处理方式
弄个 Either 在那里说什么 (Either a b) 啊谁都搞不懂弄啥子，更多 boilerplate 还不如原生 Result
弄个 Either 在那里说什么 (Either a b) 啊谁都搞不懂弄啥子，更多 boilerplate 还不如原生 Result
Forwarded from Deleted Account
迫真函数式
明明有更加函数式的风格非要用愚蠢的 loop
还甚至用了 var i = 0 和 val arr，真是蠢死了的 JavaScript 风格
不愧是前端的长期项目。
作者的迫真函数式编程水平由此可见一斑，这么简单的问题都能屑写出十行我真的怀疑此项目 TM 有7个子项目是不是包括了 810 个烂定义
明明有更加函数式的风格非要用愚蠢的 loop
还甚至用了 var i = 0 和 val arr，真是蠢死了的 JavaScript 风格
不愧是前端的长期项目。
作者的迫真函数式编程水平由此可见一斑，这么简单的问题都能屑写出十行我真的怀疑此项目 TM 有7个子项目是不是包括了 810 个烂定义
Forwarded from Deleted Account
屑写法：
即便屑写法 homo 比正规写法快 114514 倍，程序员也要克服自己的 1919 种怨念，重复写 810 遍方可修成正果（迫真）
我可是很正经的，请物理论 谢谢茄子。
val arr = IntArray(114.514.toInt())正规写法
var i = 0
while (i++ < 10) arr[i + '0'.toInt()] = i
i = 0
while (i__ < 16) arr[i + 'a'.toInt()] = 10+1
val arr = run {
val hexMaps = (0..9).map { '0'.toChar()+it to it } + (10..15).mapIndexed { 'a'.toInt()+it to it }
return@run hexMaps.toIndexedArray()
}
inline fun <reified T> Collection<Pair<Int, T>>.toIndexedArray(): Array<T> {
val first = firstOrNull() ?: return emptyArray()
val ary = Array(size) {first}
forEach { val (i, x) = it; ary[i] = x }
return ary
} 即便屑写法 homo 比正规写法快 114514 倍，程序员也要克服自己的 1919 种怨念，重复写 810 遍方可修成正果（迫真）
我可是很正经的，请物理论 谢谢茄子。
Deleted Account
屑写法： val arr = IntArray(114.514.toInt()) var i = 0 while (i++ < 10) arr[i + '0'.toInt()] = i i = 0 while (i__ < 16) arr[i + 'a'.toInt()] = 10+1 正规写法 val arr = run { val hexMaps = (0..9).map { '0'.toChar()+it to it } + (10..15).mapIndexed { 'a'.toInt()+it…
分析一个循环的关键点是在它起始时相关变量的状态，以及终止条件。
只不过最后离开循环体时
不一样的地方是
最后
val i=0; while (i++ < 10) 中 i in (0 until 10) 只不过最后离开循环体时
i = 11
和 val i=0; while (++i < 10) 不一样的地方是
++i 的版本 in (1 until 10) 少循环一次最后
i=10Forwarded from Deleted Account
extra/lsof 4.93.2-1 [已安装]
Lists open files for running Unix processes
Forwarded from Deleted Account
lsof -t path 可以查打开路径的 pid
lsof -p pid 可以查 pid 打开的所有路径
lsof -p pid 可以查 pid 打开的所有路径
Forwarded from Deleted Account
https://github.com/h0tk3y/better-parse/#better-parse
怎么感觉是在 show ParserKt 的泛型解析操作……
怎么感觉是在 show ParserKt 的泛型解析操作……
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.
Forwarded from Deleted Account
在 ParserKt 里甚至很难跳过空格，即便在使用 tokenizer+parser 的实现模式…… 这个得优化
虽然主推的当然是 scannerless parsing，但是为了秀操作当然是什么基本方法都是可以兼容的（大嘘）
虽然主推的当然是 scannerless parsing，但是为了秀操作当然是什么基本方法都是可以兼容的（大嘘）
Forwarded from Deleted Account
一旦用上 tokenizer+parser，ParserKt 的代码质量和灵活性瞬间下降了一个等级
我大概是要讽刺 Lex/Yacc style 的，emmm…… 🤪
我大概是要讽刺 Lex/Yacc style 的，emmm…… 🤪