可以聊一下有意思的老软，不活跃开发但依然很有用。
TeX，Emacs，Vim 是三棵常青树。
APL 家族真不是给普通人用的。
Roff 实在太老了，除非写手册。
Plan 9 的 mk。。。你用它家的 rc 么？
Lisp 死而不僵 。
其它呢？Smalltalk? Forth?
硬核！为啥这么仇视 LaTeX ？ ConTeXt 如何？
因为我以前上文学课和哲学课，需要以 MLA 格式交论文，发现 CTAN 上没有 LaTeX 包是完整符合格式要求的，就用 plain TeX 开始写。后来写作业都是用 plain TeX 能解决就不用 LaTeX。
ConTeXt 我觉得卖点在 XML 工作流的支持上，但是说实话配置成本高，日常用不上。而不管是小规模轻度用还是排大部头，用 XML 现在还是基于 CSS 排版方便。
Matlab 作者承认当时因为看不懂 APL 所以自己重新造的这个轮子
光写简单的文本还能接受，但是没有 PostScript 知识的话很难用起来。 但是我学了 Troff 的 Pic 预处理器来画图，也能输出 MetaPost 或者 TikZ 这样 TeX 支持的格式。
mk 可以和 POSIX 兼容的 shell 一起用。用 9front 的话不会 rc 那还能做什么
最后流行的是 MATLAB 和它的一些免费模仿品，看来 MATLAB 作者不是孤身一人。 
你发了太多这种毫无建设性的话题，对这些东西感兴趣可以直接去学，没必要跑来这里闲聊。
如同知乎上的“如何评价xx"的问题，是在没有问题创造问题。提问者完全没有思考就跑去提问只会让我反感。
比如我自学过 Smalltalk，学习的过程中能感受到 Smalltalk 的与众不同。但这不代表 Smalltalk 是什么神功秘籍密不外传，任何想学的人都可以直接去学。
你如果在学习的过程中有疑问，可以发出来大家互相交流学习。但是上来就问如何评价 Smalltalk，只会让我觉得你在没事找事。
4 个赞
这个项目的作者通过他在函数式语言 workshop 上的演讲和自己的 youtube 宣传过 APL 的正确用法，就是代码应该是可以随时重写，随时废弃的。
我写这个知乎回答时引用 co-dfns 的代码，以及更早的产品原型，在现在的 project repo 里面几乎没有一行被保留下来。所以你根本没有必要研究回答里的代码是怎么工作的。
很多用着常见编程语言的人，看见代码里认识的单词，就觉得自己看懂了算法，能把别人写的代码复制过来，自己做点能修改，就算会了算法。APL 用大量的符号的结果是只有在思路跟的上别人，和别人经历过同样的思考历程后，才能看懂别人的代码。APL 重要的不是代码长什么样，而是通过对 APL 和对算法的理解，写出属于自己的实现，如果有了更好的想法，因为用的代码量少，可以毫无压力地重新来过，清除技术债。
原则上，APL 的可读性和数学公式差不多，比如我只给这么一个公式，不给你相关的背景，我相信你想破头也想不出是怎么计算的。在学过相关概念的人眼里，只要用的是常用的表记方式，都看得出来是在讲什么。
那如果我告诉你，E←{(+/⍵⌊1-⍵)÷+/⍵⌈1-⍵} 是这个数学公式的 APL 实现呢?哪怕你会一些基本的 APL，在没有对实现背后的数学概念的了解的情況下，看不懂也是很正常的。
2 个赞
这样存在一个问题：面对一个项目，你将不得不不断地从头重新学习，没有任何知识和经验能继承下来用于降低第二次、第三次甚至第 n 次学习的成本。
确实，但问题是你还得掌握 APL 那套符号/语法/语言机制体系才能意识到
就是在表示图片里的那个公式，APL 为什么不允许直接使用公式里的符号来表示这个公式呢？
不论是什么编程语言写的项目，一旦涉及专业的知识，光靠读代码本就不是正确的学习方式，比如 MetaPost 的代码涉及贝塞尔曲线的操作，哪怕项目用了文学编程，代码边上就用 TeX 写了公式，我也看不懂，因为我没学过图形学，这就是专业性。但是如果是我学会掌握的内容，不看別人的代码也不影响自己会写。相反，以我比较了解的矩阵计算代码为例，如果用细节太详细，还根据编译器手动优化过的代码(还是用 ALGOL60 写的)对着照写，只会扼杀创造力，导致写抄出来的代码千篇一律，变成祖传代码，而且当计算机架构变化比如用上 SIMD 以后，所谓的优化就会变成负优化，无法做大改动。如果用 APL 写，哪怕最终写的代码和示例完全不一样，用的还是一样的原理，因为不涉及任何实现细节，反而比较容易优化。
而且这样的言论过于想当然了，哪怕在这样的学习过程中，对 APL 知识不会有一点儿提升吗？
错了，哪怕你会 APL，我也不能指望你没有 fuzzy system 的知识的情况少看出 {(+/⍵⌊1-⍵)÷+/⍵⌈1-⍵} 在算什么。同样地，如果没有足够写函数式语言编译器的知识，不只是看过点书或跟者教程写过项目，也不能指望你能看懂 Co-dfns 的代码，。
而且无论用什么编程语言，这些问题都是存在的，只是用自然语言命名 operator 和 function 的 编程语言里掩盖得好一点，在 APL 这样代码缺少信息量的情况下明显一些而己。
确实需要学习专业知识和读代码结合，但是 APL 的做法无疑增大了理解代码的难度。
错，并不是掩盖，而是给了读者学会的机会。APL 必须是精通领域相关知识和 APL 符号/语法/语言机制两者缺一不可的专家才能驾驭。
但是你可以知道这是图形学的贝塞尔曲线，还有通过补习相关知识来看懂的机会，而 APL 连这个机会都不会给的。
你不会是给自己学不会找借口吧
好的，那请你阅读一下 metapost 代码，解释一下 arctime 操作的实现方法，如果不会的话你可以学
https://tug.org/svn/texlive/trunk/Build/source/texk/web2c/mplibdir/mp.w
我之前解答过相关问题，不过我认为因为我专业性的问题写的答案不尽人意，如果你能给出一个比我之前回答更好的回答(之后再给出链接)，我才能认可你的观点。仅做为参考，回答 arctime 实现的问题我用时约四小时，并之前从未看过 metapost 代码。
另外，我知道是贝塞尔曲线，只是因为 metapost 用了文学编程，而不是从代码推出来的，实际上 metapost 的代码可读性非常之槽，结构之乱，几乎没有参考的价值。
为什么？是你看不懂吗？但是有很多在高中教会学生 APL 的例子，甚至有人是11岁就学会 APL 的。不知道为什么，我认为这种言论里对自己学不会某样东西不以为耻反以为荣的心态很重啊。
别的先不论，就先说这个：
“很多”是多少？学校教了不等于学生学会了，能证明教中学生 APL 他们的掌握程度能比教 C、BASIC、Python 更好才是关键。
很好，你失去了最后一次机会，恭喜你提到封号套餐，请你完成 arctime 作业以后再说