流水账〔卅一〕

开门见山，先贴一张图，本地运行「MaDoKo」的效果：

范某截图备份于此

那些示例「纯文本」都是从官方参考手册当中搬来的。既然能画出复杂到这个程度的公式，这是「更折衷的解决方案」，离线单机版运行比「Typora」还强点，虽然不是「所见即所得」，但毕竟能「实时」渲染而不是等编译。

配置很简单，主页上最下方「FAQ-10」就有提示。在已经有了「TeX Live」的前提下（参考第一篇流水帐），去「Node.js」下载脚本引擎安装包，装好后再执行两条命令行即可，启动也是命令行，可以指定工作目录。

这就算搞定了能开工了，对于不熟悉也不关心信息技术细节的用户也很方便。但是呢，正如前两篇流水帐里面提到的那样，其它领域从业人员看这些「纯文本」有没有「眼晕」的感觉，是工作时能否保持状态的关键。

接下来按照惯例「泼冷水」，这是「情商负无穷」的数学渣的职业习惯。从效果讲，这个「MaDoKo」已经把「MarkDown」扩展到了极限了，从停滞两年多版本还没到1.0也知道。从实现上讲，仍然是属于拼凑式解决方案，并且「扩展」的那些内容看上去很「脏」。

稍微解释一下，官方解释「MaDoKo」就是「MarkDown」语法用「Koka」语言实现，而这个「Koka」语言，看上去乏善可陈，或者是基于作者在微软研究院为了开个项目骗预算的理由。如果「理性客观公正中立」的评价，为啥不用Lua之类更成熟的语言呢？

并且，对语法「扩展」的部分，混合了许多「HTML/CSS」细节，甚至直接插入CSS代码。比如上面截图中的表格，花里胡哨令人惊艳，左侧篇幅所限没能同步显示出代码来，各位去参考手册当中相关部分看一眼就知道我用「脏」这个字眼的意思了。

注意在信息技术当中「脏活」（dirty work）并不见得都是贬义，尤其是对于一些数据库之类底层的需要性能的应用来说，保持「可维护性」前提之下必须要有一些「丑陋」的代码。而对于那些需要深度优化的领域，完全放弃了代码可读性，连四五层嵌套指针的情况都有，业内相关人士都知道，不啰嗦了。

总之，这个实现方式虽然「效果」很好，但是与「轻量级」目标和「简洁」设计原则背道而驰。若是其「目标」本来就是「在线专业出版解决方案」，企图与包括但不限于Adobe在内的各个对手竞争，那么「重量级吨位」也就能解释通了。

众所周知，当代专业出版社也会用LaTeX模板，其中包括很多业内耳熟能详的名字，比方说刚从境内某LaTeX相关站点下载了一套美帝灯塔国某理工科专业出版社所用模板，150MB的压缩包。所以，看到这个于后台编译为TeX之后再输出的MaDoKo，但凡经验充沛的精神病仆街写手不入流码农数学渣都会作出这样的思路广欢乐多举动。

所以我才说，这是「拼凑式」解决方案嘛，但是并没有贬义。因为前面提到了，「SageMath」也是由各个开源软件包拼凑而成的，到现在8.0版了，功能越来越强，「效果」也越来越好。而在后台使用LaTeX的好处，就是截图里面体现的那样，可以直接用现成的包，不必局限于「MathJax」的进度。这就是作为离线单机版的「MoDoKo」胜过「Typora」的地方。

使用MaDoKo还有一个原因，就是「绘图」相关内容，在业内的文章当中差不多和「公式」同等重要。大约二十年前的老掉牙经验，我还是用「gnuplot」作图然后插入文档，后来听说过「MetaPost」但是没用过，最近重新弥补代沟的时候，发现了「PGF/TikZ」这个包括在「TeX Live」官方套装当中的方案。这个方案的好处就是可以直接在LaTeX文档内部写绘图代码，如同公式一般在开头直接引用相关包就可以，于是文档风格一致连续。

小结一下，MaDoKo站点一直在运营，但是项目本身已经停滞两年多，一方面证明如同MarkDown那样在当前HTML/CSS标准已经被广泛实现并且功能足够的前提下没有继续追加功能的余地，另一方面还证明这个方案本身在商业上和技术上都没有前途。君不见Koka语言的相关链接都失效了么，重定向到这位微软研究院职员的页面上。

那么，开源社区可以考虑在这个「试验性项目」的基础上，换成更加成熟且流行的Lua重新实现，过程中要去芜存菁，还要旁征博引。因为「PGF/TikZ」本身除了用TeX底层命令之外，就是使用了Lua作为脚本。所以，将来翻版「MaDoLu」（暂名）会成为「TeX Live」套装的一部分也说不定。

接下来顺便谈谈「Node.js」，这个JavaScript™引擎是在浏览器中运行各种应用的关键。正是因为浏览器本身提供了相当多排版格式和功能，才有通过脚本「调用」之以实现「效果」的可能性。在线的办公软件都有，谷歌的GoogleDoc和微软的OfficeOnline就是例子，所提供的功能对于体制内外绝大多数办公室混子来说都够了。

然后就是另外一些不和谐的话题。比方说Mozilla曾经推出「应用程序框架」，以XUL为基础的，把一堆组件包装好，既能在浏览器中运行也可以在本地运行的开发平台，已经有第三方使用该架构开发商业应用成功的案例。而微软就推出以XAML为基础的WPF，算是视其为重要竞争对手的态度，哪怕是在纯粹的技术上。

后来嘛，一直也没关注，最近发现到了2015年XUL项目就结束了。理由也是之前说过的，谷歌扶持Mozilla挤压微软，达到既定目标之后就甩掉，自己单独推出Chrome窃取胜利果实。就看ChromeBook的宣传也知道，「所有应用都能在Chrome中运行」……那不就是「Mozilla Application Framework」已经做到的事情么。

所以，进一步的建议，开源社区可以考虑把这个「MAF」复活，哪怕改头换面去芜存菁旁征博引推出「魔改版」也可以。后台必要功能如公式和绘图等，还是以TeX相关既存技术为支持，以Lua为拼凑用纽带，前台当然要靠JavaScript™喽。

如果Mozilla同意或者第三方赞助，浏览器里面运行Lua也不是不可以。先例就是微软的IE里面可以运行VBScript，其它浏览器都不行。当年为了保险起见，对于限定IE专用的应用，我还特意专门使用闭关锁国内卷化的VBS开发呢。

但是呢，有个问题，「TeX」相关既存技术一点也不「轻量级」，不见得每个普通用户都需要下载安装「TeX Live」全套。所以「MathJax」的思路是正确的，「只提供HTML/CSS实现不了的功能」「使用LaTeX语法而已」。这措辞很严格，因为业内众所周知，不能编译第一版TeX文档的各种「魔改版」，不能使用TeX的名称，而TeX本身也已经「停滞」了。

对于「技术」停滞但「应用」活跃的情况，通常会认为其解决方案已经很「完美」只需要微调。正好这种情况，在信息技术飞速发展几十年之后的当代，于「二维平面」相关领域之中，普遍出现了，包括但不限于在线浏览和实体出版、动态和静态内容。

如果要唯物主义的解释，那就是因为人类的「肉眼」能接受的只有「二维」信息，啥「3D效果」都是人类的「肉脑」斗胆进行「脑补」的结果。在《〈设定集〉注释》当中贴了个动图，注明「一个旋转的四维超立方体在三维空间的投影在二维屏幕上的投影」，措辞很严格吧。

又到了按照惯例「泼冷水」的时间了，哎呀「情商负无穷」果然「思路广欢乐多」，这种「反革命乐观主义精神」充沛在「精神病仆街写手不入流码农数学渣」的整个人生经历当中吖，时时刻刻激励着我「倒拖渺小旗帜为了耻辱目标而错误奋斗」嘛。

前一篇流水帐结尾已经说过了「不会迷失在细节中赶紧总结然后干正经事」，那么本篇又扯了这么多细节是为啥呢？很简单，就是因为「正经事」导致的，按照恶补计划，过完年就该轮到「复变函数/复分析」了，并且由于假期想必几乎处处不方便，所以才在恶补告一（小）段落的时候提前准备。

境内教材众所周知不用废话了，除此之外还参考活跃学霸建议，翻出一本从美帝灯塔国引进的与时俱进版教材《可视化复分析》（Visual Complex Analysis）。在这本书前言当中，洋溢着对于物理和计算机的景仰，以及对「大成至圣先师」牛顿爵士的崇拜，还有作者对其座师「彭螺蛳」爵士的致敬。

于是，刚好「精神病仆街写手不入流码农数学渣」在这三个「兼职」的领域「样样通样样松」，并且由于曾经的工作经历，看到「可视化」这种字眼极为敏感。立刻就联想到了「二维平面」之上的计算机相关内容，包括但不限于各操作系统使用的图形处理引擎。

简单说，迄今为止所有的二维图形处理引擎，都是在「实平面」之上操作，早期处理点阵位图的「光栅」，后来处理矢量图形，都是这样。并且，其中把显示和打印这加色系统和减色系统两种对立的应用结合起来统一处理的解决方案也有，就是当前业界事实标准的「PostScript」，使用亲切关怀硅基而不是碳基的「逆波兰式」语法操作堆栈式虚拟机。

其中，被苹果扫地出门的乔布斯创业过程中的「NeXT」使用的显示系统，就是「Display PostScript」，把打印机芯片逻辑照搬到屏幕上，而到了「我乔布斯又回来了」之后，这一套演变为「Quartz 2D」，直到现在都是macOS重要组成部分，除了台式机之外，面向「爱疯溜溜溜」的年轻人开发的「哎屁屁」当中也在使用这个技术。

差不多与此同时，Sun™则使用同样的标准开发了「NeWS」，与「Display PostScript」不同，不是在图形处理完毕需要输出时才使用反人类语法，而是整个处理逻辑都运行在PostScript解释器当中。这个风格并不奇怪，能搞出Java™的公司，倾向于在虚拟机中运行一切那也是顺理成章的。除此之外，Sun™还搞出过JavaOS，纯Java™写的操作系统，可见其执着程度。

对于Sun™的这种思路，在硬件性能还不那么极大充沛的情况下，设计上可以使用「简洁完美」的逻辑，但实现上不如「丑陋脏活」的效果更出色，因此项目终止。到了后来，被「搅屎棍Oracle™」收购之后，具体项目哪怕技术上可行，但挡了「伪装成信息技术企业的律师事务所」的星辰大海の征途，都会被终止，如OpenOffice，前面提到了。

还有一个问题，当代主流处理器都是64位字长，很多情况下用不到这么高的精度。比方说显示或打印，32位整数就有正负二十多亿个像素或点，现实中足够了。正是因为这个原因，为了减小代码量，包括Java™在内都提供了「压缩指针」之类技术，把用不着的四个零字节「亦当删去」。

好了，铺垫了这么多，该说咱一拍脑袋想出来的「幺蛾子」了。既然这「复变函数/复分析」能「可视化」，肯定把数学上对「复平面」的操作映射到计算机操作系统当中显示引擎内部的「实平面」代码当中。那么，咱在极简主义风格指导之下就会「硁硁然」的认定：这是「脱裤子放屁多此一举」。

接下来就要严格的考虑「谁在放屁，谁需要脱裤子」这个严肃话题了。目前流行的显示引擎极大充沛，多半还把重点放在三维空间处理相关代码之上，使用了包括但不限于OpenGL等技术。这些技术毫无疑问都是「实空间」内部的操作，投影到「实平面」之上当然要比「复平面」更容易更高效。因此乍一看，似乎「复分析可视化引擎」没有位置了。

但是呢，正如前面提到的，图形处理本身无论如何使用「缓冲区」判断「像素深度」，到了「输出」环节都毫无意外的使用纯粹的二维点阵或向量数据，无论是发送到「显示缓存」还是「打印设备」都一样。因此，Sun™的思路作为「显卡」设计来说，其实是合理的。

新时代中国特色社会主义互联网上的活跃用户，恐怕不知道在它们受精之前就已经消失的需要单独购买的「3D加速卡」了吧？那么想必也不知道「浮点协处理器」曾经也要单独购买，编号「87」而不是「86」吧？这些功能都是可以分开的，集成在一起是硬件进步而不是软件进步，更不是数学上的进步。

哪怕从数学上看，复数相关运算除了处理浮点的部分之外，本身内容并不多，哪怕是旧世纪大学编程语言教学中也经常安排写个「复数运算功能包」当课堂作业。而较新版本的各种语言，甚至都有内置数据类型支持。这是软件层面的实现。

而在硬件层面，以一个64位的字作为「复数」，分成「实部」和「虚部」两个32位的数据，并设计针对性算法以电路实现，并不困难。因此，在「复数协处理器」的支持之下，以「复变函数」结论处理二维可视化信息的图形引擎，在数学表达上或许会更加「简洁完美」一些，实现中也未必「丑陋」且效率低下。

这「幺蛾子」的结论就是，所有相关的「计算机图形学」结果，尤其是专攻二维图形图像的部分，可以从「复平面」视角重新审视一遍。于是面对豪门贵种走兽派以专利覆盖方式进行的「多方围堵两面夹攻」，说不定能够避免钦定「死路一条」的命运，抛头颅洒热血前仆后继舍生忘死……其实世上本没有路，开源社区拓荒的人多了，也就成了路。

篇幅差不多了。今天还干了点别的，把《设定集》三点五篇『正文』和两篇『缘起』转换成「MarkDown」格式在「简书」发表了。这也是为了检验自己的建议之可行性。在轻量级码字的情况下，用不到「MaDoKo」那么夸张的扩展语法。不过「下标」之类简单扩展还是好用的，尤其是对于「aleph_n」写多了的场合。

顺便插一句，在码字中经常用「aleph-n」这种方式，一直没用下划线也是当年养成的不良习惯。在那万恶的旧互联网，既不提供LaTeX语法，也滥用格式字符，让我等老迈年高的脱离时代的网虫很难办吖。今后会注意与时俱进。

简书刚好提供了这个小扩展，并且还能上传图片。但是简书不能用公式，解决方案是挂在第三方服务商「CodeCogs」提供的外链上，比如：

但我还没试过，不过看也知道通过URL传递信息的公式不会太复杂，也不知道这第三方服务的稳定性和时效性如何，也不知道支持的LaTeX特性到底有多少，是否「够用」，还得等亲自体验过之后再说。