https://github.com/duangsuse-valid-projects/LiterateKt

目前是只能用来写文章的

不是难看了一点，难看的东西都有问题！

我今天早上吃饭时想了一会，基本熟悉了它的工作方式：
+ no-dependencies = null
+ have-dependencies = each-dependency-with-their-dependencies ?? [itself]

后来我一想，不对啊

xs?.concat(x) ?? [x] 这不是等于 (xs ?? []).concat(x) 吗？
再一想，自己早在还没弄自动依赖解析之前就已经犯了这个错误，但那时候是情有可原，因为没 depend DOM Attribute 就的确是『没有依赖』，但现在不行啊！
deepDependencies 本来就应该返回 Array<Element> 而非 Array<Element>?
艹，如果是 Kotlin 我肯定不会犯这种错误！都怪 TS 不区分可 null 与否！

然后我发现这是因为没有完全重写，误会了 (??) operator 导致的一个设计问题…… 其实 deepDependencies 的基线完全可以是 [] 而非 null，手生了……

#JavaScript #Algorithm #web
而且我还想到一个问题，就是现在的依赖关系不能递归，但貌似我们拼接 Kotlin File 的方式是必须可以的，依赖不存在顺序。

或者说，我们要处理的『依赖图』，不一定是有向图，但目前的递归 deepDependencies 会 max call stack exceeded，我无法允许这种出错的可能。

所以可以用 DFS 啊，既然我们认为 a-b “a依赖b” 是互相的关系，那最终的完整依赖也可以视为一个集合，只需在添加 dependencySet 和 bfsQueue 前现判一下是不是已经有了就好了。
如 a-b 的循环依赖
scan a -> add, queue b
scan b -> add, queue a
scan a -> continue
finish [a, b]

此外，这两种（递归、BFS广度优先搜索）的依赖集合算法本身都是很泛化的『算法』，不该在某个特定的模块里针对特定抽象数据实现，可以抽象出关于类型 <T> 的 deepDependencies(root: T, links: (T) => Iterable<T>): Array<T> 从而在更多数据结构上运行

#TypeScript 没有 in, out 和 * 真是不如 #Kotlin 好啊！还是 Kotlin 设计有创意……

#TypeScript 的 overloads list 有点不直接，而且是半自动的多态…… 定义侧还得手动 typeof

AMD 不能循环加载实在是太扎心了！RequireJS 也不是个好东西

RequireJS 居然不能加载 ES6 Module？？？

<script async src="https://cdnjs.cloudflare.com/ajax/libs/require.js/2.3.6/require.js" integrity="sha256-lIXwkX+X/PT2Ol6jZSAP/VfxI/RROCovmhrS4v1RrJs=" crossorigin="anonymous" data-main="dist/literate_kotlin_post.js"></script>

SyntaxError: import declarations may only appear at top level of a module literate_kotlin_post.js:1
这是太蠢了！ #web #JavaScript 不愧是前端『设计师』们的作品呢！
我都丝毫没有办法去手动给它加 type="module"

这 不 摩 登 ！

当前端太困难了，我太难了，我想回去…… 还是写 Kotlin 好了，连个循环加载都做不到，import 居然能是『Statement』，各种 workaround，服了

这实在是 太 不 摩 登 了！！！原来 import 会被『自动提升』？？？那你为什么不告诉我不能加分号？为什么不提醒我把 import 提到上面去？？？这是没官方 REPL 的 TypeScript 啊？！！

以后干脆拿 Kotlin/JS 写前端好了，省得麻烦

乍一看大家会觉得它太冗了，虽然的确很冗，但具有可维护性、可扩展性，而且其复用可能性更大、给新人阅读理解也较容易。

不断地修改和抽提，也是我每写一个应用基本都会对应地弄出一个复用库的原因，所以我根本不愁写不出来『框架』，我写点应用都能写出『框架』来，只是时间真的不能保证……

看起来冗，但可以举个例子：如果要再兼容某个类似 KotlinPlaygound 的东西，要怎么样？
这个『冗长』 的版本只需修改 playgroundDefaults、literateCodeFilter、LiterateKtMagics.KotlinPlaygroundId 对应的几个逻辑就可以了，而如果写得更『精简』，没那么方便了。
再比如，很多本来可以通过面向对象继承提出的逻辑，如果不写『冗』一点，也是感受不出的。
再比如，如果你要写一个复用库，最好的方法就是边写边用！这时候没有『把结构写「复杂」』的觉悟，是很难完成同时编写应用和复用库的任务的。

总之，冗长的好处只有用过它的人才能完全体会得到。

那，如果模块化使得项目结构更复杂，让新人难以理解了怎么办？？？
所以要写好 README.md 啊…… 没人告诉我们，只有 project root 可以放 README 吧。

#dev #PLT 给大家讲个有趣的事情：
🐔鸡你太美。

我在网易云音乐找这个东西的时候，对两首歌特别可心。
其一是原版《只因你太美》、其二是一个纯音乐 remix。

我们知道，原版(SWIN) 的是有歌词的（只因你太美……）
可是 remix 版只有重复的『鸡你太美……实在是太美』这样类似词穷的东西，我们认为它是纯音乐，没有唱词。

如果你是网易云的工程师，尝试用 #Kotlin 这样的『面向对象』编程语言给这样可能有歌词的歌曲建模，你会怎么建呢？
——

首先，我想到的办法是类似这样，

val NO_LYRICS: Lyrics = TODO()

data class Song(/*...*/, val lyrics: Lyrics)

比如，如果我们以链接(URI)的方式“存储”歌词，那么没歌词的情况：
const val NO_LYRICS = "nolyrics:"

有点类似 libc 的『特殊返回值』，比如函数 ioctl 如果返回 (-1) 表示请求出错。
但是这不是很规范，而且容易给数据维护制造问题，所以：

data class Song(/*...*/, val lyrics: Lyrics?)

这样我们也可以同时表达有歌词的『只因你太美』和没歌词的『只因你太美(remix)』

可是，如果除了歌词外还有别的东西可能有出入，或者觉得『一首歌可能有歌词也可能完全没有、但居然还要存 null』该如何？

sealed class Music(/*...*/) {
  data class Song(/*...*/, val lyrics: Lyrics): Music(/*...*/)
}

然后，我们在取的时候判断 music is Song，或者 (music as? Song)?.lyrics ?: "无歌词" 就可以了。

#dalao https://github.com/spieglt/nestur
这个真心不错啊，APU 和 PPU 是啥…… 我只知 ALU(Arithmatic Logic Unit) 毕竟是游戏机处理平台啊！还能跑超级玛丽！只用底层的 SDL 绘图

#English Prometheus 是『普罗米修斯』的意思……