duangsuse::Echo
721 subscribers
4.28K photos
130 videos
583 files
6.5K links
import this:
美而不丑、明而不暗、短而不凡、长而不乱,扁平不宽,读而后码,行之天下,勿托地上天国。
异常勿吞,难过勿过,叹一真理。效率是很重要,盲目最是低效。
简明是可靠的先验,不是可靠的祭品。
知其变,守其恒,为天下式;穷其变,知不穷,得地上势。知变守恒却穷变知新,我认真理,我不认真。

技术相干订阅~
另外有 throws 闲杂频道 @dsuset
转载频道 @dsusep
极小可能会有批评zf的消息 如有不适可退出
suse小站(面向运气编程): https://WOJS.org/#/
Download Telegram
这次还比较『可复用』,可是又有什么暖用呢?
艹,写代码的,bug 躲不掉。
才体会到工程的难度,原来测试不过不能 push 是真的!我刚才发布了一个 v1.2 一上来就是修完 bug 没修好,不能用的版本!
一个新版本居然不能用??就发布了??工程管理不善??太难了!!!
看来测试不是谎言…… 除非真是大师级的人物,不然一次写对真的不容易呢
有点怀念当年用 subslice 写『解析器』、分不清 call-by-value、call-by-name、call-by-need 的时候了,现在设计实现语法、模式什么的根本没有难度……
但是工程总是需要时间,而对这个时间的预估我目前仍是眼高手低
Forwarded from duangsuse Throws
#Kotlin #dev #life #CS #PLT 多少人幻想着香槟,却只有喝速溶咖啡的命…… 眼睛好疼。
LiterateKt 真是很赞,虽然它也还没用上啥非常不得了的技术(用上也不该是以网页脚本的形式)

但是,就目前而言好像也没发现任何问题,偶尔处理不好文章的依赖组织,发生了多层嵌套的情况错误了,其实也是因为自己没组织好文章分区的关系,重新组织发现很够用,自动依赖关系解析也不会对循环依赖多给结果导致 Kotlin redeclaration。

唯一还不够的是文档里没写明两种依赖求解方式对输入结构是否递归的要求,明天考虑修一下……
#dev #JavaScript 😂 写着写着就写了个笑话上去
永久封存 | Yuuta 台 | 😷 #Pray4Wuhan
https://zhuanlan.zhihu.com/p/94599371
一直很羡慕那些 VISA(Video Image Speech Audio) 和 ML 的研究者啊,什么 2D、3D、透视、正交、旋转、空间、对应…… 然后效果都好得多的多了,可我还要做很久的基础,也不能说实操 #PLT 领域一些高级的工作如逻辑式定理证明

好像 dependent type、逻辑式、关系式之间不存在直接联系。

呵呵,有什么用呢?我不懂也只是被喷,不会有人理解我,他们也都喊着谁懂我、谁来救救我…… 难道就是这样?一定有更好的方法……
我对文章的代码依赖进行了一些整理,现在整个文章的 Kotlin 代码结构相对规范了很多,不存在为了教学目的设置的不成熟 code 被放在顶级 literate 里的情况了。
如果有 LiterateKt 的 CLI 项目生成工具被写出,这整篇文章甚至都可以直接拿去编译。
最初的时候我觉得手动写明所有依赖也没什么,开始也是作为一个附加的特性在写依赖关系求解器的。现在我开始庆幸那时做了那种设计,要不然 LiterateKt.ts 真的没法用…… 我没想到会有这么多依赖
现在对示例程序的编写方式已经比较成熟了,都是直接在一个 literate 写一个模块的某层次的基本构件,再在里面写 depend 它们的示例和辅助示例的算法。
#Chinese 『你说的』引用的是『你说的东西』
『你说得』引用的是『你说某事的这种行为』
This media is not supported in your browser
VIEW IN TELEGRAM