- 主题:所有 bug 的根源
我发现所有 bug 的根源都是分散式的映射管理。野指针,mutable,pass by ref,面向对象,这些全都是导致分散式映射管理的途径而已。
任何两个值的关系都是一种映射,比如 child - parent,root - leaf ,result - operand 。这些映射关系通常是保存在一个实例的属性里,并且通常是同时被多个实例共同保存。比如 parent 保存自己 children 的一个数组,而每个 child 保存自己的 parent。这些属性通常是以 refrence 的形式保存。但这种映射通常是会变化的,所以一个映射改变会涉及到多个实例,而这种联动往往会涉及到 corner case ,导致数据不一致。
解决这个问题最好的办法是集中管理映射关系。每个实例不再单独记住各自的关系,而是由一个集中的 map 来表达这些关系。听起来是开倒车,但其实是最不容易出错的做法。这样其实是把每个实例当作值而不是对象来处理,那么在做语法语义分析,静态分析的时候,可以用更接近代数的方式来思考,在表达的时候也可以更接近代数,很多逻辑可以用代数的形式来表达和演算,出错的机会会少很多。比如说有一个需要做 abstract interpretation 的场合,本来需要模拟运行所有指令,我最后发现竟然可以用矩阵运算来表达,不管是运行效率还是表达方式都是后者占优,而且后者也不容易出错。
--
FROM 85.76.66.*
我还没想过状态应该怎么维护 感觉状态和关系又不太一样
【 在 allegro 的大作中提到: 】
: 我的感觉是一个原则:尽量减少程序的state,不引入冗余的state。程序应该是描述各个state之间的关系,而不是一个 ...
--
FROM 212.149.166.*
跟函数式关系不大 分散和宂余的关系表达用 haskell 也一样会遇到
【 在 henryoung 的大作中提到: 】
: 函数式编程? ...
--
FROM 85.76.66.*
你对停机问题有误解。上次你问我为什么并行最优化可解的时候我就回答过你了,凡是可枚举的 *某一个* 算法 都跟停机问题没关系。尤其是,所有跟停机问题类似的命题都需要或多或少用到对角线来构造反例,这就暗示了在你生活中接触过的算法全都跟停机问题无关。
【 在 xiaoju 的大作中提到: 】
: 所谓的写程序就是解一个停机问题,而停机问题在数学上是不可计算的,人类不是上帝也不例外。所以写程序本质上就是把一个大的不可 ...
--
FROM 85.76.66.*
这个思路跟我想的差不多。
把值和映射分开管理。映射本身当然也可以作为值,但是首先不能跟自己的 domain 混在一起,其次是实际上很少有能自然的符合 combinator 运算的 mapping ,书上的例子基本上都是 parser 和 lambda 相关
【 在 dilemma 的大作中提到: 】
: 游戏行业里有用entity component system配合data oriented ...
--
FROM 85.76.66.*