点评一下王垠的新博文: Oberon 操作系统：一个被忽略的珍宝
2013-03-08 16:31:26
原文链接:
http://blog.sina.com.cn/s/blog_5d90e82f0101iq0n.html
主要是针对文中所说的各种特性,分别做一注解
王垠这篇文章也相当不错,他不在于说了什么好,什么坏,而是在于说好坏的时候展现出了很不一样的视野和水平,这比具体观点要重要得多,至少他看到了很多人根本看不到或者根本觉得不值一提的一些东西,而这些东西非常重要.
我不是要说这个系统也不怎么样,恰恰相反,这样的系统才是正确的方向,
也是为了解答这样的疑惑,既然都说得这么好,那么为什么用的人会这么少呢?
不需要为这些系统愤愤不平,认为软件业界都不识货,越先进的越没人理,不是这样,真正的原因是这些设计中的软肋,甚至是命门,阻碍了这样的系统在市场中成功.
1 这种系统里面的程序间通信不使用无结构的字符串，而是使用带有类型和结构的数据。在这样的系统里面，“程序”的概念基本上完全消失。系统由一个个的“函数”组成，每个函数都可以调用另外一个函数，通过参数传递数据。每个函数都可以并发执行。
点评: 这种让程序的界限消失,让所有函数都暴露出来,首先命名空间的冲突是个很大的问题,其次是效率.其实,之所以要有应用程序的概念,是模块化解耦合的需要,在应用程序内部的交互很多很复杂,但应用程序与外界的交互相对较少.其次,是省略上下文的需要,当你操作一个程序时,就进入了这个程序的上下文,无需再额外加上标识.真正的解决办法是保留概念,但换一种构造方法.
2 由于参数是一个数据结构，而不是字符串，这避免了程序间通信繁琐的“编码”和“解码”过程。使得“进程间通信”变得轻而易举。任何函数都可以调用另一个函数来处理特定类型的数据，这使得像 “OLE 嵌入”这样的机制变得及其简单。
点评: 数据结构依然难以承担传达信息的作用,unix之所以使用字符串,一个原因应该在于字符串是去类型化的,做到了最大程度的松耦合,一旦在交互中引入类型,事情往往变得复杂起来,有时候复杂到失控.
3 所有函数由同一种先进的高级程序语言写成，所以函数间的调用完全不需要“翻译”。
点评: 底层统一,让操作系统成为某个单一语言的运行时,这都是很高明的思想,但"翻译"问题依然是存在的,因为不同的知识领域会发展出不同的DSL,但如果这些DSL都是由同一种高级语言构造而来,互相兼容就变得轻松许多.
4 由于这种语言不允许应用程序使用“指针运算”，应用程序不可能产生 segfault 一类愚蠢的错误。由于没有指针运算，系统不再需要现代处理器提供的“内存映射”机制，以及 TLB。这使得内存访问效率大幅提高。而且简化了处理器的设计。
点评: 这是一个错误,也可以说是一个命门,正是这样的设计让类似的系统在市场中毫无竞争力.这个命门就是效率,不对用户提供指针操作和按地址访问,根本无法做到高的效率.这不会因为硬件性能的提升而缓解,而是一直存在,也将永远存在下去.事实上,已经至少有一个语言做到了通过比haskell还强的类型系统,在提供指针操作的同时保证指针操作的正确性,错误的操作不会通过类型检查.
5 操作系统使用与应用程序相同的高级语言写成（可能需要支持一些“特权操作”），至于“系统调用”，只不过是调用另外一个函数。
点评: 系统和应用的关系不是这么简单,系统调用不仅仅是调用另外一些函数的问题,系统如何对应用隐藏自己的实现,在FOP方法中是通过所谓的遮罩来实现的.
6 操作系统的“shell”，不过是一个这种高级语言的 REPL。用户可以在终端输入各种函数调用，从而启动进程的运行。
点评: 也不是那么简单,当然文章都不可能说得太详细,放过.
7 系统不需要 SQL，不需要关系式数据库。所有的数据都作为“对象”，保存在一个分布式的数据空间。
点评: 很难说这点是错是对,但"对象"思维是错的.
8 系统不需要“文件系统”。所有的数据，包括“进程上下文”自动被“版本控制”，在合适的时候作为对象同步到磁盘。所以即使在机器掉电的情况，绝大部分的数据和进程能够在电源恢复后自动继续运行。
点评: 这个是精华.但问题是依然在用对象,也是用"事物"来思考,而不是以关系的方式来思考.既然提到了版本控制,对用户来说,操作系统完全可以把从安装开始,一直到当前的所有状态都保存下来,任何时候都可以把这台电脑的所有操作过程从头到尾播放一遍.
9 程序员和用户完全不需要知道“数据库”或者“文件系统”的存在。程序假设自己拥有无穷大的空间，可以任意的构造数据。
点评: 这是对的,很多细节需要对用户透明.用FOP的话来说,用户只需要管逻辑关系.
10 为了减少数据的移动，系统根据数据的位置，选择： 1）迁移数据，或者 2）迁移处理数据的“进程”。程序员不需要使用 MapReduce，Hadoop 等，就能进行大规模并行计算。
这个操作系统是如此的“一致”，以至于所有的用户和程序员，只需要学会一种很简单的程序语言。
点评: 前面这句太具体,属于具体优化策略,放过.但后面那句是不对的,原因在于存在DSL.
主要是针对文中所说的各种特性,分别做一注解
王垠这篇文章也相当不错,他不在于说了什么好,什么坏,而是在于说好坏的时候展现出了很不一样的视野和水平,这比具体观点要重要得多,至少他看到了很多人根本看不到或者根本觉得不值一提的一些东西,而这些东西非常重要.
我不是要说这个系统也不怎么样,恰恰相反,这样的系统才是正确的方向,
也是为了解答这样的疑惑,既然都说得这么好,那么为什么用的人会这么少呢?
不需要为这些系统愤愤不平,认为软件业界都不识货,越先进的越没人理,不是这样,真正的原因是这些设计中的软肋,甚至是命门,阻碍了这样的系统在市场中成功.
1 这种系统里面的程序间通信不使用无结构的字符串，而是使用带有类型和结构的数据。在这样的系统里面，“程序”的概念基本上完全消失。系统由一个个的“函数”组成，每个函数都可以调用另外一个函数，通过参数传递数据。每个函数都可以并发执行。
点评: 这种让程序的界限消失,让所有函数都暴露出来,首先命名空间的冲突是个很大的问题,其次是效率.其实,之所以要有应用程序的概念,是模块化解耦合的需要,在应用程序内部的交互很多很复杂,但应用程序与外界的交互相对较少.其次,是省略上下文的需要,当你操作一个程序时,就进入了这个程序的上下文,无需再额外加上标识.真正的解决办法是保留概念,但换一种构造方法.
2 由于参数是一个数据结构，而不是字符串，这避免了程序间通信繁琐的“编码”和“解码”过程。使得“进程间通信”变得轻而易举。任何函数都可以调用另一个函数来处理特定类型的数据，这使得像 “OLE 嵌入”这样的机制变得及其简单。
点评: 数据结构依然难以承担传达信息的作用,unix之所以使用字符串,一个原因应该在于字符串是去类型化的,做到了最大程度的松耦合,一旦在交互中引入类型,事情往往变得复杂起来,有时候复杂到失控.
3 所有函数由同一种先进的高级程序语言写成，所以函数间的调用完全不需要“翻译”。
点评: 底层统一,让操作系统成为某个单一语言的运行时,这都是很高明的思想,但"翻译"问题依然是存在的,因为不同的知识领域会发展出不同的DSL,但如果这些DSL都是由同一种高级语言构造而来,互相兼容就变得轻松许多.
4 由于这种语言不允许应用程序使用“指针运算”，应用程序不可能产生 segfault 一类愚蠢的错误。由于没有指针运算，系统不再需要现代处理器提供的“内存映射”机制，以及 TLB。这使得内存访问效率大幅提高。而且简化了处理器的设计。
点评: 这是一个错误,也可以说是一个命门,正是这样的设计让类似的系统在市场中毫无竞争力.这个命门就是效率,不对用户提供指针操作和按地址访问,根本无法做到高的效率.这不会因为硬件性能的提升而缓解,而是一直存在,也将永远存在下去.事实上,已经至少有一个语言做到了通过比haskell还强的类型系统,在提供指针操作的同时保证指针操作的正确性,错误的操作不会通过类型检查.
5 操作系统使用与应用程序相同的高级语言写成（可能需要支持一些“特权操作”），至于“系统调用”，只不过是调用另外一个函数。
点评: 系统和应用的关系不是这么简单,系统调用不仅仅是调用另外一些函数的问题,系统如何对应用隐藏自己的实现,在FOP方法中是通过所谓的遮罩来实现的.
6 操作系统的“shell”，不过是一个这种高级语言的 REPL。用户可以在终端输入各种函数调用，从而启动进程的运行。
点评: 也不是那么简单,当然文章都不可能说得太详细,放过.
7 系统不需要 SQL，不需要关系式数据库。所有的数据都作为“对象”，保存在一个分布式的数据空间。
点评: 很难说这点是错是对,但"对象"思维是错的.
8 系统不需要“文件系统”。所有的数据，包括“进程上下文”自动被“版本控制”，在合适的时候作为对象同步到磁盘。所以即使在机器掉电的情况，绝大部分的数据和进程能够在电源恢复后自动继续运行。
点评: 这个是精华.但问题是依然在用对象,也是用"事物"来思考,而不是以关系的方式来思考.既然提到了版本控制,对用户来说,操作系统完全可以把从安装开始,一直到当前的所有状态都保存下来,任何时候都可以把这台电脑的所有操作过程从头到尾播放一遍.
9 程序员和用户完全不需要知道“数据库”或者“文件系统”的存在。程序假设自己拥有无穷大的空间，可以任意的构造数据。
点评: 这是对的,很多细节需要对用户透明.用FOP的话来说,用户只需要管逻辑关系.
10 为了减少数据的移动，系统根据数据的位置，选择： 1）迁移数据，或者 2）迁移处理数据的“进程”。程序员不需要使用 MapReduce，Hadoop 等，就能进行大规模并行计算。
这个操作系统是如此的“一致”，以至于所有的用户和程序员，只需要学会一种很简单的程序语言。
点评: 前面这句太具体,属于具体优化策略,放过.但后面那句是不对的,原因在于存在DSL.
转载于:https://blog.51cto.com/584250550/1243912
193
到【灌水乐园】发言
10 为了减少数据的移动，系统根据数据的位置，选择： 1）迁移数据，或者 2）迁移处理数据的“进程”。
.迁移处理数据的“进程”才是王道
"进程"(代码)和"数据"无法区分,所以两个是一回事
正是持有你这个观点才选2的，2比较符合你这个定义，1的话普遍的定义仅仅是个数据字段
嗯
所以，他说的"并行"通过迁移"进程"确实可以简单实现，可以实现一个不需要干涉（但可干涉）的“平行时空”，这样一来那个“时空”（运行时）里不需要预先知道将会接收到什么具体的“物质”。1的话，很明显指向典型的RPC，需要预先定义好“面包机”、“咖啡炉”、“绞肉机”等等任何可能要用到的工具。
> 我来回应