@kyuuseiryuu 似乎你一直以为是我不懂……
现在理学工学硕士不必修科学哲学了？就是“不会考”也要混到结课吧？
不同的学科是自然科学的分类，还哲学是科学……中特马哲都没敢这么说吧。
了解一下科学实证主义是什么时候破产的行么？

@secondwtq 能打的，是指不“单调”么？ SGML 和 DSSSL 了解一下？（

@exip 要表格什么的 md 就没救的……看这需求是没跑了。
程序员也干不过 markdown 方言兼容和残废（比如 Bitbucket wiki ）问题。

不同文档面向的用户和维护需求不同，为什么要强求使用相同的实现？
（要不需要编辑，直接 pdf 都行。）
要强调检索那得结构化数据，都不应该保证存的是“文档”。
去微软化？自己实现个 ISO/IEC 29500 ？

全金属壳充电不严格接地线不都会漏电么。。。限制接触电流大小和位置是不是尴尬的问题罢了。

@skyrem WSL1 里直接装 arch 无所畏惧……反正内核滚不挂（
最危险的也就是 glibc 滚挂了开不了 shell 而已，反正文件系统内容都能访问，就是麻烦点。

@kyuuseiryuu ……你是不是能找些搞物理的老师确认一下。
还有搞科学哲学的。

你要是恩格斯那种，砸钱做生意大概也是有前途的……

……这是不是错区了。。。
（《奋斗吧，系统工程师》之类动画化还坑着……）

一时抽了 typo …… derivation→derivative

@anonymous256 GPL 没有明确要求这样做，因此不需要提到。你可以提供说明文档解释你提供的资源的不同部分适用不同的许可。
技术上，你的软件利用的是同这个 GPL 的 exe 兼容的命令行接口，而非被 GPL 覆盖的命令行接口的实现本身，因此提供显式的依赖声明反而是不恰当的。另一方面，你有理由（例如，为了用户的便利）而一并提供不同许可证覆盖的工作——这样的工作不和你的作品发生直接的联系，仅仅是偶然捆绑在一个渠道中提供罢了。

IANAL，不过按一般理解，GPL 的传染性影响的是 derivation work，而你可以做到不属于这种情况。
（当然，要更靠谱的解读你可以直接联系 FSF 确认。）
stackoverflow.com/questions/405208
GPL 不允许你 relicense，因此你发布的 GPL 覆盖的 exe，除非有其它许可，还是得按 GPL 发布。
GPL 原则上要求你同时能提供发布的二进制程序的源代码，你为此需要提供对应的源代码资源，可以是副本或者链接。

@zpf124 虽然 Java 和 JVM 耦合有些过头，JLS 原则上不管 JVM，后者由 JVMS (Java Virtual Machine Specification) 规范。两者一定程度上是独立的。
例如 Dalvik 上能实现的 Java 能符合 JLS，但 Dalvik 不符合 JVMS。这也体现出加了私货在名义上有问题，但实际上能（单向）兼容的情况（虽然不是 Java 语言这个层次上的）。
很遗憾（？），现状就是 spec 本身约定的技术没法限制这些使用。（当然，法律一定意义上倒是可以算另一个次元的技术……）
JLS 的确是有自身特殊的鸡肋，一个原因是实际起到作用的各种平台规范太多而架空了（有很多不同方面的现象，例如，JavaSE 这个配置在 Java 生态的占比的弱小，再如 JLS 过分依赖 JVMS ）。
这根本上也不是技术问题；这造成的文档等支撑项目的维护成本就技术角度上其实是很不经济的，只不过所有权人看上去不在乎这个（或者有意乐意这样抬高某些门槛）罢了。
但无论 JLS 在整个体系里的存在感多弱，都改变不了 JLS 是用来规范 Java 语言本身的首要文档这个事实。要推翻这点只能靠标题党诈欺了，还没谁做到。

@masker 那看起来是更本质的适合不喜欢把自己理解为计算机的人适用的抽象。

@kyuuseiryuu 先有物理再有数学对吧。
那么先有物理学还是先有数学呢？

@beginor 那看起来确实解决了一个痛点。反正横竖要 Hyper-V 的话……
不过对想把 hypervisor 腾出来的场合还是不爽的。

草，一边隔壁黑 generics，一边厢这里把 general 都 typo 了……

@goodlexiao 命令式的对立面是声明式，纯函数式？没排面的。

@thautwarm

不满足 1 的语言多得很，比如 C。说这样的语言抽象能力烂，一个原因就是因为 C 没支持和 lambda abstraction 对应的 first-class functions。所以这个分类到现在仍然显然是很有现实意义的。

而历史上 1 的资格还就是比 2 和 3 老的多，描述 paradigm 上本来就没要往 pure 上靠，更没什么 algebraic data type 什么 pattern matching 之类细枝末节的东西存在的空间。

数学上本来确实有足够多 pure 的东西，但拿 pure 上位要搞 generic-purpose 语言的，还就是从 DSL 里强行上位的 ML 系的功劳，根本就代表不了之前的工作。

注意自动定理证明一直是非常 domain-specific 的，在方法论意义上都不算普遍，甚至根本搞不定方便地表达不预设前提的“计算”。而从中搞出来的语言的差别大部分就是口味问题，并且有一些过于功利性目的论的内卷偏好——类似有些数学家强行喜欢 sequent calculus 或者 natural deduction 却从来没法成功地干掉 Hilbert-style deductive system 的地位一样。

非要概括这些东西，那么明明 pure 比 functional 还更关键，为什么非要舍弃？这显然不符合自然语言的省力原则。所以我的理解就是某些人有意无意搅混水方便灌水而已。

@Shaikh 因为各种 paradigm 都想支持，历史包袱又大，到处都有人想拿来强行搞不适合开发的东西，结果就是各种屎都沾上了。

@charlie21
1.Anders Hejlsberg 老实搞 TS 比这个前途是大得多了。
2.剩下的哪天 ECMA-334 更新了再说。（不太想对指 finalizer 为 destructor 的材料文明用语。）

@powertoolsteam 贵司现在全面转向 Web 了吗……业务领域是和印象中的有些不一样。

@thautwarm Haskell 就稍稍吧，不说某些 ML 系的魔改方言，类型系统弱鸡到被 Agda 之流的 DSL 旁门左道都能打得满地找牙……

你的历史认知似乎有点奇怪。
一说实话是玩具，连妥协的门槛都没进。用起来顺手的外行更多不表示在工业界里发达到需要多少妥协的程度了，本来不同的专业开发者之间也没太多交集。
二是理论研究过气三十年的玩意儿了……
三是差不多六十年的玩意儿了……不过你应该没考虑到 fexpr 之类的玩意儿。早期 LISP 都没很强调代码即数据，专门生成代码一条道走到黑的已经是 Lisp-1 和 Lisp-2 分家之后的事情了，但即便晚到按 hygienic macro dssq 这样算应该也不止三十年。

你所谓的未来也别多想了。
砍掉 first-class side effect 的东西，说实话只能当 LIR，而且不能解决严重的性能问题，连 LIR 都当不好。（你有见谁整天拿 C++ TMP 骗饭吃的么。）
现实就是没个靠谱的。