编程以外的依赖关系

主要是关于依赖关系在编程语言领域外的一些场景,
并不只有代码当中会呈现出这种模式, 历史随着时间也有,
考虑到编程语言本身就是用来模拟的真实世界, 这应该也存在相似性,
而且随着编程语言描述世界的能力的增强, 是否能成为哲学语言也未可知.

代码中的"依赖"

最常见的依赖关系处理的场景, 可以说是模块的依赖管理,
比如 npm 模块的依赖管理, 是每个开发人员的基础课,
比如模块 A 依赖 B 和 C, 而 B 依赖 E 和 F, 就是个树状的关系,
A 缺失了任何一个依赖, 都不能完整地运行它的全部功能,
而且当 B C E F 已经存在时, A 的工作量相对来说就很小了,
此外依赖更新还有冒泡的关系, E 更新通常会冒泡到 A,
如果 E 更新时接口发生了改变, 而 A 未跟进, 更新就会失败.

另一个可以看到依赖关系的地方是函数调用, let f x y = z.
从函数式编程角度看, z 就对 f, x, y 三种产生了依赖,
由于函数 f 通常在代码加载时生成, 那么 x 和 y 满足时, 就得到 z.
也就是说如果是异步或者 lazy 的数据的 x 和 y, 那么 z 会进入等待,
等到 x 和 y 都完成时, z 也就自动完成了. 这是编程语言里的做法.

现实中的"依赖"

现实当中的技术或者产品, 大量的依赖也是存在的, 特别是说到产品,
比如说 VR 的成熟, 就依赖很多东西, 比如计算量, 比如网络带宽, 比如人类生理的研究,
比如 AlphaGo 的成功, 依赖 GPU 的强大性能, 依赖大脑神经的研究, 还有很多,
粗略地也可以看到, 现成生活当中的依赖条件往往不那么清晰,
我们在事先评估某个技术是否成熟的时候, 大部分人看不清依赖有多少,
就像上面的例子展示的, 它的依赖不成熟时, 整个东西就无法完整, 技术也会打折扣.
通常我们仅仅以"条件不成熟"一句带过, 其实也可以说成"依赖不满足".

另一个是在事情的依赖发生更新时出现的问题. 比如说大脑当中的一个成见.
成见难以推翻的一个原因是它总是有着自己的依据, 很多很多的依据,
这些依据就作为了依赖, 而依赖的完整也就支撑了成见持久地存在.
我们知道世界很大, 世界会变, 这些依据往往会有更多, 会发生改变,
然而我们的记忆并不容易改变, 即便改变了, 原先的成见也不会响应式地更新,
这都是人类记忆的一个缺陷了. 随着人见多识广, 变老, 观念也会固化,
年轻初入世界往往是不靠谱的, 他们不立足我们的很多依据, 但其实也就这样.

人类世界的事情有着太多复杂性, 不是简简单单写代码可以媲美的,
因为有着太多的因素, 往往思考问题难以覆盖到所有的依赖,
然而, 把整个世界的运行规则看做一个函数的话, 它的参数也就是整个世界,
要得到正确的结果, 就需要正确的参数, 也就是整个世界,
我们都知道不可能, 因为人脑是及其有限的, 考虑的因素也是有限的,
也就意味着人类必然犯错误, 就像机器学习存在准确率问题一样.

由于依赖性, 一个问题往往会牵涉到大量因素, 其实是很累的事情,
特别是时间顺序上, 比如 B 依赖 A 的工作结果, 那么任何 A 的细节都会影响 B,
比如 A 因为私人的事情影响到了提交结果给 B 的时间, 就影响到 B,
那么 B 的每个行为就是要依赖 A 那个小事么, 当然不是.
这个时候引入接口和协议, B 依赖一个协议, A 只要遵从协议完成即可,
比如 A 限定在某天完成, 那么 B 就从之后第二天开始工作. 也就是进行了解耦.
换个角度看也是对依赖关系的一种 Mock 的做法吧.

其他可能性

用编程语言解释现实世界或许看着无聊, 但可惜大家都在这样做,
随着我们用编程语言描述越来越多的业务, 可以看到它有着强大的表达能力,
甚至在某些大型 3D 游戏当中编程语言可以把整个世界造出来,
不得不钦佩这样的能力, 人类简直成了上帝, 想想真是后背发凉.
但是至少验证整个世界可以用数据, 状态, 函数, 逻辑这些概念表达了,
那么可以想象, 未来更多的编程的概念可以在真实世界当中找到影子.