暴论: 所有编程课本都应该用 Org 格式写

如题。

编程教学中最常出现的模式就是“示例+运行结果”,太多人喜欢把书上的代码亲手敲下来,然后再运行。 如果课本是用 Org 写的话,读者可以直接 click to run,也可以修改示例代码(freely),看看运行结果有什么不同。

所以我认为使用文式编程进行教学,是一种教育方式的进步。 可惜现在连提供电子版(例如 PDF)的图书都没多少,特别是国内;而国内的高等教育更是个寄,有些课甚至连运行结果/示例代码都没有。

写笔记这方面也是类似,我以前都是 Markdown 写的,其实它跟别的标记语言相比并没有本质的优势。 后悔没早点了解 Org,这样写出来的笔记的复习效率就更高。

给还在使用 Markdown 的坛友列举几个 Org 的实用功能(P.S.,本人也是近来才全面切换至 Org 的,当然有遗漏,欢迎补充), 趁早换 Org 吧, 早用早享受

  • 上面提到的可以运行代码。实际上可以在同一个文档中运行各种语言的代码。它尽量提供了错误跳转,当成一个支持各种 PL 的简易版 IDE 就行。
  • 按照特定的方式组织代码。比如,你可以只写代码片段,然后 click to run 时 Org 会自动把它包装成类似 “include xxx,using namespace xxx,int main (){…}”的形式。
  • 说一个我学习时常用的 workflow: 我会定义一个用默认浏览器打开电子书的 file local variable,一个用系统通知提醒我阅读进度的 variable。(好吧, 这算 Emacs 的 feature. 但我以前写 Markdown 时用的大多是 Typora, 它是没这个功能的.)
  • 像 Excel 那样对表格进行计算。我在记笔记时有时需要画表格,表格中常出现用来汇总数据并显示计算结果的列, 以往是这样“a+b=c”的书写方式。如果使用 Org 的表格,既可以体现我要如何计算(也就是“表达式”是怎么写的, 比如在表格下方写 $3=$1+$2),又能随时修改前面用到数据,Org 会自动帮你更改计算结果。

楼主主要使用 Org Babel,而且没有探索更多的功能; 至于日程管理等则几乎没有接触,热心的坛友请安利一下。

以上都只是针对编写跟编程有关的文档, 我曾经也用 Markdown 写过一些数学笔记, 不知道在这方面用 Org 相对于 Markdown 有什么优势. 希望常用 Org 写数学笔记的坛友分享一下的自己的 workflow.

2 个赞

org 能用 latex, markdown 不能, 还谈什么优势?. 我为了用上完美 org math 写了一套自己的公式自动顺序编号的 elisp, 自己用得很开心. 但是 karthink 现在在搞的那个 org-latex-preview.el 是未来的最佳解决方案. 如果能成功开发出来, 那 org 就是毫无争议的宇宙最强数学笔记工具.

主流的 Markdown 实现都支持 LaTeX. 我想比较的是 Org Mode 和 支持 LaTeX 的 Markdown 实现

现在很多(AI,数据分析类)计算机课程作业或者辅助材料都是 Jupyter notebook+ 云服务,基本和楼主说的一样了,而且不需要装本地环境。org 要自己搭本地环境,而且对富文本支持不行,不太可能推广。org 核心优势还是 emacs 的定制能力,融合笔记阅读等其他生态

3 个赞

我也觉得jupyter notebook单就易用性来说比org强,毕竟基于浏览器,另外jupyter notebook还有一个优势是widget,数据可视化用的很多但是org这方面成熟的包很少。

Markdown 用的比较少,你说的支持是 MathJax 和 KaTeX 那种支持吗?如果是的话那还是算了,完全没有可比性。在 org-mode 里你可以直接写 LaTeX ,而且几乎可以预览所有东西。

Markdown 不能用 latex,latex 是一个几 GB 大小的 distribution. 普通 markdown 用 mathjax 之类的只能算是一个 latex 的有限的 emulator

对,虽然我们喜欢Emacs和OrgMode,但是对于大多数对Emacs没有兴趣的人来说,Jupyter Notebook毫无疑问是更好的学习环境:

  • 编辑方式虽然简单,但更符合大多数人已有的习惯。而且只是编辑少量代码块,简单功能足够用了。
  • 和OrgMode一样可以运行代码,可以编辑代码尝试不同的结果。对一般用户来说插入代码块比Org更简单。
  • 比OrgMode更丰富的结果显示方式。可以非常方便的在结果里显示可滚动的表格,可以交互的图表,可以显示动画。
4 个赞

所有编程课本都使用org格式写, 这个难度估计和世界上各个国家地区的人都讲 世界语 ,从而实现世界大同的难度差不多吧 :joy:

记得当年CCTV好像也教过世界语

“易上手”是一个虚假的优势. 理论上完全可以把 emacs 定制成一个开箱即用的笔记本启动器,让一切键位都符合大多数人的使用习惯. 甚至在最顶端做一排按钮用来插入代码块,删除代码块,etc. 只不过没人做这种事情. emacs 的复杂性对于不懂的人来说是隐藏起来的,我们觉得复杂是因为我们是 biased 的. 只要我们把这个虚构的笔记本启动器配置好,然后把 tutorial 做好,没人会觉得 emacs 笔记难用. org 之父也说过,org 虽然啥都能做,但是他保证只用其最基本功能的人依然能将其作为一个简单的 outliner 来用,复杂功能的扩展不应该牺牲基础功能的使用.

滚动表格和可交互图表这些,org 虽然没有,但是 ipynb 的实现也很弱. 我用 jupyter 的时候如果要弄个图的 zoom in/out,我宁可直接改个 range 重新 plot 一遍,也不想用那卡到没体验的交互. 事实上我往往做一个大 figure 包含多个 plots 直接同时看多个不同的 region,这个比交互实用得多. 真需要复杂的图表和数据之间的交互,ipynb 是不能打的,这个时候直接导出数据去 origin pro 上搞最方便.

就学习需求来说,集中处理的是 minimal examples,数据量小,此时对交互的需求可以忽略. 更实用的反而是对知识的检索以及建立知识之间的联系. 在这一点上,emacs 的各种花式搜索和 org 的各种花式 crossref 可谓吊打 ipynb. 顺便一提,我一直感觉 ipynb 的文学编程是虚假的,因为我找不到类似 noweb 一样的实现.

ipynb编写的教科书实例:概率编程和贝叶斯方法,我觉得效果很不错

“只不过没人做这种事情" 在我看来也是个虚假的理由,因为这个理由可以用来解释 80% 的问题,但是它掩盖了实现过程中的复杂性,而且 “没人做” 这件事本身就反映出一个很大的问题。

用 org 来文学编程已经不算是基础功能了,它需要你对 org 、Emacs 和 Eslip 都有一定的了解才能玩的转(至少对于我来说)

1 个赞

那我换个说法. 我对支持 LaTeX 的要求就只是能够正确的渲染我在文档 (包括导出的格式) 中编写的 内联 LaTeX 或者 公式块。

我个人觉得文学编程可有可无,编程与展示分开其实挺方便的。而编程教学更多的还是要传递语言特质,思想等,这个东西可用文学编程的模式展示也可以完全忽略它,没啥影响。语言的学习还是要自己去写实际的项目,文学编程容易让人追求形式,而忽略本质。

1 个赞

光这个点来看,org 没有特别的优势,甚至还有劣势,org 和 markdown 都是纯文本,在里面写一个公式比如

(\lambda ^2)

仅仅是一串字符, 用普通编辑器打开什么也不会发生 。

之所以能渲染成好看的公式,都是靠第三方库,比如 org-latex-preview 是通过 emacs 代码去调用 latex 里某个程序(latex 是一大堆工具,类似 gcc 工具集),上面那串字符串传给 latex 里的 dvipng 或者 dvisvgm 之类的生成图片的子工具,生成一张 svg /png 图片,保存在一个不想被人直接看到的路径里,然后 emacs 又去把这张图片读出来,利用 emacs 显示 svg 图片的能力展示出来,并且用诸如 overlay 的技巧把原来的字符串隐藏了。

typora 看到 markdown 里的相同的 (\lambda ^2) 字符串,也需要调用第三方库把它变成图片类型,这个过程和 emacs 类似,也是把公式字符串隐藏只给你展示图片。但它不是去调用 latex, 因为从易用性角度,它不会要求用户装了一个编辑器之后还要去安装一个巨大的 latex 工具库,所以它内置了一个更轻巧的解析 latex 公式字符串的引擎,叫做 Mathjax ,它是 js 写的,目的就是能轻便地渲染 大部分常用 latex 公式,并且转成 html,svg 等很常见的可视化格式,所以它的权衡是在效率和平台移植性,牺牲一点表达能力,但大部分人在 markdown里写数学公式也不会太复杂,基本够用。

类似的,把 org 或者 markdown 导出成其他格式的文件,也是需要调用外部渲染引擎,根据导出的不同格式可以用不同方式,比如 org导出成 pdf 可能直接就用 latex 来渲染公式,这样公式直接可以嵌入在 pdf 里,但 org 导出成 html 那可能就不需要渲染,而只要在 html 头里加上一个 Mathjax.js 的引用,然后你用浏览器打开这个 html, 浏览器去调用 Mathjax.js 从而解析公式,这时候浏览器成了最终的渲染引擎.

所以,如果能接受自己安装本地 latex,配 emacs -org, 用 org 记录数学公式相比 typora 的优势就是可以写出一些 Mathjax 无法渲染的公式(Supported TeX/LaTeX commands — MathJax 3.2 documentation 这是 mathjax 支持的 latex 公式集),用 typora 的优势是你安装完就可以开始后写了,并且预设的主题都比较漂亮。我在 emacs 或 vscode 里写完 markdown 一般都要在 typora 里修改并欣赏一下 :slight_smile: ,除了好看的另一个原因是,markdown 如果传到 github 远程仓库或者其他在线平台,从浏览器打开时用的渲染引擎也大部分也是 Mathjax, 所以如果本地用 typora 看没什么问题,浏览器打开基本也是没问题的,这是平台移植性的优势。

org mode 的优势在于,写完一段公式后,你可以在后文插入一个 pdf 某一页的链接,点开链接就在 emacs 里打开了某本教材或者论文对这段公式的详细证明或者应用场景,再在下方插入一段 python 代码,这是对该公式的代码实现,代码给出了一些样例,执行后生成了一个 plot 展示公式的某种性质,同时该公式所在的 org heading 又是另外一个知识点的 roam 的反向链接,可以随时跳过去,用带拼音的 fuzzy search 搜索某个关键词,定位到某个快要忘记的相关内容上 …

8 个赞

看你所谓的“渲染”是什么意思,如果你写了一堆 mathjax 的伪 latex,用真 latex 导出成 pdf 的时候可能会崩

1 个赞

python/Julia notebook 也可以。

我讨论一个 markdown 的简单的问题. 当然空谈 markdown 的时候我们都不知道具体在说啥, 软件不一样, 方言也不一样. 我就说 mweb.

以前我强度使用 mweb 的时候发现它不可能写长数学笔记. 数万字量级的大量公式笔记的预览100%会崩. 因为左边每次输入一个任意符号, 右边就会把全文预览重新刷新一次, 公式量大的时候, 连续输入符号, 预览反应不过来的就崩了. 我没用过其他 markdown 软件, 但我深度怀疑一切左输入右预览形式的 markdown 软件都有一个不算高的公式数量限制, 某些长笔记是会达到这个限制的, 公式太多了之后实时预览功能就等于废了.

另外说一点, 笔记一长, 写作过程中的前后对比变得必不可少, 就像看一本厚教材, 也需要频繁地前后翻页对比. emacs 的 buffer 系统允许你同时浏览并编辑同一个笔记的多个不同的部分(理论上可以无限多), 并且不会有保存冲突的心理负担. 我不认识任何 markdown 软件可以做到这一点, 除了本身支持多窗口预览的编辑器(比如 vscode)附带的 markdown 功能.

我之前也用org-mode多于markdown,但是现在除了多年前沿袭下来的一两个笔记文档,其他都换md了。原因大抵以下几条:

  1. 使用场景会影响使用频率。离开Emacs,org-mode几乎寸步难行;而我们几乎离不开网络(浏览器)场景,不管主观还是客观,用多了md,org-mode的语法势必会有遗忘或不熟。
  2. 个人专业原因,对统计精度的要求大于运算速度。所以很多计算用R,Rmarkdown搭配益辉大佬的 knitr ,简直是神器。关键这玩意儿还能更进一步,支持在编译PDF前设定更复杂的LaTeX语法。
  3. 没必要。如懒猫所说,看起来很酷的功能,静下心想想,我实际使用到的并不多,不能单纯为了使用而去练习工具。日常的简单使用,md够应付了,有复杂排版需求的,上LaTeX,也许是年龄大了,我现在更喜欢在纸上写写画画,感觉比电子版笔记更有效率。说到教学,我甚至还有个想法,有些很多年前定下的做法,可能本身就是为了在极端条件下比如木亥占戈时用最简陋的条件解决问题,后来形势变了但积弊一时难以改变。

PS,本回复使用md语法 :upside_down_face:

话说,世界语(Esperanto)最大的优势恐怕就是起个好名字了吧 :rofl:

4 个赞