@zzzzzzZ 我怀疑是你更需要补充网络常识。你似乎不太明白你讨论的所谓开源是指什么。（虽然开源不开源跟免费不免费没直接关系这点你似乎是理解了？）
作为常识，公认的“开源”指的是符合 OSI 定义的 OSD 的概念，主要依赖版权法，并没有什么直接适用于编程语言的保证。
说白了，编程语言是跟数学公式类似的东西，不限定某个材料上拿来发表，根本就不 copyrightable。
能被版权保护的，是出版物、文档、程序代码之类的材料。而能被专利权保护的普遍更严格。
然后问题是，剩下不限制供给又不受保护的东西，没谁有义务交钱。凭什么你说不免费就不免费了？
不过你倒是也承认，公开语法之类的设计根本不算“开源”。
然而“语言”指的首先就只是这些东西。或者实际问题是，你对“开源”的理解问题还不那么大，而对“语言”的理解有偏差？
你对 C#现状的了解看样子非常脱离实际。不使用 VS 商用 C#的多了去了……
照你说的，“.NET 相关平台”在非 Windows 下就是盗版？先不说有没有，你想清楚了没，能盗谁的版？
而且你似乎没分清.NET Framework 和.NET Core。
题外话，C#不只有这几个实现。你当 Mono 干什么吃的？

@q397064399 没谁否认模块化和可维护性的需求和重要性。
（实现这些需求不只是分层，分层还有某些特有的过度设计问题，然而这些都不是重点……）
重点是，你之前就没提分层，之后又把抽象层次搞混了。
一开始的所谓的“冯氏图灵机”根本就没分层，而且跟这个思路根本没关系，反而脱离实际。
我重新想了下，图灵机可能真的是 CS 导论和基础课程根本就不怎么讲的结果，那个冯诺依曼大概是组成原理以讹传讹？
历史上冯诺依曼架构（普林斯顿架构）、哈佛架构、改进的哈佛架构之类的设计包括哪些玩意儿都是相对明确的。
而包括你在内不止一个人似乎是把冯诺依曼架构和存储程序计算机搞混了。（被张尧学之流忽悠瘸了？）
冯诺依曼架构在 First Draft of a Report on the EDVAC 明确，只是存储程序计算机的一种。
现在的架构没逃离的是后者。这个思路说白了也根本就不是冯诺依曼先搞出来的，不会晚于 30 年代。ENIAC 前这个概念据说就很流行了，只是不知道最先是谁搞的。
更直接的问题是，冯诺依曼架构有冯诺依曼瓶颈之类的问题所以需要改进，而现在根本就没动机干掉存储程序这个设计……（难道还想退化成硬布线的计算器？）因此也根本不需要强调通用的计算机是存储程序。
至于屏蔽 ISA 以下的细节没问题，但是你提的取指以及并列的读数据、写数据（我理解成从数据通路里转移数据），这恰恰就是应该被 ISA 屏蔽的东西。
组成原理讲这些简单的实现帮助理解是没问题，但一知半解结果上就是破坏分层了。

@starsriver ALU 这个名字描述的是模块功能，不是具体的实现。我不清楚你所谓的“本质”论是哪来的。FPU 的本质是不是也是线性累加器？
你看起来一点都不了解实际工作是怎么完成的。找一坨实际 CPU 执行单元中 ALU 的 RTL 设计看看再说。或者在此之前，你示范一下如何靠线性累加器堆出硬件除法器？
微码跟汇编没直接关系。就算是类比，微码本身也是类似机器码编码出来的代码，而不是源语言。
微码的源语言说白了根本就没必要公开，也没多少汇编用户碰过，你怎么确定跟汇编“本质”一样？你做过微码实现方案？
（很多人习惯把机器码和汇编混淆，如果他们能清楚汇编器做了多少多出来的破事以后可能会清醒一点。）
要是觉得这不可理喻，要么你来定义一下什么才应该是基础，然后指导一下现在的厂商怎么做？

@zzzzzzZ 你可能是假版权法和讼棍骗子的受害者。什么东西算盗版，语言是不是有所谓“开源”，补完法律常识课再说。

@lithiumii 对 end-user 来说，你如果是 MATLAB 的用户，同样是 MATLAB 提供的所谓 MATLAB programing language 的实现的用户。这时候你可以不区分它的哪部分才是语言实现，因为 MathWorks 就没发布单独产品能让你把 MATLAB 中的语言实现甚至语言本身剥离出来单独用——锅的源头其实是懒得单独给语言命名。（不像 Mathematica 最后总算是挤出来个叫 Wolfram Language 的……）
但是考虑重新实现语言来讲，就完全不是这种情况了。不把作为整体产品的 MATLAB 分开就没法说清楚做的是什么。这时候 MATLAB 这个名字还是留给整个产品清楚点。MATLAB scripting language 是引用维基里的限制得比较明确的说法，或者按官方的说法得拿 MATLAB programming language 消歧义。
讨论语言单独具有的权利时也是如此，所以至少不加区分是有问题的。
（也有类似其它抽风的比如，Perl 是语言，perl 指实现。）

@zzzzzzZ 开发环境收费算是编程语言收费，你能糊弄过法官再说。
C#不交钱不给商用？没给钱商用.NET Core 的是不是先要挖掉 C#的实现？
正常的标准库一坨 spec，都没担保提供参考实现，哪来的源码，开的什么源？就算是指实现，至少 VC++自带的 Dinkumware 长期以来就一直不是“免费且开源”的。

@vsitebon 那个 Quora 挂的第一个答案就有问题↓
@lithiumii MATLAB 不是语言。
我不知道有什么能合法有效完全地阻止你自己实现一个兼容的 MATLAB scripting language 然后免费发布（当然，不能侵犯其它权利，不用同样的名字）。

@mokeyjay @qq292382270 类似地，我不知道谁能合法地完全阻止你山寨一个兼容易语言的其它语言的实现免费发布。

@shijingshijing 指令集不是整个授权的对象。要告基本上就是折腾专利。
否则 QEMU 之类的模拟器早就万世不得超生了。

@littlewing 我不觉得 Oracle 还能造出不存在的法律并立即生效。

另外，就算是软件实现，一般版权法也不限制使用——直接限制的是类似非法复制之类的传播和修改后再次发布的衍生作品之类明确有限的一些情况，这不包括软件的“使用”。
不过中国的法律要求你停止使用明知侵权的软件。

@bbdk 要收费，依据是啥，合同？“知识产权”？
得了吧，这方面只要不是提前约定，只要你拿到了货，本来物理上就是“免费”的。即便是法律默认限制的专有权利，一般也不会直接干预原样的“使用”，除了非常个别的诉讼标的（比如专利）。
真要说有什么直接的限制，就是生产者硬是不给你货——直到你交钱交到他满意为止。
这种限制的直接来源是生产者自身的意志。
一开始，新事物的生产者往往更热衷他们的作品能被接受，至于作为商品卖钱，那是后来的事。
像公开发行的软件在历史上一开始就是免费的。直到 Bill Gates 发了公开信说可以并且应当通过向用户收取费用来赚钱，收费才 dssq，变得像是主流了。这方面很多传统黑客一直反对，认为是剥夺了他们的“天赋人权”，所以一直对着干——比如 FSF 的抠脚皮大汉 RMS。（不过现在主流商业模式一转攻势不少软件又“免费”了……）
至于语言，如果是捆绑到出版物，卖不卖钱都很自然（类似论文）。但通用目的语言本身的设计，虽然有独创性，却更接近数学公式。有多少人会支持对数学公式的用户（而不是提出和记载公式的论文或者特定实现的用户）收费？法理和实际操作上的可行性何在？
另外就是语言推广起来更麻烦。没预设的稳定用户群体，就没什么收费的基础。（后者通常都是比较特定的领域才行得通。）
这些因素合起来就是越通用的语言基本上越不要求收费使用。
（题外话，作为财产权的版权一开始算是盎格鲁-萨克森流氓搞出来的“阶级斗争工具”，某种意义上挺不尊重作者的。）

你这隔离方向有点问题，要审计内网资源还挺麻烦的；公用外网环境乱占用资源搞清谁的锅也麻烦。
可以考虑内网瘦客户端远程到内网服务器，外网环境机器不限，要跨边界传输资料要申请。（不过也不便宜，主要是适合原本就有集群执行关键任务的单位。）
（保密需求再强点的还有多级内网和人员物理隔离……）

@onionKnight888 这样实施是嫌 IT 成本太低了么……一般的机器，就算是瘦客户机都能直接主板配置成禁用然后密码锁死。难道你们工位周围一点监控都没，还怕你们上班拆机放电？

你肯给钱？讲出你的需求，看看有没有人接单。

@geelaw 就“在任何……总是被支持”，指的若是程序(strictly conforming program)，且限定是 hosted implementation，则你的补充是对的；除了 ISO C 在 Program startup 一节中对 main 有显式允许“ or equivalence ”的说法（其中一个例子就是 argv 的**和[]的等价性，见脚注）这点外。
int main(); 不是任何 ISO C 实现都被要求支持的声明，除非同时存在被要求支持的 main 的定义之一的原型声明。此时，前者是和定义兼容(compatible)的函数声明。
但若 int main()出现在函数定义中，这仍然是要求被支持的，因为 ISO C 的说法是 defined ... with no parameters ... or equivalence，并没说此处的声明必须要有原型或者必须是明确的(void)（甚至没说是 parameter type list ）——尽管函数声明符中的()是 obsolescent feature ——所以即便排除原型保证的 diagnostic 的好处，定义中写成 int main(void)仍然更好。

@geelaw 你的说法是错的。之前我给的链接有提供原文引用和分析（新的标准修订版本原则上不会改动这里的内容）：
github.com/FrankHB/pl-docs/blob/master/zh-CN/main-function.md
首先的具体问题：你提的“正确”事实上对不上标准中的和一般理解的“正确性”相关的要求（不管是形式语法、以 shall 明确的条款、constraint 还是 well-definedness ），不管是对 conforming implementation 还是对 program 来说。
标准对 conforming implementation 要求需要支持两种的 main 声明，这不表示禁止其它任意的扩展（也不直接禁止程序使用这样的扩展）。例如，ISO C++明确禁止非 int 返回类型的全局 main 函数，但没对参数类型有同样的限制。
你的另外的一个技术错误是无视了 C 和 C++的不同。C 的 int main(void);原型声明对应 C++的 int main();，但 C 的 int main()作为声明并不等同于 int main(void);，在 C++中近似 int main(...);。
函数的签名(signature) 在 ISO C++ 中一直有明确定义（用于支持重载等），不同版本的定义有差别但都排除了返回类型，参见[defns.signature]。
ISO C 没有明确对应的“签名”概念。日常所谓的“签名”，语源是数理逻辑，一般是指“函数类型”，注意这和上面的 C++中的定义有差别——它依赖返回类型（而 C 和 C++ 其实也是有这样的“函数类型”的概念的）。在 C 从 C++ 的设计中照搬来原型声明这个设计之前，“签名”的含义是不怎么明确的。特别地，C 仍支持 () 参数列表这样明确不指定参数类型的情况。所以虽然你说的“日常理解的含义”虽然不算有很大的普遍问题，但这个上下文中反而会引起混乱。

@geelaw 我不记得有哪个版本的 C/C++ 标准提出“正确的 main 的签名只有以下 2 种”（姑且搁置“签名”是指什么的问题）。请核实并指出来源。

允许 void main 还敢装做是 C 或者 C++的，除非是特定 C 的 freestanding implementation，就是扯蛋。
注意 C 和 C++略有不同。
cf. https://github.com/FrankHB/pl-docs/blob/master/zh-CN/main-function.md

剩下的问题，主要来自 C-like 语法的不成熟的语法设计：
https://github.com/FrankHB/pl-docs/blob/master/zh-CN/about-syntax.md#%E5%85%B3%E4%BA%8E%E5%8E%86%E5%8F%B2%E9%81%97%E7%95%99%E9%97%AE%E9%A2%98%E7%9A%84%E4%BE%8B%E5%AD%90

如果允许，使用 string[] args 这样的风格是更推荐的做法。不过，C 和 C++中根本不允许这种语法……
考虑到 char**本身倾向于造成理解上的含义混乱（凭啥不是 const char**或者 char* const*……，凭啥*表示数组而不是 in/out parameter ）而且[]允许字面上更好的可读性（虽然不被语言支持，但起码你能自然地写[/*size=1~3*/]这样暗示源的预先设计的范围），个人建议 char* args[]而避免 char** args。
类似 char**这样的写法，基本上在 C++不应该出现，因为没什么合适的理由使这种潜在有歧义的写法显得有必要。而 C 的 char**可以表达 C++的 char*&这样的情况，约定只有这种情况使用 char**，则用意相对是清楚的。

@littlewing 请不要再迫害冯诺依曼了……
纯冯诺依曼架构下的 CPU，共用总线读取指令或读 /写内存数据，没缓存没法并行。
你家“现代计算机”能受得了这种限制么。

@q397064399 我指出的是你所谓的这些抽象对底层实现者还是对高层用户都没有什么实际意义。因为实际的场景几乎全不是按你想象这样抽象的。
你给的模型典型实现中只是在微架构层面直接相关。ISA 以上的用户虽然被允许利用某些特定实现的知识做启发式优化，但一般根本不需要依赖这种模型编程。原则上，一些时候还应该避免做得到，否则就是泄漏实现细节的问题了：制造 side-channel attack 的机会是安全设计上的 bug。
另外，在 ISA 的层次上划分软硬件的分界只是侧重商业角度上的保守做法，不是普遍必须的。“指令”都不一定是硬件接受的编码处理的基本单位。

回到主题。
“关于软件构架与设计方面涉及到的问题、面临的困境、解决的办法似乎根本没有变化过。”
不对，是多出很多新的问题，而解决问题受到的限制更大了，而且整体演化成了没法单纯从技术上面对的问题工厂。
20 年前，软件规模要求的压力显然没现在这么大，原始需求的问题领域也没现在那么丰富。
而 20 年来软件开发人员成本的增长不足以支撑软件开发人员完成多出来的需求变化需要的能力的增长。
因为大多数管理人员习惯用“水平扩容”（增加资源数量）解决问题，在遇到人的瓶颈（总工时）也没有什么好的方案只能照猫画虎（要扩招更要 996 ），反而加剧了传统软件工程的问题（譬如，沟通成本）。
更有甚者，从业人员的平均基础水平实际上是下降了。
这一方面是因为现在的开发人员很多场景下分工过于专一，普遍欠缺考察迁移问题解决方案的能力的场景，要求降低了；
另一方面是基础教育本身就歪了（想想 SICP 都改用 py 了）。
这进一步导致解决新的问题时会倾向于专一而便于靠堆砌资源数量变通的解法，却不注重解的结构和内部关联，更不关注维护现有解决方案的成本去除冗余。
很多所谓的新的技术就是这时候炮制出来的。
由于“新”的技术越来越多，又不没几个人去查重归并，以后这方面问题复杂度会越来越高。
仅仅是“学习”的问题，其实算不上什么事儿。真正开始体现影响的是选型成本以及应对碎片化的机会成本。这时候就各显神通了：无视的无视，diss 的 diss，还有自己糊屎取而代之的。
直白点说，问题增长得本来就不慢，试图解决问题的人似乎有效地解决了一部分问题，但实际上制造了更多其它的问题，而且越来越不容易解决。这个倾向比原始问题快得多。
字面上，这当然能算得上技术变化很快。只是不应该那么快。
按理说人的忍耐总是有极限的。可惜现实由于韭菜（资本和相对低端的人力资源）仍然大批量进场的问题，这部分暂时还没法平衡，还会在天上飞一阵子。

啥叫“过于”严格。