大学结束的时候我写了篇记录整个过程的文章，到现在已经有差不多一年了，也许是个时候再写个小总结性的文章了。倒也不是说这样的文章非得一年写一篇，当我有做总结的想法时，这可能说明我在某些想法上已经与过去的我有了很大的不同，把这些变化记下来必可活用于下一次。
与一般的玩具技术文章不同，这个不需要什么引用，也不需要什么大纲或者规划，写完作数(sou)，因此内容上可能相当不严谨。本来六月的时候这篇就已经完成了一小部分，现在就借着过去的我的内容规划继续写下去吧。
本文使用的环境为マサラダ的超预告篇。
在前一篇总结中，我尝试将学校里的学习叫做「自上而下」的学习，而将基于自己兴趣或求知欲开展的学习叫做「自下而上」的学习，并强调了后者的重要性。这差不多一年半过去了我似乎并没有对它们做更进一步的讨论。不过两者的实践我想我应该是足够了，毕竟上了这么久的学，写了这么多 emacs 相关的文章。目前看来我至少有这些体会：
- 基础的知识框架非常重要，相当于在脑子建立了符号到具体知识的哈希表，而且方便添加新东西进去。就 emacs 来说就像是 elisp manual 里的章节目录
- 自顶向下的学习很难带来创新，读文档学 emacs 非常操蛋，读完了不会有什么新想法的
- 自底向上方法能带来创造感，写 新的 代码时很爽
- 自底向上很容易陷入局部最优，好不容易辛辛苦苦写出来的代码拿出来一看，别人早就实现过了而且还写得比你好
这两个方法都有局限性，都得用才行，但我这话说了等于没说，给出的方法一点也不具体。下面是我的体会：刚开始的时候应该是 ↑ 的，需要根据一个小问题摸清具体的范围；接着应该是 ↓ 的，查找已有资料来尝试使用已有知识解决问题；再接着发现新的问题又到了探索的时间，↑；再次尝试从已有知识出发，↓ …… 如此震荡往复直到收敛至学习完成，一个比较自然的学习过程应该交织着已有知识与自己的实践与理解。但可惜的是一般不会有老师来教你解决眼前太过特定的问题，而且个人的探索过程也很难一帆风顺。虽然一直在抓瞎很好笑，但是倒也是无可奈何，不得不感谢 GPT 这个好老师。
大概快三年前，我立下了从 0 开始学习 emacs 的计划，并实行 lazycat 给出的一条推荐方法直到现在：（当然我的理解可能有些毛病）
【3】 你搞不懂 Emacs 复杂的配置的原因是因为你不懂 Elisp 编程, 学习 Elisp 的方法: 老老实实读 Emacs 内置的 Elisp reference manual, 这么厚的手册怎么学?
- 一页一页的挨着看, 一个API一个API的读, 不要跳过
- 每个 API, 都在 ielm 里面实践一下
- 遇到不知道啥鬼用的 API, 去 Google 或 EmacsWiki 上搜索一下, 看看别人怎么用这些 API 的?
我原本打算记下每个 API 的用法，给每个主题写一篇非常详细的文档，这也是我过去一直写 emacs 文章的一大动力来源。但我逐渐发现这是不可能的：
- 我没有这么多的时间拿来折腾 emacs
- 很多细节的东西对我来说是没有作用的
- 文档和 emacs 实现是会改变的
一年前有人完成了 elisp manual 的中文翻译，但是只有 markdown 版本，我曾打算将其整理为 texi 格式并勘误后重新发布。到了现在虽然有了 ChatGPT 的强大翻译，但我已经没有这个想法了，这个创建和维护所需要的精力不是个人能够完成的。实际上在大多数时候我们需要的并不是一个精确的知识，我不懂英语语法但不妨碍我使用英语，我不完全了解 emacs，但这不妨碍我使用 emacs，大多数情况下知识够用就行，并不需要我们成为专家。
没办法，虽然很多情况下深入研究是一件非常有意义的事情，但是「吾生也有涯，而知也无涯 。以有涯随无涯，殆已！」，在有限的资源下我们只能尽量把时间用在更加重要的地方（如果有人出资请我研究 emacs 倒也不是不行（笑））。原先我打算写一本结合了 emacs maunal 和 elisp manual 的详细介绍 emacs 各方面的书，但这对我并没有什么意义，也许对读者也是这样，因为我们绝大部分人都不会阅读源代码或是参与 emacs 的开发。目前我能做的大概就是就这自己感兴趣的东西写一点简单的总结，等待总结足够了可以考虑更新一下叶文彬前辈的《Elisp 入门》。在时间这个深不可测的沙漠上行舟真是困难啊。
不管是学习也好，工作也好，做研究也好，我们只能把有限的时间和精力投入到要的地方，其他地方可能只能够用就行了。じかんがありませんね～。如果您有学习 emacs 的兴趣，下面是我的建议：
- 能够上网和掌握一点英文
- 尽量坚持用下去，只要用的话就一定有改进的需求，有了需求就会有进步，但是失败了也没关系，我至少尝试了五六次
- 不管是什么问题，在无法找到答案时可以去 emacs-china 上礼貌地问问，会有人解答的
- 参考学习它人的配置，有空余时间简单翻翻文档了解 emasc 这个整体的功能框架和分类，翻翻就行，碰到什么东西感兴趣说不定可以写一篇博客
关于 emacs 的深入研究，我自认为我已经到头了（实在是没时间写了），除非有非常突破性的更新（比如 treesit），我应该不会写这方面的文章了，更多的是一些插件介绍了文章分享。估计最后的详细分析文章就是 elisp 的 OOP 了。大概四年前我还在嘲笑 30 多岁的表哥现在怎么连玩游戏都静不下心来，现在看看一集动画都看不下去的我，笑死。
为善无近名，为恶无近刑。缘督以为经，可以保身，可以全生，可以养亲，可以尽年。
不知道你有没有过为自己的什么人生观啊，价值观啊之类的玩意确定一套准则，找到所谓的哲学。年初的时候我就这这个目的找到了一本叫《哲学的重建》的书（能写这样一本书真了不起啊），对哲学什么的我秉持的同样是够用就行的准则，你也可以叫我哲学白吃。在找到这本书时我正在努力从哲学的角度理解什么是面向对象（当然还是失败了），顺带还问了作者一个问题：
【我】：在网上搜索抽象相关的东西的时候偶然发现了您的文章和书，简单阅读了一下关于抽象的一章，感觉收益良多。从文章的内容来看，您应该也具有非常多的编程经验（笑）。
我主要想咨询两个问题：
- 您觉得编程中的抽象都起到了哪些作用？各方面的作用都可以。如果您了解面向对象或函数式编程的话，您觉得这两种抽象方式有什么区别和联系呢（如果能聊一聊范畴论更好）
- 能否对我这样的未学过哲学或相关知识的普通人给出一些建议，我应该从哪里开始了解比较好？听说有一门叫做认知科学的新学科。
【岳耀】：您好。“抽象”其实在编程里有非常多的体现，比如“抽象类”，就是具体的“象”被抽离出来，或者说并没有被详细定义的类。其实只要有变量存在，就有抽象，因为变量就是只规定了类型，没规定具体值的量（或者说具体值被“抽离”了，但虽然被抽离，结构仍然在那里，不能随随便便找一个东西填回去）。面向对象的编程和函数式编程的区别不在于抽象，而在于“对象的结构”：这里的“对象”是广义的（《哲学的重建》中的含义），既包含了编程中的对象，也包含了编程中的函数。在你谈论一个函数和一个对象时，它们都是作为广义的“对象”被谈论的。对象的本质特征在于“封装”。函数的封装方式是留出输入输出接口，和有些学科中的“传递函数”很类似。编程里谈论的对象，是按照对人来说更为“自然”的方式来封装的：一个对象“有什么”，和外界怎么交互。通过这种方式就很容易设想出一个有很多层级的系统。这比函数嵌套函数理解起来更“自然”。
在我看来，哲学应该是一种比具体学科更抽象的理论。这种抽象应该意味着普适性。而严格的“普适性”就应该是没有例外。或者这样说：把它应用到数学领域，就产生了原原本本的数学，把它应用到计算机领域就产生了原原本本的计算机理论。它应该是一个把不同学科联系起来的“插值函数”，精确地经过每一个点。当然，为此它也必须要“抽象”。我把哲学理解为人类的普遍认知方式（就哲学的认知部分而言），当它被作用到从某种角度来看能被归为一类的对象上时，普遍的认知方式就被作用于经验（这里说的也包括抽象世界里的经验），就产生了学科内容。
关于抽象的那一章，虽然可以独立阅读，但这样阅读无法真正理解它的价值。《哲学的重建》第三部分建立在第二部分之上，也就是说用认知倾向公理来解释这些思维过程的发生原理，比如抽象这个过程可以进一步拆分成为什么样的思维运动。“认知倾向”是比这些东西更为“原子化”的“思维模块”。
关于认知科学和哲学的关系，可以参考《哲学的重建》的序言。
【我】：感谢您的回复，我昨天读了一部分，发现我将抽象与对象化这两个概念弄混了，过去我对抽象的认识就是“把多的东西变成少的”，现在看来还是太粗糙了。在面向对象编程中的对象会涉及到成员和方法，这应该算是一种对象化而没有到抽象的程度，只有类和对象才是一对多的关系。我原本想问您对象化是不是抽象的基础，看了书发现没有必要了。非常感谢。
看来对象化就一定会涉及到封装的。
《哲学的重建》尝试用八条公理来解释认知，但我倒也没仔细记忆，想起来这本书的时候我会回来翻一下。剩下的交给生活实践吧，毕竟生活处处是哲学啊（笑）。
关于面向对象的封装特性我最近真的是有了新的理解。根据墨菲定律，如果有多过一种方式去做某事，而其中一种方式将导致灾难，则必定有人会这样选择。如果某个变量被设为了公有，那使用它的方法就存在新的可能，那它就 一定 会被滥用。
鄙人发现在别人背后说人坏话是一件非常不好的事情，和很久之前的高中同学聊天的时候他跟我说了一些烦心事：A 对 B 说了一大堆 C 的坏话，当 A 知道 C 知道有人在背后说自己坏话时，第一时间想到的一定是 B，在涉及多人参与时这个问题还会更加复杂。ChatGPT 告诫我建立积极的沟通习惯和培养诚信是维护健康个人关系和社交环境的关键，构建一个方便好用的人-人接口是有利于减少整个系统复杂度从而增进合作的。这不正是封装之要点吗。
这一年我并没有玩什么游戏，看什么动画，已经电子阳痿力（悲），看看我惨淡的 Steam 年度报告：
 |
 |
游戏上没什么好说的，动画的话今年给我最大印象的应该是 「Do it yourself!!」，我在有人误拿我钱包钥匙回不了家的情况下花一个晚上看完了它，せるふ可爱捏。
 |
 |
到了这里总结也差不多结束了，整个总结也就是总结一下我对个人时间有限和力量渺小更进一步的认识。暂时也只能想到这么多了。
不管今年咋样，再过一周就是明年了，事已至此，先 Merry Christmas。